1. DOM 이란,

  ㅇ 웹브라우저의 제작사별,버젼별 차이에 의존하지 않고 표준적인 프로퍼티(Property) 및
     메소드(Method)를 통해,  웹 페이지 내의 모든 요소에 접근할 수 있게하는 기반모델을 
     말한다.                                            ☞ DOM 관련 홈페이지


2. 특징

  ㅇ 객체지향적 설계
     - 문서 내의 모든 요소를 객체화해서 표현하고 접근토록 함
  ㅇ 웹 브라우저에 의존하지 않고 문서 표현 가능
     - 플랫폼, 프로그래밍 언어에 비의존적인 독립적인 인터페이스
  ㅇ DOM에서는 다음사항을 정의하고 있음
     - 문서에 대한 논리적 구조, 동적 접근, 동적 제어 방법을 정의 
  ㅇ 웹 페이지에 동적으로 접근 및 변경 가능
     - 객체, 프로퍼티, 메서드, 이벤트를 통해서 접근하고, 
     - 스크립트(자바스크립트 또는 VBscript 등)를 사용해서,
     - 웹 페이지의 컨텐츠를 동적으로 변경할 수 있게 함
  ㅇ 문서를 트리형 구조로 표현 
     - 문서에대해 트리구조를 갖는 객체들의 모음으로 표현함 (계층적 구조) 
  ㅇ DOM 산업표준 및 표준 권고
     - Level 0 DOM
     - W3C 표준
        . 1998년10월 DOM Level 1 권고안
        . 2000년11월 DOM Level 2 권고안


3. 객체 표현

  ㅇ 웹 브라우저가 HTML 문서를 로드하면 자동적으로 여러 개의 객체들을 생성
     - 문서 내의 모든 요소 노드는 객체

  ㅇ 객체의 종류
     - 도큐먼트 객체 : HTML 태그 당 하나의 객체
     - 디폴트 객체   : 초기에 자동으로 생성되는 객체
        . window, document, history, location, navigator, screen,
          clientInformation
     - 속성 객체     : 속성, 스타일, 텍스트를 표현하는 객체
        . attribute, style, runtimeStyle, currentStyle, rule, textNode,
          textRange, textRectangular
     - 임시 객체     : 문서 처리 중에 동적으로 생성되는 임시적인 객체
        . clipboardData, dataTransfer, event, popup, selection
     - 기타 객체     
        . custom, namespace, ...

  ㅇ 객체 계층구조
                       window
     ┌────┬────┼─────┬────┬───┬─ ...
 location   history    document   navigator   screen  event ...
           ┌──────┼─────┐
          form         image        link

     - document 객체 : 해당 자바스크립트를 포함하고 있는 HTML 문서를 참조할 수 있
                       는 객체를 말한다
     - window 객체   : 브라우저 화면을 참조할 수 있는 객체를 말한다

  ㅇ 객체에 접근하는 방법
     - id를 사용하는 접근방법        : getElementByID
     - name 속성을 이용하는 접근방법 : getElementByTagName => 결과가 배열로 얻어짐
     - all 컬렉션을 이용하는 접근방법
     - all 이외의 다른 컬렉션을 이용하는 접근방법
     - this를 이용하는 접근방법


4. Node  ☞  DOM 노드 (DOM Node)


5. DOM 관련 메소드  ☞  DOM 메소드 (DOM Method)


6. DOM 프로퍼티 

  ㅇ Node 관련 프로퍼티 (Node Property) : 각 요소 그 자체의 정보
     - 기본 : nodeName, nodeType, nodeValue, innerHTML(비표준), ...
     - 관계 : parentNode, firstChild, lastChild, childNodes, previousSibling,
              nextSibling, ...
     - 노드 찾기/이동을 위한 5가지 프로퍼티  
        . 노드 관계 : parentNode,firstChild,lastChild,previousSibling,nextSibling
        . 노드 리스트 : childNodes[], children[]
  ㅇ style 관련 프로퍼티 (Style Property) : 각 요소의 스타일 정보
     - position : static, fixed, relative, absolute
     - left, top, margin, color, font, font-family, ...

출처 - http://www.ktword.co.kr/abbr_view.php?nav=&m_temp1=2506&id=465

BOM   Browser Object Model   브라우저 객체 모델

수정일 : 2010-01-31

1. 개요

  ㅇ BOM(브라우저 객체 모델)은, 웹 브라우저 창을 관리할 목적으로 제공되는 객체 모음
     을 대상으로 하는 모델로써, 자바 스크립트 등에서 이를 사용할 수 있다.
     - 브라우저 제작사 마다 세부사항이 다소 다르게 구현, 한정적임


