요즘 EP2때문에 같이 일하는 행복한 고니님의 블로그에 갔다가 Ajax에 대한 글을 읽었다.

Five Ajax Anti-Pattern
http://mygony.com/archives/998

위에 글을 통해서 원문까지 독파를 했다. 아마 많은 분들이 평소에 생각한 내용들이 많이 나와서 자신이 생각한 결정에 도움이 될것이다. 항상 같은 고민을 하고 있었고, 솔루션은 대부분 비슷하더라가 내 지론이다.

XML, JSON, HTML을 데이터를 리턴을 해줄수가 있다. 너무 어렵고 불편한쪽으로 하지 말자. UI쪽에서 편하게 쓸수 있는 데이터 타입을 생각을 해보자. 중간에 XSLT와 같은 기술을 이용해서라도 좀더 편안하게 클라이언트에서 사용을 할수 있는 구조로 주자.

Ajax and XML: Five Ajax anti-patterns
http://www-128.ibm.com/developerworks/web/library/x-ajaxxml3/index.html


사실 Ajax는 새로울 것은 없는 기술이지만, XHR인터페이스 기본 기술을 바탕으로 현재에는 엄청나게 발전을 하고 있다. 앞으로도 발전의 가능성이 높은 부분이라고 생각을 한다.

자의든 타의든 간에 요구사항을 만족을 하기 위해서 퍼포먼스를 위해서 서비스나 솔루션을 개발을 할때는 꼭 하나의 모듈이상은 쓰게 된다.

이번에는 수많은 복잡한 form을 처리를 하기 위해서 사용을 했는데, 현재까지는 대만족이다. 여러 좋은 사람들의 의견때문에 더욱더 좋은 디자인을 결정을 할수가 있었고, 대략 현재까지는 만족스럽다. 하지만, 눈에 거슬리기 시작하면 또 나는 refactoring을 시작할 것이다.

Ajax vs AHAH

2006/09/09 18:12
Ajax 코딩을 하며서 항상 고민이 되었던 부분은 뷰단으로 데이터를 XML으로 넘겨줬을때 파싱하기도 어렵고, XML파서가 브라우져마다 달려서 클라이언트단에서 파싱해서 알맞은 뷰를 만들어서 보여주기가 여간 부담스러운 것이 아니었다.

Ajax를 처음할때는 뷰와 에디터, 로직을 위해서 가능한 XML으로 리턴하고, 클라이어트 자바스크립트에서 뷰를 만들어서 해결을 했는데, 크로스 브라우져를 지원해야 하는 업무를 맡게 된 다음부터는 생각이 바뀌었다. Json타입이 어느정도 대안이 될수 있다고 생각을 했다. 그리고, 실무에서 그렇게 적용해서 재미도 봤다..^^

하지만, 좀더 나은 방법은 클라이언트에서 아예 부담을 없애는 것도 좋다는 생각이 들었다. 일단 비즈니스 로직을 수행후 특정 데이터 포맷으로 나오면 그것을 XML타입이나 JSON타입으로 서버에서 만들고, VIEW에 대한  템플릿을 작성을 해서(velocity, freemaker등등을 이용) 데이터만 매치을 해줘서 아예 HTML형태로 내려보내는 것이 좋을거 같다. 물론, 데이터와 뷰와 결합을 해서 내려가게 되면, 통신하는 데이터양에 대한 부담감도 있지만, 그건 압축을 통해서 해결이 가능하지 않을까 싶다.

XSL을 이용한 XSLT도 뷰를 만들어내는 방법이 될수도 있으나, 퍼포먼스쪽에서 좋은 점수를 주기는 힘들고, 간단하고, 쉽게 템플릿 엔진을 이용하는게 개발이나 유지보수에서 더 편하리리라 생각을 한다.

