Rhio.Kim's Blog - drawing Laputa Web -

CRUD(create read update delete) Pattern정의

이번 패턴을 정리하면서 어떤 이름을 지어볼까 매우 고민 스러웠습니다.
마땅한 이름도 생각이 나질 않고...

CRUD pattern 이라고 명명 했지만 처음 이름은 XHR pattern 이였는데..
문서의 흐름과 맞지 않는 것 같기도 하고...(혼자만의 가비지...)

자세한 사항은 첨부 파일을 예제소스는 example.js 파일을..
prototype.js 를 자주 활용하다보니 예제 또한...

모티브 :
웹 페이지에서 일어나는 사용자의 단일 액션에 대응하는 일련의 프로세스를 하나의 클래스에서 구현한다.  일련의 프로세스는 사용자가 서버에 요청을 하기 위해서 클릭을 한다거나 입력을 하고 요청을 하고 그에 따른 서버 측에서 처리가 이루어지고 처리 결과를 다시 사용자의 브라우저에 통보를 하고 브라우저는 결과를 통해 사용자에게 결과를 인식 시키는 일련의 작업을 말합니다.  

목적 및 장점 :
1.    CRUD(Create, Read, Update, Delete) 인터랙션에 대한 처리와 시스템 장애에 대한 빠른 문제 파악과 대응

조건 :
1.    XHR Wrapped클래스가 존재하여야 한다. (prototype.js, dojo, jQuery, etc)
2.    XHR 오브젝트를 이용한 데이터 처리가 있어야 한다.
3.    요청을 위한 단계와 응답에 대한 처리 단계가 간단하고 명료해야 한다.

제약 :
1.    복잡한 UI 처리 및 CRUD이외의 처리가 다소 병행되어 진다면 클래스 혹은 객체가 무거워질 수 있다.

단점 :
1.    특정한 인터랙션 위한 패턴으로 확장(extend) 및 소스 재사용 면에서 용이하지 못함





요약

Ajax을 통한 개발에 있어서 사용자의 경험(user experience)은 매우 중요해졌습니다.  그만큼 사용자의 액션도 다양해졌고 매우 고급스럽게 바뀌어 가고 있습니다.  간단하게 인디케이터만 봐도 그렇습니다.  예전 Web1.0 방식에서는 웹 서버의 부하로 페이지가 열리지 않을 때 사용자는 단지 White Background 즉 아무것도 없는 하얀 백지 상태의 화면만 주시하고 있었어야 했습니다.

하지만 현재에는 인디케이터를 통해 사용자의 요청에 대한 진행 상황을 유연하게 표현함으로써 사용자의 경험을 존중해 줍니다.

이렇게 복잡해진 부분도 있지만 사용자 요청에 대한 대부분은 서버로부터 데이터를 요청하거나 입력, 갱신, 삭제에 대한 경우입니다.  요청에 대한 응답에 있어서 그 처리가 간단하고 명료한 시스템이라면 CRUD 패턴을 이용해서 하나의 요청과 하나의 응답에 대한 처리를 하나의 클래스에서 처리한다면 시스템의 장애가 발생 시 어떤 부분 즉 어떤 사용자 액션에서 발생했는지 쉽게 파악하고 대응할 수 있게 됩니다.

하지만 설계 면에 있어서 향후 시스템의 확장이 있을 경우나 사용자의 액션에 대한 처리가 복잡해지게 되면 대응하더라도 설계 구조 자체를 뒤바꿔 할 여지가 다분해 보입니다.

실제로 저는 BBS나 콘텐트의 댓글 시스템에 이전에 포스팅 한 Design by Design Pattern 과 함께 CRUD Pattern을 이용하여 개발을 했습니다.  유지 보수가 발생하지 않아서 효율 및 실무에 적용할 만한 패턴인지 증명되지는 않았습니다.

이 내용은Ajax/Rich UI의 특정한 개발을 위한 방법론에 가깝다고 봐도 무방합니다.  또한 개인적인 경험에 의한 정리이며 일반적인 시스템 설계에서 말하는 패턴의 정의와는 상이하거나 다른 의미를 갖을 수 있습니다.

Design by Design Pattern정의


모티브 :
HTML 디자인을 개발자에 의해서 동적으로 생성되도록 처리하려면 개발자에 의해서 디자인을 javascript의 정해진 변수에 넣고 프로세서에 맞춰 필요한 디자인을 Document에 렌더링을 해야합니다.  유지보수 시 디자인적인 추가 요소가 발생할 경우 개발자가 디자인을 수정하거나 편집해야 하는 일이 발생한다.