2. 특징

  ㅇ 웹브라우저의 윈도우 객체를 대상으로 하는 윈도우 객체 모델의 일종으로써,
     - 비표준적이나, 대부분의 웹 브라우저는 Netscape 3 를 표준처럼 많이 따름
        . 이를 DOM Level 0 이라고도 불리움
     - 웹브라우저를 위한 객체 모델의 표준으로는, DOM(다큐먼트 객체 모델)이 있음

  ㅇ 역할
     - 웹 브라우저의  버튼, URL 주소 입력 창, 타이틀 바 등  웹 브라우저 윈도우 및
       웹 페이지의 일부분을 제어할 수 있게끔하는  윈도우 객체 모델임.

  ㅇ 계층구조 
     - 하나의 window 객체 : 브라우저 창 하나에는 각기 하나의 window 객체가 있게됨
        . window 객체는 전역 객체(global object)라고 불리움
           .. 전역객체는 그 객체의 프로퍼티,메서드를 쓸때 그 이름을 명시할 필요없음
        . 각 window 객체 간에는 서로 통신을 할 수도 있음
     - window 객체 안에는 다음과 같은 객체들이 있음
        . html 웹문서로 향하는 관문 : document 객체
        . 웹 이동을 위한 객체 : location, history 객체
        . 컴퓨터 스크린 정보 : screen 객체

  ㅇ 참고사항
     - 메서드 例 : alert(), prompt(), write(), ...
     - 이벤트 例 : onclick 이벤트, onload 이벤트, ...

출처 - http://www.ktword.co.kr/abbr_view.php?m_temp1=2519&m_search=

• by 권남 
• 2012/10/14 21:33 
• kwon37xi.egloos.com/4747016 
• 덧글수 : 4

Maven을 써 본 사람들은 대부분 느끼리라 생각하지만 매우 경직돼 있고 그로인해 무언가 Maven이 기본 지원하지 않는 빌드 과정을 추가해야 할 경우 고생이 이만 저만이 아니다. 이에, 요즘 Maven 대한 대안이 많이 나오고 있으며 그 중 가장 돋보이는 것이 Gradle(Groovy 기반)이 아닌가 싶다. 그래서 차기 프로젝트의 빌드 툴로 Gradle을 도입해보고자 현재 프로젝트의 빌드 구성(매우 복잡하다)을 Gradle로 바꿔보며 그 가능성을 시험해 보았고 그 과정을 정리해 보았다.

매우 긴 내용이 될 것이라서 성질 급한 사람들을 위해 요약한다.

• 난 이제 가능하면 Maven 안 쓴다. 되도록 항상 Gradle 혹은 이것보다 나은 툴이 나온다면 그것을 사용하리라.
• Gradle의 사용자 가이드를 번역해 두었다. Java 프로젝트를 진행하는데 필요한 거의 모든 내용을 번역하였고, 또한 내가 경험하며 검색등으로 찾은 문제 해결책들도 모두 정리해 두었다. Maven 공부할 시간에Groovy + Gradle 공부하는게 더 생산적이라고 생각한다.
  

• 프로젝트 구성/빌드 툴로써 프로젝트 구성은 정적인 설정 정보이고 빌드는 동적인 행위이다. 그런데 이것을 정적인 데이터를 저장하는데 적합한 XML로 그 내용을 기술하게 함으로써 동적인 행위인 빌드에 크나큰 제약을 가한다. 게다가 XML은 너무 장황해서 실제 설정 내용보다 XML 뼈대가 더 많다.
  
• 다른 하나는 Gradle을 사용하다 느낀 것인데, Maven은 설계상의 문제도 있다. 바로 멀티 프로젝트 구성을상속 구조로 한 점이다. 그에 반해 Gradle은 구성 주입 방식(Configuration Injection, 설정 주입 방식이 더 나은 번역일까?)을 사용한다. 이는 빌드 구성 정보에서 매우 큰 차이를 만든다.
  

1. 15개 정도의 프로젝트가 서로간의 의존 관계를 맺고 있다.
2. Spring 3.1이 뼈대를 이룬다.(이것 자체는 빌드에 영향을 안 줌)
3. Apache CXF를 통해 SOAP Client Java 클래스 자동 생성하고 이를 각종 서비스에서 사용한다.
4. JPA 2를 ORM으로 사용하며 이것의 StaticMetaModel Java Class들을 자동 생성해야 한다.(Annotation Processor)
5. Lombok 을 사용하여 Getter/Setter/Slf4j/기타 등등의 코드를 자동 생성한다.(Annotation Processor)
6. 웹 프로젝트들은 공통 리소스를 가지고 있으며 Eclipse에서는 LinkedResource로 지정되어 개발시 불필요한 공통 요소 복제 작업이 안 일어나도록 처리하고 있다.
7. 웹 프로젝트에서 Javascript 파일을 빌드 툴에서 자동 최적화 해서 배포해 준다.
   