크로스 브라우져 이슈도 해결을 하고, 파싱에 대한 귀찮음도 템플릿을 만들어서 해결을 하고, 데이터양의 문제도 해결했다. 아직 실무에 적용을 해보진 않았지만, 이것들을 좀더 쉽게 할수 있게 framework형태로 만들어 두면, Ajax가 더이상 노가다가 아니게 될수 있지 않을까?

AHAH - AJAX의 보완
http://dnzin.com/cunningweb/2006/09/08/ahah/

XMLHttpRequest를 이용해서 Ajax UI를 구현할때 다음과 같은 오류를 본적이 있는가?
아마도 많으리라 생각을 한다.

"시스템 오류 -1072896658"

당황하지 말자...나도 사실 당황했다. 이게 자꾸 왜 뜰까하고 검색을 해봤더니 다음과 같이 나왔다. 아마도 이것 이외에 이유가 더 있을 수도 있다. 하지만, 일단 인코딩을 의심해보자.

AJAX script 오류 : 시스템 오류 -1072896658
http://blueb.net/blog/search/-1072896658

Google Web Toolkit - Build AJAX apps in the Java language

초기생성 날짜 : 5월 27일

구글에서 자바로 Ajax를 쉽게 개발할 수 있게 하는 SDK를 배포했다. 역시!! 구글~!!

gwt-windows-1.0.21
SDK의 버젼에 주목할 필요가 있다. 0.XX의 알파버젼이 아닌 1.XX이상의 버젼으로 그 동안 안정화에 많은 고심을 할 끝에 나온  product라는 것을 알수가 있다.

Ajax를 노가다로 만들어 본 사람들은 알겠지만, 개발할때도 힘들고, 디버깅도 어렵고, 테스트로 어렵다.

여러가지 사례들도 많았지만, JSF나 Google Web Toolkit , DWR처럼 자바로 개발을 하는 방법이 현재는 Best Practice로 자리를 잡아나가는거 같다.

최근 트렌드를 보면서 개인적으로 Ajax의 개발 미래를 넌지시 예상을 해보자면, 직접 웹페이지 안에서 하는 코딩은 거의 없어질 듯하고, 이렇게 오픈된 소스를 활용을 하거나, 능력이 되는 회사나 lab, team에서는 특색에 맞는 sdk를 만들어서 사용을 하지 않을까 싶다!!

아키텍쳐를 한번 살펴보자. 아래 그림과 같다. 어떤가? 심플해보이지 않는가?ㅎㅎㅎ



Why Translate Java Code to JavaScript?

Java technologies offer a productive development plaform, and with GWT, they can instantly become the basis of your AJAX development platform as well. Here are some of the benefits of developing with GWT:

  • You can use all of your favorite Java development tools (Eclipse, IntelliJ, JProfiler, JUnit) for AJAX development.
  • Static type checking in the Java language boosts productivity while reducing errors.
  • Common JavaScript errors (typos, type mismatches) are easily caught at compile time rather than by users at runtime.
  • Code prompting/completion is widely available.
  • Automated Java refactoring is pretty snazzy these days.
  • Java-based OO designs are easier to communicate and understand, thus making your AJAX code base more comprehensible with less documentation

javascript를 직접 코딩 안하고 자바를 통해서 개발하는 것에 대한 장점이 위와 같이 나와있다. 색깔을 틀리게 한 부분만 보면 Ajax개발에 있어서 선택이 아님 거의 필수라는 생각이 든다.

XP와 TDD가 주목받고 있는 지금 Ajax개발에 충분한 기반으로 자리잡을수 있을 듯하다. 테스트를 할수 없는 코드는 만들지도 말라고 했다. javascript의 디버깅의 어려움, 테스트의 어려움을 GWT를 통해서 해결을 해보자.

사용법은 간단하니...한번씩 구현을 해보는것 좋을듯..^^

설치방법
1. gwt-windows-1.0.21를 다운로드를 받는다.
http://code.google.com/webtoolkit/download.html

2. 적당한 폴더에 압축을 풀고, GWT_HOME으로 압축을 푼 곳을 환경변수에 추가를 한다.
CLASSPATH와 PATH에 GWT_HOME의 경로를 설정해준다.