목적 및 장점 :

조건 :


제약 :

단점 :


좀더 자세한 패턴에 대한 설명은 PDF 문서에 담았습니다.

이 내용은Ajax/Rich UI의 특정한 개발을 위한 방법론에 가깝다고 봐도 무방합니다.  또한 개인적인 경험에 의한 정리이며 일반적인 시스템 설계에서 말하는 패턴의 정의와는 상이하거나 다른 의미를 갖을 수 있습니다.

ExtJS의 기본 이해하기 ( Component Class의 inheritance 구현 및 계층 구조의 이해 )

Ext.data.Connection = function(config){ Ext.apply(this, config); this.addEvents( "beforerequest", "requestcomplete", "requestexception" ); Ext.data.Connection.superclass.constructor.call(this); };

Ext.data.Connection 는 ExtJS의 Rmote server에 XHR Request를 위한 class이자 namespace 입니다.
ExtJS의 모든 Class는 Ext의 하위 패키지 그 안의 서브 클래스들로 구성되어 집니다.  이때 위 처럼 클래스들이 생성되어서 동작하기 위해서 기본적으로 하는 처리가 있습니다.


위의 소스를 간단하게 보겠습니다.
Ext.data.Connection 는 function 을 갖습니다. 첫번째 인자료 config 라는 Hash 형태의 오브젝트를 갖습니다.

Hash 형태의 오브젝트란? 
{ key : value }의 형태를 말하고 이해를 돕기 위해 Hash형 오브젝트라 칭합니다.
Hash형 오브젝트 타입은 value에는 다양한 type의 값이 올 수 있습니다.

이는 사용 시 new 연산자를 이용하여 인스턴스화 되게 됩니다.
즉 Ext.data.Connection은 function으로의 기능이 아닌 instance 화 되어 사용되게 됩니다.

그러면 인스턴스가 생성될 때 수행되는 컨텍스트를 봅니다.

Ext.apply(this, config); 는 아래의 Ext의 맴버로서 수행되어집니다.