8. Carbon Five Database Migration 툴로 데이터베이스 마이그레이션을 진행한다.
9. Eclipse와 연동해야 한다. Eclipse 전용 플러그인이 있지는 않아도, 최소한 Gradle의 구성 상태를 Eclipse 설정으로 그대로 명령어 한 방으로 옮길 수 있어야 한다.
10. 추가) Maven의 Profile 기능을 통해 개발/통합테스트/Staging/Production등을 구분하고 프로필에 따라 서로 다른 빌드 로직을 탄다.
    

실제 복잡도는 더 높다. 단지 빌드에 무관한 항목들이라 기입하지 않았을 뿐이다.

저 모든 것들이 두 가지만 빼고 Maven에서 보다 더 쉽게 Gradle에서 설정 가능하였다. Eclipse 연동도 성공적으로 이뤄 내었다.

이떻게 했는지는 Gralde 사용자 가이드 번역에 모두 기록해 두었다. 저 정도 복잡도가 된다면 웬만한 자바 프로젝트는 아무 문제 없이 구성 가능할 것이다.

문제를 일으킨 것은 두가지다.

첫째, provided 스코프가 없다. 이는 내가 보기엔 치명적인 문제이며 나를 가장 많이 괴롭힌 것이었다. 하지만이슈로 등록 되어 있어서 곧 해결 될 것으로 보이며 물론 현재 버전에서도 해결책을 찾아 내었다. 더 큰 문제는 Eclipse 연동시에 Eclipse가 provided로 지정된 라이브러리를 웹서버 띄울 때 배포하는 것이었는데 그것도 모두 해결해서 기록해 두었다. from_maven 참조

둘째, Carbon Five Database Migration(C5) 툴은 기본적으로 Maven 플러그인이다. 독립 툴이 아니다. 이를 Gradle 플러그인으로 직접 옮겼는데, 너무 쉽게 되었다. C5 자체가 실제 기능 코드와 Maven 플러그인 코드가 잘 분리되어 있기 때문이다. 게다가 Gradle 플러그인 만들어 추가 하는 것은 Maven으로 플러그인 만들어서 프로젝트에 추가 하는 것과는 차원이 다르게 쉽다.

Gradle은 기본적으로 모든 Ant 태스크를 사용할 수 있다. C5가 Ant 연동을 제공했다면 정말 아무것도 아닌 일이었겠지만, 뭐 그 덕분에 Gradle 플러그인 만드는게 얼마나 쉬운지도 배우게 되었다.

또한 나는 차기 프로젝트에서는 Ant/Maven을 둘 다 지원하는 flyway를 사용할 예정이다.

결론은 이렇다.

사실 Gradle을 사용하면서 느낀 Maven의 문제점은 더욱 더 많다. from_maven 참조 해 보시길.

앞에서도 말했듯이 난 이제 피치못할 상황이 아니면 Maven 사용 안 할 예정이다. Gradle 혹은 최소한 이보다는 나은 프로젝트 구성/빌드 도구를 사용할 것이다.

아무리 간편한 툴이라도 그 기능이 요구사항에 못 미치고 버그가 많다면 그걸 사용하면 안된다. 하지만 나는 기존에 내가 참여하고 있는 프로젝트의 빌드 구성을 모두 Gradle로 완벽하게 포팅함으로써(설정파일 줄 수가 Maven 2800줄에서 Gradle 650줄로 줄었다) 기능도 부족함이 없음을 스스로 증명했다.

비록 Groovy와 Gradle을 모두 다 배워야 하는 부담이 있겠지만, 그게 장기적으로 더 개발자를 이롭게 할 것이다. 나 같은 경우 순전히 Gradle을 하고 싶어서 Groovy를 배웠는데, 그 뒤로 우리 프로젝트를 관리하는 부가 시스템과 셸 스크립트들을 Groovy로 다 바꿔 버렸다. 원본 프로젝트의 Java 코드를 직접 호출 할 수 있기 때문에 훨씬 더 편해졌다.

Maven에서는 아무리 Java를 알아도 빌드 구성을 하면서 너무 힘든 경우가 많았다. 하지만 Gradle을 나의 Groovy 지식이 일천함에도 훨씬 더 편안하고 즐겁게 일을 마칠 수 있었다.

빌드가 아니라 프로젝트 운영 코드를 짜는데 더 집중하고 싶은가?

그러면 Gradle을 사용하자.

출처 - http://kwon37xi.egloos.com/4747016