압축을 푼곳에 있는 디렉토리와 파일들이다. 차근차근 살펴보자!!

개발방법
대부분 이클립스를 이용해서 개발을 한다고 생각을 하고 이클립스의 예를 들어보자
applicationCreator -eclipse MyProject com.mycompany.client.TestApp

cmd에 들어가서 프로젝트 파일들을 생성시킬 장소에 들어가서 위와 같이 명령만 때리면 자동으로 파일들이 쭉 만들어진다.
여러가지 skeleton들이 만들어진다.

그 다음 *-compile.cmd를 클릭을 하면 컴파일되서 다음과같이 www폴더가 생긴다.

*-shell.cmd를 클릭을 하면 다음과 같은 화면이 동시에 2개가 뜬다.

이제 기본적인 스켈레톤 생성과 테스트가 끝난 것이다..^^

그 다음 Eclipse를 띄운뒤 File -> Import를 선택하고, "Existing Projects into Workspace"를 선택해서 만들어진 폴더와 파일들을 import한다.www폴더를 컨텍스트 root로 잡고, wtp를 이용해서 호스트 모드로  tomcat를 띄우면 된다.

다음과 같은 URL에서 테스트 페이지를 확인할 수가 있다.
http://localhost:8080/com.nhn.ajax.TestApp/TestApp.html

아래화면은 실제 브라우저에서 본 화면이다.

더 많은 이야기들은 아래 링크를 참조하자~!!

Google Web Toolkit - Build AJAX apps in the Java language
http://code.google.com/webtoolkit/


Google Web Toolkit Downloads
http://code.google.com/webtoolkit/download.html

Google Web Toolkit Getting Started Guide
http://code.google.com/webtoolkit/gettingstarted.html

6월 11일 추가
네이버 블로거 레퍼백곰님 후기
http://blog.naver.com/django44/40024832964
위에 포스팅에 대한 이야기 : DWR,GWT방식 vs Rico방식에 대한 혼란이 있습니다만, 어떤 스타일이 맞는지 고민, JSF나 기타 UI플랫폼(Swing,Awt, VS.net)을 생각하면 UI개발은 컴포넌트기반이 맞다는 생각도 들고,  순수html요소의 디자인과 비즈니스로직 input으로서의 ui와 경계선이 헷갈립니다. JSF가 표준처럼 자리 잡을수 있게 되면, 아무래도 컴포넌트 기반으로 가지 않을까 조심스럽게 전망을 해봅니다. 아마도 또 많은 개발자들의 삽질로 더 좋은 아키텍쳐가 나오지 않을까 싶네요. 일단은 Ajax는 노가다로 할렵니다...흑흑....

6월 16일 추가
GWT(Google Web Toolkit) 테스트 중…
http://www.talk-with-hani.com/archives/252
좀더 GWT에 대해서 생각을 해보자

7월 23일 추가
Google Web Toolkit
http://jania902.egloos.com/1970669
힌둥이님 DWR 강좌
http://cafe.naver.com/ArticleRead.nhn?clubid=10068252&menuid=&listtype=A&boardtype=L&page=&articleid=1588

Quick Guide to Prototype
http://particletree.com/features/quick-guide-to-prototype/
네이버 책검색 플러그인 테스트겸 예약주문한 책을 포스팅해보자

[예약판매] 실전 Ajax

저스틴 게틀랜드.벤 갤브레스, 황인석.강승우.송인철 옮김 / 인사이트(insight)


팝업창을 누르면 하단에 스크립트 에러가 난다...^^;
그냥 살포시 무시하고, 선택을 하니깐, 제대로 나온다...ㅎㅎㅎ

어제 고민고민하다가 주문을 했다. 5월 1일쯤 발송이라고 했나???

BLOG main image
OOP and Java by ologist

공지사항

카테고리

All (649)
private!! (106)
WEB & IT (140)
Developer (400)