최근에 프로젝트에 ExtJS를 비록하여 몇가지 JavaScript 프레임워크를 검토한 적이 있다.
내부적으로 ExtJS를 사용하고 있지만, 결코 주변의 다른 프로젝트를 진행하고 있는 사람들에게는 적극적으로 권하지 않는다. 왜냐하면, 한국은 HTML, CCS 그리고 JavaScript를 웹 프로그램의 한 부분으로 생각하지 않고 있을 뿐더러, 그렇다고 디자이너의 역할 중의 하나라고도 생각하지 않는다. 그렇게 때문에 HTML, CSS 그리고 JavaScript의 전문가를 찾아 보기가 쉽지 않다.

ExtJS를 권하지 않는 이유는 처음 이를 사용할 때는 Windows에서나 제공할 수 있었던 많은 기능들이 컴포넌트화 되어 있어서, 사용하기 편할거라는 생각을 하는데, 이를 응용한 새로운 컴포넌트를 만들거나 제대로 기능을 사용하려면, 약 2달정도의 학습시간이 필요하기 때문이다. 개발 초기에 이를 감안한다면, 사용하는 것은 별 문제 없지만, 기존의 HTML과 CSS만을 이용할 때보다는 전체 개발시간이 늘어날 거라고 반드시 예상하고 개발 플랜을 잡아야 할 것이다.

최근에 기존에 개발되어 있던 기능을 살펴볼 일이 있었다.
개발자가 ExtJS의 코드를 그대로 가져다 써서 인지 사소한 버그가 있었다. ExtJS의 버그나 잘못은 아니라고 생각한다. Ajax와 ExtJS의 그리드 컴포넌트를 이용하였는데, 마지막 페이지에 있던 Rows를 모두 삭제하면 이전 페이지로 이동해야 하는데, 마지막 페이지 그대로를 표시하는 것이었다.

그래서, 몇가지 자료를 찾아보았더니, 관련된 예제는 아래와 같은 Link에 있었다.
그리드에 데이터 목록을 가져오고, 목록에 추가/수정/삭제에 대한 예제가 있다.

예제: Tutorial:Using Ext grid form dialog to achieve paging list, create, edit, delete function 

이중에서 delete에 대한 예제는 아래와 같았다. (아래 Delete Function 예제 참조)