/** * Copies all the properties of config to obj. * @param {Object} obj The receiver of the properties * @param {Object} config The source of the properties * @param {Object} defaults A different object that will also be applied for default values * @return {Object} returns obj * @member Ext apply */ Ext.apply = function(o, c, defaults){ if(defaults){ // no "this" reference for friendly out of scope calls Ext.apply(o, defaults); } if(o && c && typeof c == 'object'){ for(var p in c){ o[p] = c[p]; } } return o; };

위의 apply에 의해서 this에 config로 넘겨준 값이 모두 overwrite 되게 됩니다. this가 가지고 있던 속성 및 메서드까지 모두 config가 가지고 있던 값으로 치환되어집니다.

이때 apply 에 첫번째 인자로 주는 config 는 ExtJS에서는 해당 클래스가 갖는 속성의 의미와도 같습니다.

좀더 쉽게 풀이해서 쓴다면 ExtJS의 하나의 클래스가 인스턴스화 되어질 때 기본적으로 갖게 되는 속성 그리고 상속구조가 형성되면서 override 되는 속성과 메서드들의 기본 설정을 합니다.

좀더 쉬운 예를 들어보면 하나의 widget이 생성되어 브라우저에 띄울 때 그 widget의 기본 사이즈, 드래그 앤 드랍 등을 할 수 있는 설정을 이 config에 Hash 오브젝트로 넘겨주는 초기 설정값과도 같습니다.

this.addEvents( "beforerequest", "requestcomplete", "requestexception" );

이 코드는 이벤트 리스너를 설정하게 됩니다.  최근에 릴리즈한 자바스크립트 프레임웍에는 Custom Event가 모두 지원하고 있습니다. 

ExtJS에서도 이를 지원하는데요. 이는 Observable class에 있습니다. 
위의 코드는 이 Ext.data.Connection 이 인스턴스화 될 때 사용하게 될 기본적인 이벤트 리스너에 해당하는 것들입니다.

위에 잠깐 예시를 들었던 widget 에서는 기본적으로 widget을 움직일 수 있고 최소화 시킬 수 있는 기능을 기본적으로 갖게 됩니다.  경우에 따라서는 숨길 수 있는 기능이나 최대화 기능도 부여할 수 있습니다.  이처럼 this.addEvent를 통해서 Ext.data.Connection 이 갖는 기본적인 이벤트 리스너를 등록하게 됩니다.

XMLHttpRequest 를 통해서 서버측 데이터를 받아올 때 혹은 받을때 받고나서 등등 다양한 상황에 맞는 이벤트 리스너를 사용하기에 앞서 Connection 클래스가 기본적으로 갖게되는 이벤트 리스너를 설정해 주게 됩니다.  위의 경우 ‘beforerequest’, ‘requestcomplete’, ‘requestexception’ 3가지의 리스너를 설정하게 됩니다.

이렇게 설정된 리스너는 fireEvent 메서드 즉 핸들러를 수행하게 됩니다.

마지막 구문

Ext.data.Connection.superclass.constructor.call(this);

상당히 길게 나열된 구조입니다. ExtJS의 가장 중요한 부분이라고 해도 과언이 아닙니다. 어떻게 해서 저렇게 긴 메서드가 생성되었을까요 간단하게 풀이해서 보도록 합니다.
Ext.data.Connection 이것은 굳이 Ext.data.Connection 이라고 하지 않고 this라고 해도 무방했을텐데 왜 그랬는지 살짝 궁금해집니다.

this를 쓰지 않았던(?) 못했던(?) 이유... 2008.05.18 추가

more..

그 다음에 오는 superclass 는 단연 계층 구조에 있어서 최상위 클래스, 부모 클래스를 나타낼 텐데요.  superclass.constructor 입니다.  즉 superclass 가 아닌 superclass의 constructor를 나타냅니다.  이는 인스턴스화 되지 않는 부모 클래스의 생성자를 참조하고 있습니다.

그런데 과연 superclass 라는 것은 원래 있는 것인지? 아니면 ExtJS에서 기본적으로 제공하는 것인지 의문이 듭니다. 이는 Ext.extend 맴버에 의해서 Ext.data.Connection 에 부여됩니다.

Ext.extend(Ext.data.Connection, Ext.util.Observable, { … });

잠시 extend 메서드에 대한 설명을 간단하게 하고 넘어갑니다.
extend 메서드는 YUI의 구조와 동일합니다. 첫번째 인자로 넘어간 오브젝트에 superclass 속성을 부여하여 두번째 인자의 prototype을 superclass 가 레퍼런스하도록 합니다.

즉 Ext.data.Connection.superclass는 Ext.util.Observable.prototype을 레퍼런스하게 됩니다. 곧 Ext.util.Observable 의 constructor를 call 메서드를 통하여 호출하게 됩니다. 메서드를 Ext.data.Connection Scope에서 수행하게 됩니다.

이는 생성되면서 addEvent 를 통해서 생성된 이벤트 리스너의 동작을 켭니다. 이 말은 addEvent를 통해서 추가된 리스너들은 단지 ExtJS의 이벤트 class에 이벤트 이름만 등록하고 실제로 Ext.data.Connection 이 인스턴스화 될 때 비로소 리스너가 작동이 가능하게 됩니다.

언제나 그렇듯 말로만 보면 쉽게 이런 구조가 이해되지 않아서 간략하게 나마 그림으로 표현해 봅니다.



어차피 그림 조차도 설명이네요. ^^;

Data Caching Structure in Ajax(XHR) Pattern

웹에서는 수 많은 페이지에서 서버에 수 많은 데이터를 요청합니다.
Web 2.0 이전 방식에서는 페이지가 링크를 통해 이동할 때마다 서버에 불필요한 데이터 요청을 하게 됩니다.

예를 들어서 어느 블로그나 카페에 컨텐츠를 구성하는 요소 중 카테고리와 게시판이 있습니다.
우리는 이 게시판에서 요구하는 것은 게시글의 제목을 눌렀을 때 그 게시글에 대한 상세한 정보입니다.

누가 작성하였고 등록된 날짜와 시간이 언제인지 그리고 그 게시글의 내용이 무엇인지 하지만 이전 방식은 화면이 리로딩 되면서 게시글 보기 페이지로 이동되면서 좌측 카테고리 목록도 서버에서 다시 요청하는 쿼리가 수행되고 화면 인터페이스를 구성하기 위한 여러가지 쿼리들이 함께 수행되게 됩니다.

이는 Web 2.0 방식에 좀더 정확한 표현으로 Ajax 개발에 있어서 비 효율적임을 알 수 있습니다.
이로서 우리가 생각해야 하는 것은 데이터 캐싱에 대한 구조입니다.

Javascript를 이용한 간단한 예제를 들어보자면 아래의 그림과 같습니다.


기본적인 user interface 를 구성하는 코드들에 서버에 비동기 데이터 요청을 하게되는 XMLHTTPRequest 가 있습니다. 그리고 서버 사이드에서 이 비동기 요청을 받아 DBMS에 해당 요청에 대한 쿼리만 수행하고 그 결과를 응답해줍니다.

이때 화면이 리로드 되지 않기 때문에 우리는 받아온 데이터를 javascript 의 variable 즉 local storage에 hash( { key : value } ) 형태로 데이터를 저장해 놓습니다.  이는 저장된 데이터를 활용해 동일한 데이터 요청을 하지 않게 됩니다.

위에서 보는 것처럼 XMLHTTPRequest가 request가 발생되었을 때 var storage 에 기존에 요청한 데이터가 존재하는지 체크하여 있으면 Server-side Script에 요청을 하게 되고 이미 존재한 경우에는 요청 없이 local storage에 이미 있는 데이터를 그대로 활용하게 됩니다.

이 데이터 캐싱 구조는 Ajax 개발에 있어 매우 중요하고 Ajax Application을 개발하는 목적을 달성시켜주는 패턴중에 하나라고 말할 수 있습니다.

간단한 예제 소스입니다.
@import prototype.js 1.5 var storage = {}; function login(userid, password) { if(storage[userid]) return storage[userid]; /* 기존 요청 데이터가 있으면 그 데이터를 반환 */ new Ajax.Request(‘server.php’, { method : ‘post’, parameters : { uid : userid, pass : password }, onSuccess : function(transport) { storage[userid] = transport.responseText; } } } login(‘rhio’, ‘38fal2’); login(‘ecmas4’, ‘3kkkajf’); alert($H(storage).inspect()); //->{ ‘rhio’:’rhio의 로그인 결과 정보’, ‘ecmas4’:’ecmas4의 로그인 결과 정보’ }
위의 예제처럼 storage에 서버에 요청했던 정보들을 저장해놓게 되면 재 요청이 이뤄지지 않고 기존 데이터를 그대로 활용할 수 있습니다.

하지만 단점은 한 페이지에서만 활용할 수 있으므로 화면이 리로드되거나 다른 페이지로 이동하게 되면 활용 할 수 없게 됩니다.

Firefox에서는 이를 session storage와 global storage로 storage 메커니즘을 지원하고 있습니다.

위의 예제는 session storage와 유사한 방식이며 global storage는 브라우저가 닫히기 전까지 사용할 수 있는 storage를 역할을 하고 있습니다.   하지만 현존하는 브라우저에서 모두 지원되는 메커니즘은 아닙니다.

  다양한 프레임웍(DOMAssistant 2.6, jQuery 1.2.3, Prototype 1.6.0.2, Mootools 1.2b2, ExtJS Core 2.0.1, YUI 2.4.1)들에 대한 셀렉터(Selector) 속도 및 유효성 테스트입니다.

  정확한 테스트와 상호 테스트간의 충돌을 방지하기 위해서 각각의 프레임웍 테스트를 각각의 아이프레임내에서 수행되도록 처리했네요. 최대한 정확한 테스트가 되기위해서 여러모로 신경을 썼다는 군요.


제 PC 에서 수행한 결과입니다.
DOMAssistant 2.6         1087ms
jQuery 1.2.3                  1454ms
Prototype 1.6.0.2      2324ms
Mootools 1.2b2             1578ms
ExtJS Core 2.0.1      617ms
YUI 2.4.1                      1789ms

테스트 결과가 생각과 많이 다르네요..
Prototype.js가 속도면이나 유효성면에서 제일 떨어지네요.  실망스럽네요. 하지만 다른 부분은 탄탄하게 구성되어있으니 element 찾을때 Selector를 이용해 접근하는 $$ 함수의 사용을 자재해야겠군요.

  반면 ExtJS는 그리드 기반의 Framework인데 Selector 부분을 신경을 많이 썼나보군요.
하기야 대부분 css 컨트롤을 통해서 그리드 구성을 할터이니 이부분도 상당히 신경을 썼겠죠..
내부 로직은 잘 모르겠지만 ExtJS가 Selector에서는 다른 Framewokr에 비해서 탁월한 성능을 보이는게 사실이네요.

테스트 사이트 : http://www.domassistant.com/slickspeed/

Mootools javascript 라이브러리를 이용하여 artViper designstudio team 에서 유동적인 효과는 만들었지만 Mootools 기반의 확장과는 다른 것들중의 일부 입니다.

artViper 사이트에 들어가면 다양한 Ajax 기반의 라이브러리들이 많이 있습니다.

mooColorFinder, mooAutoComplete, mooImageCrop, mooSocialize, mooInlineEditor, mooSecrueForm, mooTell-A-Friend, mooSlide 와 같은 다양한 라이브러리를 제공해주고 있습니다.

북마크 위젯은 상당히 호감가는 라이브러리이네요.
그외에 PHP로 구현한 다양한 라이브러리를 제공하고 있네요.

Paul Colton, Uri Sarid, Kevin Hakman 와의 인터뷰 내용입니다.

• Jaxer "server isde Ajax framework" 는 어떻게 생각해냈는지..
• server side Javascript framework과 Jaxer 의 차이점
• Jaxer의 작동 원리
• Jaxer 사용시 부작용
• 개발자들의 사용법
• Jaxer를 사용한다면 아키텍쳐의 변경 방법
• Javascript 2에 관해
• Jaxer의 향 후

media link : http://www.vimeo.com/698776/

좀더 안정된 Ajax 개발 Pattern - Dynamic rendering with many HTTP Request
javascript 가 document rendering 에 미치는 영향 과는 다른 부분에서 접근했습니다.

정리하고 있는 문서중의 일부를 적어봅니다.

아래 이미지와 같은 UI를 동적으로 구현하려 할때에 Image를 포함(document component)한 Dynamic Rendering에 의해 발생하는 HTTP Requests 와 관련한 내용입니다.

좌측 이미지와 같이 "HD", "▲", "▼"는 이미지로 구성되어져 있습니다.

"HD" 이미지는 2개 하지만 정적인 페이지를 요청한 것이라면 첫번째 요청한 이미지만 Requst Result가 200(Headers and content returned)이 발생하고 그외의 이미지는 304(Content read from browser cache)가 발생하게 됩니다. Static 페이지의 경우에는 캐시를 사용하게 됩니다.

그렇기 때문에 불필요한 작은 이미지 하나 때문에 HTTP Request 를 발생하지 않습니다.

또한 우측으로 보이는 "▲", "▼" 이미지 역시 "HD" 이미지와 동일합니다.

하지만 동적으로 rendering 하는 방식은 경우(innerHTML을 통하거나, 동적 element를 사용)에 따라 이미지 개수만큼 HTTP Request가 발생합니다.

첨부한 자료는 아래의 시나리오에 의해서 나타난 결과입니다.

시나리오

  1.    createElement 를 통해 수십개의 엘리먼트를 생성합니다.
  2.    CSS에 background : transparent url(‘image url’); 속성을 갖는 className을 생성해 놓는다.
  3.    해당 엘리먼트들에 생성해 놓은 className을 부여합니다.
  4.    생성된 엘리먼트를 appendChild로 document에 rendering 합니다.

TPuzzle 이후 새롭게 탄생할 TFastClick Ajax Game 입니다.
TPuzzle 는 Ajax로 구현된 네트워크 게임으로 만들어 보려는 목표가 있었으나 언젠지 모르게 제 관심밖으로 점점 멀어져 버렸습니다.

그래서 이번 게임은 매우 간단하면서도 "사람 짜증나게 하는 게임"입니다. 

플래시로 구현해놓은 게임이 있어서 짬을 내서 javascript 로 구현해보았습니다.

간단한 룰은 랜덤으로 생성되는 숫자를 순서대로 클릭하는 게임입니다.

생각보다 20초안에 성공하기는 쉽지가 않더군요. ^^;;
그래서 목표 "PlayTime"는 17초입니다.

사람의 눈과 사람의 뇌의 단순함을 느낍니다. ㅋㅋㅋ

아직 구현되지 않는 부분이 있어서 이번주 중에 공개할 예정입니다.

DB 연동으로 순위 저장이 되어야 하기 때문에 그부분 구현이 남아있고 Effect 부분이 빠져있어 아직 보잘 것 없습니다.

하지만 잘못하면 잘못하면... 빠져든다는 것.. 중독성이 강할지도 모르고 오기가 발동하여 회사에서 일하다 말고
17초라는 기록을 깨기 위해 점심시간에도 이것을 하고 있는 당신을 볼지도 모릅니다.

전적으로 이런분들은 건강에 해를 미칠 수도 있으며 그에 대한 책임은 절대로 본인에게 있습니다.