2007/03/24 16:50 Developer
AJAX를 사용시 좋은 데이터 교환 형태는?
용어정의를 먼저 하자. 2가지 방식으로 비동기 데이터 및 컨텐츠를 가지고 온다.
어떤 것이 더 좋은 선택일지 생각을 해보자.
Ajax : Asynchronous JavaScript and XML
AHAH : Asychronous HTML and HTTP
Ajax vs AHAH
http://www.ologist.co.kr/362
데이터를 가지고, html을 만드는 곳이 클라이언트 javascript or 서버쪽 Java, 둘다 html을 만들어 내는 것은 많은 +,",' 등등을 통해서 만들어 낸다. UI 및 태그가 바뀌고 디자인 요소들이 바뀐다고 하면 클라이언트 UI개발자나 자바 개발자나 둘다 엄청난 노가다를 해야 한다. MVC라는 말이 있다. 과연 서버쪽에서 데이터만을 전달해주고, 자바스크립트에서 노가다를 통해서 사이즈가 큰 html을 만들어내는 것이 진정한 MVC일까? UI개발자는 자바스크립트로 노가다를 해도 된다는 얘기인가?
또, 서버에서는 데이터만을 전달하고, javascript가 알아서 노가다를 통해서 만들어내는 코드가 변경에 민감할 것인가? 물론, 서버에서 string을 이어서 html을 만들어내는 노가다보다는 화면 부분인 자바스크립트에서 노가다를 하는 것이 UI변경시 좀더 빠르고, 명확하게 할수는 있지만, 더 좋은 부분은 관리가 되는 html파일로 존재를 하는 것이 더 좋다. 즉, 클라이언트,서버 둘중의 한 곳에서 템플릿 파일을 통해서 디자인 요소가 관리가 되어야 한다.
내가 알기로는 javascript로 이용할 수 있는 템플릿 엔진은 아직 없는 것으로 알고 있고, 선택은 서버쪽일 수 밖에 없다. 아예 html형태로 클라이언트에 내려주고, html에 관련된 코드들이 특정한 템플릿 파일로 존재를 한다면, 클라이언트 개발자가 템플릿 파일을 수정할 수 있게 된다. 템플릿 파일에 대한 데이터 맵핑은 서버에서 하지만, 템플릿 파일은 클라이언트 개발자가 관리할수 있는 구조를 만드는 것이다.
그래서 난 아래 방법인 AHAH의 방법을 쓸것이고, 하나 덧붙여야 덧붙여야 겠다.
발음은 '아하트'라고 하면 되겠다.
AHAHT : Asychronous HTML and HTTP by Template
가장 큰 장점은 서버쪽에서 힘들게 XML형태로 만들지 않아도 되고,(사실 이부분도 DOM을 통해서 string형태로 만들어야 하지만, 실무에서 메모리나 편의를 위해서 그렇게 만드는 사람이 몇이나 되겠는가?) 클라이언트쪽에서 힘들게 파싱을 해서 html을 만들지 않아도 된다.
UI(html)에 대해서 분리가 명확해진다. 서버코드 + 템플릿 파일 + 자바스크립트 형태로 자바스크립트에서 UI요소를 최소화 할수 있는 장점이 있다. 현재 그렇게 작업을 하고 있는데 우리 회사의 UI개발자의 이해도가 높아서 비교적 협업이 잘 이루어지고 있다.
그리고, 정말 간단한 형태의 데이터 전달은 JSON을 적극 활용을 하고 있다....^^
3월 25일 추가
김민재님 블로그에서 아래 링크를 가져왔다.
벤치마킹이라는 것이 항상 특수한 상황에서 하기 때문에 실무에서 딱 들어맞다고 할수는 없지만, 참고로 보고, 상황에 따라 편하게 사용을 하면 되겠다.
Benchmark - W3C DOM vs. innerHTML
http://www.quirksmode.org/dom/innerhtml.html
어떤 것이 더 좋은 선택일지 생각을 해보자.
Ajax : Asynchronous JavaScript and XML
AHAH : Asychronous HTML and HTTP
Ajax vs AHAH
http://www.ologist.co.kr/362
데이터를 가지고, html을 만드는 곳이 클라이언트 javascript or 서버쪽 Java, 둘다 html을 만들어 내는 것은 많은 +,",' 등등을 통해서 만들어 낸다. UI 및 태그가 바뀌고 디자인 요소들이 바뀐다고 하면 클라이언트 UI개발자나 자바 개발자나 둘다 엄청난 노가다를 해야 한다. MVC라는 말이 있다. 과연 서버쪽에서 데이터만을 전달해주고, 자바스크립트에서 노가다를 통해서 사이즈가 큰 html을 만들어내는 것이 진정한 MVC일까? UI개발자는 자바스크립트로 노가다를 해도 된다는 얘기인가?
또, 서버에서는 데이터만을 전달하고, javascript가 알아서 노가다를 통해서 만들어내는 코드가 변경에 민감할 것인가? 물론, 서버에서 string을 이어서 html을 만들어내는 노가다보다는 화면 부분인 자바스크립트에서 노가다를 하는 것이 UI변경시 좀더 빠르고, 명확하게 할수는 있지만, 더 좋은 부분은 관리가 되는 html파일로 존재를 하는 것이 더 좋다. 즉, 클라이언트,서버 둘중의 한 곳에서 템플릿 파일을 통해서 디자인 요소가 관리가 되어야 한다.
내가 알기로는 javascript로 이용할 수 있는 템플릿 엔진은 아직 없는 것으로 알고 있고, 선택은 서버쪽일 수 밖에 없다. 아예 html형태로 클라이언트에 내려주고, html에 관련된 코드들이 특정한 템플릿 파일로 존재를 한다면, 클라이언트 개발자가 템플릿 파일을 수정할 수 있게 된다. 템플릿 파일에 대한 데이터 맵핑은 서버에서 하지만, 템플릿 파일은 클라이언트 개발자가 관리할수 있는 구조를 만드는 것이다.
그래서 난 아래 방법인 AHAH의 방법을 쓸것이고, 하나 덧붙여야 덧붙여야 겠다.
발음은 '아하트'라고 하면 되겠다.
AHAHT : Asychronous HTML and HTTP by Template
가장 큰 장점은 서버쪽에서 힘들게 XML형태로 만들지 않아도 되고,(사실 이부분도 DOM을 통해서 string형태로 만들어야 하지만, 실무에서 메모리나 편의를 위해서 그렇게 만드는 사람이 몇이나 되겠는가?) 클라이언트쪽에서 힘들게 파싱을 해서 html을 만들지 않아도 된다.
UI(html)에 대해서 분리가 명확해진다. 서버코드 + 템플릿 파일 + 자바스크립트 형태로 자바스크립트에서 UI요소를 최소화 할수 있는 장점이 있다. 현재 그렇게 작업을 하고 있는데 우리 회사의 UI개발자의 이해도가 높아서 비교적 협업이 잘 이루어지고 있다.
그리고, 정말 간단한 형태의 데이터 전달은 JSON을 적극 활용을 하고 있다....^^
3월 25일 추가
김민재님 블로그에서 아래 링크를 가져왔다.
벤치마킹이라는 것이 항상 특수한 상황에서 하기 때문에 실무에서 딱 들어맞다고 할수는 없지만, 참고로 보고, 상황에 따라 편하게 사용을 하면 되겠다.
Benchmark - W3C DOM vs. innerHTML
http://www.quirksmode.org/dom/innerhtml.html