Delete function Delete function will get the selected id(s) and create JSON data and send JSON data to Java server-side for handle. /************************************************************ * Action - delete * start to handle delete function * need confirm to delete ************************************************************/ function doDel(){ var m = grid.getSelections(); if(m.length > 0) { Ext.MessageBox.confirm('Message', 'Do you really want to delete it?' , doDel2); } else { Ext.MessageBox.alert('Message', 'Please select at least one item to delete'); } }   function doDel2(btn) { if(btn == 'yes') { var m = grid.getSelections(); var jsonData = "["; for(var i = 0, len = m.length; i < len; i++){ var ss = "{\"id\":\"" + m[i].get("id") + "\"}"; //alert(ss); if(i==0) jsonData = jsonData + ss ; else jsonData = jsonData + "," + ss; ds.remove(m[i]); } jsonData = jsonData + "]"; ds.load({params:{start:0, limit:myPageSize, delData:jsonData}}); } } And delete parameter to server side with JSON data like this: delData=[{"id":"5"},{"id":"6"}]

위 예제를 보면, 서버로 데이터를 요청할 때, 파라메터로 start 값과 limit값을 보내줌을 알수 있다.
상기 예제 소수의 하단을 보면,    ds.load({params:{start:0, limit:myPageSize, delData:jsonData}});
라는 코드가 눈에 들어올 것이다. 이를 이용하여, 서버에서 DB에 쿼리를 수행해서 현재 페이지에서 필요로 하는 첫 번째 인텐스 값과 현재 페이지에서 표시할 수 있는 데이터의 갯수를 가져오는 것인데, 위 예제는 기본적으로 "0"번 인덱스를 서버로 보내서 매번 1페이지만 가져오는 것이다.

만약 이를 해결하려면, 두가지 방법이 있는데

첫번째는 위에서 사용했던 함수 ds.load({params:{start:0, limit:myPageSize, delData:jsonData}});
의 start 파라메터에 이전 페이지의 첫번째 인덱스를 넣어주는 것이다. 이를 위해서는 전체 Total Counter를 이용하여 총 페이지 수와 인덱스를 찾는 로직이 필요한데, 이미 많이 사용되는 코드라 쉽게 찾고, 만들수 있을 거라 생각된다.

두번째는 페이지 네이션을 모두 서버에서 담당하는 것이다. 이 경우는 동시에 사용자들이 수정 추가 삭제에 대해 부분도 충분히 고려되어 질 수 있다. 이에 필요한 계산 로직은 위의 첫번째 방법과 별로 다르지는 않고 단지 책임에 대한 부분만 책임을 지면된다. 이때는 서버에 현재 페이지의 첫번째 인덱스 번호를 서버로 보내주는 것이 바람직하다.
이를 이용하여 서버에서는 전제 개수와 페이지를 계산하고 마지막 페이지가 존재하지 않는 경우 이전 페이지의 목록을 보내주면 되기 때문이다.
 

기본적으로 RIA라는 말은 "Rich Internet Application"이라는 full name에서와 같이 Rich라는 말에 주목하게된다.
이는 기존의 인터넷 환경과 Resouce를 사용할 수 있는 환경이 좋지 않았다는 이유를 반증하기도 한다.

인터넷상에서 우리가 사용할 수 있는 Application은 C/S Aplication 즉 Client & Server 기반의 애플리케이션과는 구분이 된다. 기본적으로 웹 브라우져를 사용한 다는 전제가 깔려 있기 때문이다. 하지만 이것 또한 과거의 빈약한 네트워크 환경과 인터넷 환경에서의 이야기 이다.

현재의 대한민국의 인터넷 환경은 과거 10년전과 비교하면 엄청난 변화가 있다.
10년 전의 인터넷은 기업체와 대학에서 사용하던 상용 인터넷 서비스를 제외하고는 PC방에서만 체감할 수 있을 만한 빠를 속도를 경험 할 수 있었다. 그리고는 ADSL이 나오면서 일반적인 가정에서 이를 경험할 수 있었다.
지금의 인터넷 서비스는 집집마다 광으로 직접 연결되어 있다. 그리고 무선 인터넷 역시 많은 변화가 있었는데, 무선 인터넷의 빈약한 환경속에서 WAP으로 구현하거나 이와 유사한 형태로 데이터를 모바일 브라우져를 통해서 보았었는데, 어느샌가 우리는 WAP이외의 다른 브라우져을 더 많이 사용하고 있다.

이러한 변화는 단지 네트워크 기술의 발전에 의해서만은 아니다. 하드웨어 기술적인 발전과 관련 소프트웨어와 사용자의 제품에 대한 관심들 많은 요소들이 복합적으로 변화되고 진보해 왔기 때문이다.

과거의 RIA와 현재의 RIA를 바라보는 관점도 이에 맞추어서 달라져야 할 것 같다.
과거의 제한적인 환경들이 현재에는 많은 부분 해결되었고, 이를 위해 기술적으로도 많이 발전했기 때문이다.
하지만 우리가 Internet Application을 개발한다고 하면, 이는 곧 웹 브라우져를 기반으로 한 웹 프로그램을 개발한다는 말로 인식하기 때문에, 이는 기존의 방식과 별반 차이가 없어 보인다. 그러나 해결해야할 문제로 떠오르고 있는 것이 있다. 이전에는 우리의 인터넷 환경은 단지 마이크로 소프트사의 IE 6.0을 기준으로 웹 사이트를 만들고 CSS와 Javascript를 적용하는 것으로 호환성을 고객에게 제공한다고 생각하였다. 물론 이때는 지금의 javascript와는 다른 VBscript와 Jscript를 사용하기도 했다. 마이크로 소프트사의 90%가 넘는 절대적인 시장점유율이 불러온 결과로 웹을 이용한 서비스를 제공하는 포털과 개발자는 단지 IE에서 정상적으로 동작하는 웹 어플리케이션을 만들고 배포하면 그만이었다. W3C의 Web기술 권고안을 따르지 않고 IE의 시장 점유율에 지원하고자 하는 Web Browser를 쉽게 결정한 이유는 너무나도 단순하다. 개발비와 유지보수비를 줄이려는 욕구 때문이다. 때문에 대다수의 사용자가 사용하는 IE만 지원하면, 다른 브라우져와의 호환성 테스트와 개발 및 수정에 필요한 비용들 그리고 유지 보수에 대한 비용들을 추가적으로 지불하지 않아도 되기 때문이었다.

그러나 현재의 상황을 다르다. 마이크로 소프트사가 웹 브라우져의 개발에 대한 지원이 몇년가 전무한 상태에서 Firefox와 사파리 브라우져는 깊게 갈린 칼로 무장하고 대중의 앞에 나섰고, 상당한 성과를 올리는 중이다.
그리고, 새로운 기술과 기능들을 경쟁적으로 추가하고, 이를 구현한 새로운 버전의 브라우져를 사용자들에게 수시로 발표하고 있는 상황이다.

문제는 새롭게 시장 점유율을 높여가는 브라유져와 새로운 기능들을 추가할 때마다 나오는 브라우져간의 호환성이 항상 유지되어야 하는데, 꼭 그렇지 많은 않다는 것이다.
IE의 경우는 IE 6, IE7 그리고 얼마전에 발표된 IE 8 사이에서도 동일한 페이지를 전혀 다르게 표시를 해주고 있다.
사파리 브라우저의 경우도 마찬가지이이다. Safari 2와 3가 혼재되어 사용되고 있고, Safari 4에 베타 버전 이야기도 최근이 심심치 않게 들리고 있다. Firefox의 경우는 어떠한가? 이 역시 버전 firefox 2와 3를 같이 사용하고 있는 것이 현실이다.

최근 브라우져들은 속도를 개선하고 자기들이 가장 빠른 브라우져라고 자랑하고 있고, 사용자들은 최고의 브라우져를 골라서 사용할 수 있지만, 개발자 입장에서는 결코 행복한 상황만은 아니며, 새로운 고민에 빠져가고 있는 상황이다.
거기다 모바일 브라우져를 지원해야만 하는 상황에서는 좀더 문제가 복잡해 진다.
구현의 이슈를 뒤로하더라도, 이들 모두를 제대로 지원하기 위해서는 많은 시간과 추가적인 비용에 대한 문제가 있기 때문에 좀더 많은 고민들을 해야할 이유가 생겨나는 것이다.

이러한 이유들로 Flash와 Silverlight와 같은 RIA 기술들을 사용해야 하는 하는 것이다.
사실 이는 웹 표준과는 다른 기술들이고, 다른 방향에서 발전해 왔다. 하지만 Platform 독립적으로 동작할수 있도록 자신만의 컨테이너를 제공하기 때문에, 개발자에게는 동일한 실행 환경을 제공하게 되고, 이 위에서 개발을 진행하면 되기 때문이다.
  
개발과 비용과 유지보수의 이슈는 RIA를 사용하고 도입해야할 또 하나의 이유를 주고 있다.
 

얼마전에 Ruby on Rails를 2.2.2하였었는데, 오늘 또 2.3.2버전으로 update하였다.
이전에도 2.3버전이 곧 나올거라는 것은 알고 있었고, RubyOnRails사이트에서 보여지는 개발문서들은 2.3 버전을 기준으로 외부로 공개되었었다.(2.3버전을 기준으로 쓰여졌다는 말임)

Rails 2.2.2를 2.3.2 버전으로 업그레이드 하는 것은 아주쉽다. 이미 여러차례 gem을 이용하여 플러그인들과 Library들을 설치해본 경험이 있기때문이고, 쉬운 사용법 때문이다.

내가 작년에 진행했던 프로젝트는 나른대로 처움에 잡았던 컨셉과 기능들이 잘 설계되었다고 생각하였다.
하지만 개발자들의 빠르게 효율적으로 만들어주고, 좀 더 쉽게 개발할 수 있도록 도와주려 했넌 나의 생각은 여지없이 무너지고, 결국 EJB에 버금가는 또 하나의 무거운 괴물을 만든것이 아닌가라는 생각이 자주든다.

개발과 테스트 그리고 배포시의 패키지 또는 개발된 리소스를 이용하는 방법은 달라야한다.
Rails에서 배포는 gem을 이용하는데, 개인적으로는 간단하고 단순한것이 마음에 든다.

기본적으로 Gem을 이용하기 때문에 최신 버전을 받는것은 간략하게 "gem install rails" 라고 Command창에서 실행하기만 하면 된다.
이를 실행하기 전에 현재 설치 되어 있는 Rails 버전을 아래과 같이 확인할 수 있다. 
명령창에 "rails -v" 라고 입력하고 실행하면 된다.
  

현재 설치 되어 있는 Rails의 버전은 2.2.2 이다. 이제 새로 배포되기 시작한 Rails 2.3.2를 설치할 텐데, 위에서 한번 언급했던 "gem install rails"라고 실행을 하거나 "gem install rails -y"을  주고 실행을 시키면 된다. 이때 사용하는 "-y" 옵션은 설치에 필요한 패키지들에 대한 dependency가 있는 모듈 역시 자동으로 설치하도록 도와준다.
여기서는 위의 그래에서 처럼 "-y" 옵션을 사용하여 "gem install -y"를 명령행에서 실행시켰다. (아래 그림 참조)


설치 명령에 따라서, 업그레이드에 필요한 Rails의 필수 6개의 피키지들이 위와 같이 설치가 되고 있다. 먼저 기본 6개의 패키지들이 설치가 되고, 이어서 필요한 문서들이 함께 설치가 되고 있는 중이다.

Rails와 문서들의 설치가 완료되면, 아래와 같이 Rails의 버전을 확인해서 설치가 정상적으로 완되되었는지 다시 한번 확인하면 설치는 마무리 된다.

지난 몇주 동안 Ruby on Rails를 가지고 이것 저것 테스트도 하고 공부를 하고 있는 중이다. 그리고 RedRails 플러그인을 Eclipse에 설치하여 몇가지 셈플도 만들어 보았는데, 예전에 사용해 보았던 RedRails 0.8, 0.9 버전보다 사용하기도 편해졌고, Console창에서 Scaffolding을 이용하여 파일을 생성하는 것보다 더 가볍고 빠르다는 느낌이 든다.
이는 아마도 백그라운드에서 Ruby이 VM이 떠 있는 상태에서 실행되기 때문일거라 생각된다.
Console창으로 Rails를 실행하는데 익숙한 개발자를 위하여, RedRails는 Console 모드를 추가되었다.

RedRails를 설치하는 방법에 대해서 간략하게 설명하려고 하는데, 다음과 같은 순서로 진행하면 된다.

RedRails는 http://www.aptana.com/에서 다운을 받아 독립적으로 실행되는 프로그램으로 설치하거나 Eclipse의 Plugin형태로 설치가 가능하다.
윈래 RadRails는 개인 개발자가 혼자 개발하다고, Aptana라는 회사로 이적하면서, 개발되고 수정되고 있는, 공개 Plugin인데, Aptana라는 회사는 웹 개발을 위한 개발 툴과 Eclipse 플러그인을 개발하고 있는 회사로, 툴들이 제법 사용할 만한 가치가 있다. 

먼저 http://www.aptana.com/studio/download 로 이동해서, 설치 버튼을 누르면, 플러그인 설치를 위한 설명 페이지로 이동하게 된다.  Eclipse에서 RedRails 플로그인을 설치하기 위해서는 먼저 Aptana Studio를 설치해야 하는데, 이는 Eclipse의 Help > Software Update... 메뉴를 선택하면 아래와 같은 화면이 나타나는데, 차의 우측의 Add Site...버튼을 클릭하고 Remote Update를 위해서 다음과 같은 URL을 입력 필드에 입넣어주고 저장한후 상단의 Install...버튼을 클릭하여 실행을 시켜면 아래 그림과 같이 진행이 될 것이다. 
        * Add Site...:   http://d3kp2jit5ckrb9.cloudfront.net/3.2/ 
         

설치할 Plugin들을 다운로드하면 아래와 같이 설치 항목들을 확인하는 창이 나타난다. 당연히 "NENT"버튼을 클릭해서 다음 단계로 넘어간다.
 

그러면, 아래와 같은 화면이 나타나는데, 라이센스에 관련된 내용이므로 동의하고 다음단계로 넘어가면 된다.


위 그림에서 "Finish"버튼을 누르면, 설치가 진행된다.



설치가 완료 되면 아래와 같은 창이 나타나는데, "Yes"버튼을 클릭하여, Eclipse를 재 시작 시킨다.


Elipse를 재 시작하고, Aptana Studio를 시작한다. (만약, 직접 실행이 되지 않았다면, Eclipse의 우측 상단에서 Apatana Perspective를 선택하면 된다.)
그리고, 상단의 메뉴를 보면 아래와 같은 메뉴텝이 있는데, 여기서 두번째 메뉴 아이템을 클릭하면, Aptana의 설치 가능한 Plugins Manager 윈도우가 나타난다.


아래과 같이 Plugins Manager윈도우가 나타나면, "Install"텝을 선택하고 보면, 리스트에 Aptana ReadRails라는 플러그인이 보인 것이다. (아래 그림 참조)

설치하려고 하는 Plugin에 마우스 오른쪽 버튼을 클릭하고, Context메뉴에서 Install을 선택한다. (여기서 우리는 Aptana RedRails를 선택한다. 이유는 다들 알겠지요. 우리는 RedRails 플러그인 설치하려고 여기까지 왔습니다. ^^)

여기까지 잘 따라왔으면, 아래와 같은 창이 나타나는 것이 보게될 것이다.
각 항목들을 모두 체크해 주고,  화면 아래에 있는 "Next"버튼을 클릭하여 다음 단계로 이동한다.

위에서 처럼 Plugin을 설치하게 되면, 처음에 Aptana Studio Plugin을 설치했을 때 처럼, Eclipse를 재 시작을 확인하는 윈도우가 나타나게 되는데, "Yes"를 눌러 재시작을 시키면 된다.


Eclipse가 정상적으로 재시작하자마다, 아래의 창이 나타남을 볼수 있을 것이다.
화면 하단의 Install버튼을 눌러 Ruby와 RedRails를 위한 gem들을 설치하면 Rails를 사용하기 위한 모든 준비가 마쳐지게 된다.



주의 사항으로는 만약 Ecllise가 설치된 경로에 한글이 포함되어 있으면, Aptana Studio 플러그인이 정상적으로 설치가 되지 않는다. 나도 몇번을 설치하다가 결국을 Eclipse 경로를 "C:\" 아래로 바꾸었다. (이는 이전 버전에서는 없었던 문제이다. )

RedRails를 설치하면, 실망할 일은 별로 없을 것이다. 오히려 개발하는데 여러 모로 편리함을 주기때문에 편리하다. 특히 Javascript 코딩을 하거나, SVN을 연동할 일이 있다면, 이는 정말 Eclipse가 잘 하는 장르 중에 하나이다.

여담인데, 오늘 SVN없이 작업하다가 셈플 코드를 모두 날렸다. 결국 SVN Eclipse plugin을 설치하고 나서야 안심이 되었다. 이 플러그인역시 위에 있는 화면중에 하나인 plugin Manager를 통해서 설치했다. 나의 경우는 SubClipse Plugin을 설치했다.