Rhio.Kim's Blog - drawing Laputa Web -

  근 한달 동안 소중한 책들이 연달아 시리즈로 출판되었습니다.  책들의 소개에 앞서 웹 개발에 대한 트랜드가 과연 어떻게 흘러갈까? 라는 생각을 문득하게 됩니다.  RIA 에 맞춰 다양한 언어에서 강력한 인터넷 어플리케이션을 만들 수 있도록 방향을 잡고 변화하고 있고 그에 MS, SUN, Adobe 에서도 다양한 방법과 기술을 제시하고 있습니다.


  MS, SUN 과 Adobe의  RIA 기술은 닷넷 프레임웍이나 SDK와 같은 Runtime 환경을 위한 배포의 정책을 함께 가져야 한다는 것이 단점이 될 수 있습니다.  배포라는 부분은 아직까지는 무시 못할 부분중에 하나이기 때문이죠. 허나 자바스크립트에 비하면 그 기술과 기능은 분명 월등합니다.  반면 자바스크립트는 그러한 부분이 전혀 없고 단지 브라우저가 지원하는 ECMAS262 표준과 각 브라우저의 JavaScript 엔진에 따라서 손쉽게 동작하고 있습니다.

그렇기 때문에 현재 국,내외를 불문하고 많은 사이트에서 자바스크립트 프레임웍을 사용하고 있습니다.  서로 나아가야 할 방향은 틀리기 때문에 서로 비교하는 것이 오류일 수도 있지만… ^^;

한가지 더 언급하면 MS, SUN, Adobe에서 제시하는 기술은 너무나 다양한 사용자의 환경, 인터넷 인프라에서 원활히 많은 기능을 충족 시키기에는 아직은 어려움이 있어 보입니다.  RIA의 모든 기능적 조건을 만족하기 위해서는 그만큼의 시스템 환경과 인터넷 인프라가 구축되어야 하지만 반면 국외의 경우 아직도 매우 낙후한 환경이 많이 존재한다는 것입니다.  
이에 경량의 자바스크립트 프레임웍은 낙후된 환경에서도 현재보다 진보된 기술과 기능을 제공하도록 발전해 가고 있습니다.  다가오고 있는 인터넷 환경의 Rich Application에 필요한 기술을 모두 갖출 수 있도록 발전해 나갈 수 있으리라 봅니다.


JavaScript 로 Ajax/Rich UI 실무와 연구(?)를 꾸준히 해오면서 힘들었던 것은 대부분의 자료가 외국 자료였고 자주 접하게 되는 프레임워크의 레퍼런스조차 국내화 되어있는 것이 턱없이 부족했었다.  이에 2006년 김영보선생님의 Prototype 프레임워크를 분석한 “Ajax Prototype.js 완전정복” 이라는 책을 시작으로 JavaScript의 관심도는 무척이나 높아졌던 것 같습니다.(개인적인 생각)

그 이후 꾀 오랜 시간이 흐르고 최근에 줄줄이 발간된 ‘JavaScript 완벽가이드’, ‘Prototype & Script.aculo.us’, ‘Pro JavaScript Techniques’, ‘jQuery in Action’ 자세히 보면 인사이트 출판사에서 웹이 나아갈 방향 아니 미래를 읽었을까?  




  연이어 출간된 서적들의 흐름을 보면 JavaScript의 원론을 파악할 수 있는 JavaScript 완벽가이드라는 책.  이는 JavaScript에 대해서 심도 있는 부분까지 알고 싶어했던 개발자라면 원서로 이미 접했을 만한 책이다.   또한 이 서적은 최근 5판까지 개정판이 원서로 나왔었고 3판까지 번역서가 출간된 이래 5판의 원서가 출간되지 꽤 오랜 후에 번역되었는데 원서를 보며 어려움을 겪던 개발자들에게 분명 단비와 같은 역할을 할 것이라 생각합니다.
  그리고 “오해가 깊은 자바스크립트”의 오해의 골을 풀어주지 않을까 생각하고 늘 바이블과 같은 역할을 해줄 것이라 믿습니다.




Pro JavaScript Techniques 는 초급을 넘어선 자바스크립트를 이용한 Ajax/Rich UI 개발을 해보았거나 jQuery, Prototype와 같은 프레임워크를 이용하면서 이들에 대한 기술적 의문을 갖었던 것들의 많은 부분을 해소시켜줄 수 있는 책이다.  

이 책의 서두 2부까지의 내용은 JavaScript의 가장 기본이며 자바스크립트에 대한 오해 즉 JavaScript 개발자가 갖는 오해의 많은 분들을 풀어줄 수 있는 내용을 담고 있습니다.  번역서가 나오기 전 원서를 통해서 내용을 접할 때는 확실한 의미 전달이 되지 않았었는데 이번 번역서를 계기로 명확한 의미를 이해할 수 있는 계기가 되었던 것 같습니다.

그리고 jQuery의 창시자인 존 레식(John Resig)은 본인이 갖은 노하우를 거침없이 독자(자바스크립트 개발자)에게 모든 것을 공유할 마음을 갖고 있는 것 같습니다.  그의 블로그를 통해서도 느낄 수 있지만 늘 열심히 새로운 기술에 대한 공유를 선두하고 있고 저 같은 경우에도 그런 열정을 많이 배우고 있습니다.  (각설하고)

책의 모든 내용을 설명으로 일관할 수 없지만 실무에서 JavaScript를 이용한 Ajax/Rich 개발을 하고 있는 분이라면 이 책을 38,939,392,391,382번 읽어 보시길 권장드립니다. (그 만큼 많이 읽어 보면서 의미를 되새길 만한 내용들이 매우 풍부합니다.)



  다음 소개할 책들은 아시는 분들은 아시겠지만 위의 책들의 내용이 지식으로 선행된다면 좀더 쉽게 다가올 수 있는 내용입니다.  ‘Prototype & Script.aculo.us’ 는 앞서 설명한 책들의 기술(자바스크립트의 다양한 기술)과 더불어 DOM, CSS 에 대한 지식이 함께 필요로 하는 책에 가깝습니다. 
  흔히 생각하는 레퍼런스 서적에는 조금 거리가 있지만 그 안에 숨어있는 사상과 특징들을 쉽게 파악하여 프레임웍 자체의 큰 그림을 그릴 수 있는 내용들로 이뤄져 있습니다.  또한 DOM, CSS에 대한 궁금증과 기술 학습에 절실함을 느끼게 될 지도 모릅니다.  Prototype을 통해 Script.aculo.us는 탄생한 것 처럼 Prototype을 이용해 ExtJS와 같은 Grid 프레임웍도 탄생할 수도 있는 확장성까지…

간단히 레퍼런스 가이드 역할을 넘어서 자바스크립트를 이용한 Ajax/Rich UI Application을 만드는데 큰 도움을 줄 것입니다.



jQuery in Action이라는 책은 읽어 보지 않아서 모르겠지만 국내에서 이미 jQuery 프레임웍을 사용한 서비스들이 곳곳에 있고 관심있는 개발자들도 상당한 것으로 알고 있다.  존 레식의 JavaScript의 노하우의 결정판이기 때문에 이를 통해 JavaScript와 DOM, CSS의 모든 기술적 이해를 위한 윤활유 역할을 분명 해줄 것이라 판단한다.  또한 책이 번역되기 위해 인사이트 출판사에서 뒷받침하고 있기 때문에 더욱 믿음이 간다.

이미 많이 나와있지만 레퍼런스가 없는 프레임워크(Dojo, Mootools, ExtJS 등)가 많습니다.  그에 반해 Prototype과 jQuery에 대해서는 국외를 포함 국내에도 많은 자료들을 얻을 수 있는 기회가 많아 졌습니다.  하지만 프레임워크을 이용하고 접근하는 것에 있어서 사상을 먼저 이해하려는 접근법이 매우 좋은 좋은 것 같습니다.(김영보 선생님께서 해주신 말입니다.)

자리잡아가고 변화하는 과정의 자바스크립트의 “Unobtrusive JavaScript” 번역하기 힘든 수식어 처럼, “오해가 깊은 언어”라는 관례적인 이해의 탈바꿈 과정에서 위의 책을 포함한 다양한 서적들이 많은 도움을 주리라 생각됩니다.  
  또한 JavaScript와 관련된 좋은 서적들이 더 많이 출간되었으면 좋겠습니다.

부제 : Javascript의 prototype은 어떤 의미를 갖는가?



그럼 오브젝트는 무엇일까요?

다시 MDC 에서 정의한 프로토타입에 대한 설명입니다.

Constructor

prototype 이라는 것은
javascript의 표준인 ECMAScript의 오브젝트 중 하나입니다.


이렇게 정의를 하고 계속해서 좀더 상세히 알아보도록 합니다.


ECMAScript는 C++, Smalltalk, Java 처럼 클래스의 개념이 존재하지 않지만 오히려 오브젝트를 위해 스토리지를 할당하고 그들의 프로퍼티에 초기값 할당을 통해 그것들의 일부 혹은 모든것을 초기화하는 실행 코드로 오브젝트를 만드는 생성자를 제공합니다.

생성자를 포함하는 모든 함수들은 오브젝트이지만 모든 오브젝트가 생성자가 되는 것은 아닙니다.

각각의 생성자^constructor는 프로토타입 기반^{prototype-based} 상속^inheritance과 공유^shared 프로퍼티^properties를 구현하기 위하여 프로토타입 프로퍼티 갖습니다.

오브젝트는 new 연산자에 생성자를 사용하여 생성되어짐 : 예를 들어 new String(“A String”)는 새로운 string 오브젝트를 생성합니다.

new를 사용하지 않고 생성자를 적용하는 것은 생성자에 따른 결과를 갖습니다.

예를 들어 String(“A String”) 는 초기 문자열이 만들어집니다. 하지만 오브젝트는 아닙니다.

ECMAScript는 프로토타입 기반^{prototype-based} 상속^inheritance을 지원합니다.

모든 생성자는 연관된 프로토타입을 가집니다. 그리고 생성자에 의해 생성되어진 모든 오브젝트는 생성자와 연관된 프로토타입(Object’s prototype 이라 불리우는)에 절대적인 레퍼런스를 갖습니다.

더욱이 프로토타입^prototype은 null이 아닌 원형^prototype에 절대적인 레퍼런스를 갖습니다. 그래서 이것을 프로토타입 체인^{prototype chain} 이라고 부릅니다.

오브젝트에서 레퍼런스^reference가 프로퍼티^property에 만들어 질 때 저 이름의 프로퍼티를 포함하는 프로토타입 체인^chain의 첫번째 오브젝트에 저 이름으로 프로퍼티를 갖는다.

바꿔 말하면,  

첫번째는 오브젝트가 직접 언급했던 프로퍼티가 있는지 없는지 조사(검토)하는 것입니다.  만약 오브젝트가 정해진 프로퍼티를 포함한다면 그 레퍼런스가 참조하는 프로퍼티입니다.  만약 그렇지 않다면 오브젝트는 찾기 위해서 다음 프로토타입^prototype으로 넘어간다. 

즉 위의 예제 소스를 예로 설명하자면 마지막에  childObject.name.toString(); 를 호출했습니다.
최초 childObject가 가지고 있는 name을 참조합니다. childObject에는 name 프로퍼티를 가지고 있기 때문에  toString()을 수행하게 됩니다. 만약 name 프로퍼티가 존재하지 않는다면 fatherObject -> grandFather -> Object 까지 찾아가게 되겠죠.

아무튼 name 프로퍼티가 존재하므로 childObject에는 toString()이라는 메서드를 수행하게 됩니다. 하지만 childObject 에는 toString() 이라는 메서드가 존재하지 않기 때문에 Object.prototype.toString()을 수행하게 됩니다. 만약 Object.prototype.toString 메서드가 존재하지 않는다면 당연히 (fireBug)toString is not a function 이라는 메세지를 보게되겠죠.

그래서 클래스 기반^class-based 객체 지향 언어는 일반적으로 인스턴스^instance에 의해 이동된 상태, 클래스에 의해서 이동된 메서드 그리고 상속은 구조와 습성의 유일함이다.

ECMAScript에서 상태와 메서드들은 오브젝트에 의해서 이동되어 집니다.  그리고 구조, 습성, 상태는 모두 상속되어 집니다.

직접 그것들의 프로토타입^prototype이 포함하는 특별한 프로퍼티^property를 포함하지 않는 모든 오브젝트들은 저 프로퍼티와 그 값^value을 공유한다.

아래 다이어그램을 참조

CF는 생성자 입니다(그리고 또한 오브젝트 입니다.).

다섯개의 오브젝트는 new 연산자를 통해 생성 : CF1, CF2, CF3, CF4, CF5

각각의 오브젝트는 q1, q2의 프로퍼티를 포함합니다. 점선 라인은 절대적인^implicit 프로토타입^prototype 관계; 예를 들어 CF3의 프로토타입은 CFp입니다.

그 생성자 CF는 자체적으로 CFp, CF1, CF2, CF3, CF4, CF5에 보이지 않는 2개의 프로퍼티를 갖습니다.

CFp 안에 CFp1 프로퍼티는 q1, q2 혹은 CFp1라 지정되지 않는 CFp의 절대적인 프로토타입 체인에서 발견되어지는 어떤 프로퍼티들 처럼 CF1, CF2, CF3, CF4, CF5에 의해서 공유되어 집니다.

CFp와 CF 사이에 절대적인 프로토타입 링크가 없다는 것을 알아야 합니다.

클래스 기반 언어들과는 달라 프로퍼티들은 값을 할당하는 것으로 오브젝트에 동적으로 추가될 수 있습니다.

즉 생성자는 생성되어진 오브젝트의 프로퍼티 일부분 혹은 전체에 이름과 값의 할당하는 것을 요구하지 않습니다.

위의 다이어그램에서, 한가지 CFp에 프로퍼티에 새로운 값을 할당하는 것에 의해 CF1, CF2, CF3, CF4, CF5를 위한 새로운 공유된 프로퍼티를 추가할 수 있다.

모두 ECMAScript 262-2 Spec 자료입니다.
중간에 번역의 이해를 돕고자 이미지화 하였습니다.  혹 이미지화 한 것이 혼동을 잃으킬 수도 있습니다. ^-^;
오역이 있을 수 있지만 최대한 번역에 대한 점검을 하였습니다. (외국에 살다온 직장 동료에게 검증을 받았습니다. ^^;;)

과연 자바스크립트 OOP에 대한 이해도를 조금 높히는데 도움이 될까 번역해 보았습니다.  경우에 따라 오역이 있을 수도 있습니다.  또한 완벽하지 않다는 말이 될 수도 있습니다.

원글은 아래 링크를 기재해 두었습니다.  이번 글을 개념적인 부분을 설명하고 있어 글로만 표현하였습니다.  이미지를 첨부해 좀더 이해도를 높이려고 했으나.. 힘들어서 포기 ^-^;

우리가 흔히 알고 있는 객체 지향 언어인 Java 와 C++ 의 간단한 비교가 아래부분의 표로 기재되어있습니다.   하지만 기재된 것이 차이점의 전부라고 할 수는 없습니다.

언어와 다른 언어를 비교해가며 OOP가 된다 안된다를 거론하지는 않았으면 합니다.
또한 어느 언어나 객체지향이 가능하다라고 말하고 싶습니다.  마지막으로 OOP에 대한 비교 우위를 따지는 것은 단지 수치화 해보고 싶은 마음에서만 하는것이 좋다고 생각합니다.

Java와 C++과 같은 클래스 기반 객체지향 언어는 두 가지의 뚜렷한 본질적인 개념을 갖는다.

클래스

인스턴스


클래스 정의

자바스크립트 같은 프로토타입 기반prototype-based 언어는 이렇게까지 구분하지 않습니다. : 단순히 오브젝트Object를 같습니다.

프로토타입 기반 언어는 prototype 오브젝트의 개념을 갖습니다.  개체를 사용하는 템플릿으로써 새로운 오브젝트를 위한 초기 프로퍼티를 얻기 위해 사용됩니다.

모든 오브젝트는 생성할 때나 런타임 때 자신의 속성을 지정할 수 있습니다. 또한 모든 오브젝트는 prototype 통해서 다른 오브젝트에 연결 될 수 있고 두 번째 오브젝트에 첫 번째 오브젝트의 프로퍼티를 공유하도록 허락합니다.

클래스 기반 언어, 별도의 클래스로 정의합니다.
이 정의는 여러분이 클래스의 인스턴스를 생성하기 위해서 특별한 메서드를 지정하고 생성자를 호출합니다.  생성자 메서드는 초기값을 지정할 수 있고 생성 주기에 다른 처리를 할 수 있습니다.

여러분은 클래스의 인스턴스를 생성하기 위해 생성자 함수와 관련된 new 오퍼레이터를 사용합니다.

자바스크립트 또한 같은 모델이지만 생성자로부터 별도의 클래스 정의를 갖지 않습니다.  대신에 사용자는 오브젝트를 생성하기 위해서 특정한 초기 프로퍼티와 값의 구성을 정의합니다.  모든 자바스크립트 함수는 생성자처럼 사용될 수 있습니다.  새로운 오브젝트를 만들기 위해서 new 오퍼레이터로 생성자 함수를 사용하면 됩니다.


서브클래스subclass와 상속inheritance

클래스 기반 언어는 클래스의 정의를 통해 클래스 계층hierarchy 구조를 만듭니다.  클래스의 정의에 이미 존재하는 클래스의 하위 클래스로 새로운 클래스를 지정할 수 있습니다.  서브 클래스는 슈퍼 클래스의 모든 속성을 상속 받습니다.  또한 추가적으로 새로운 속성을 부여하거나 상속 받은 것들 것 수정할 수도 있습니다.

예를 들어 직원 클래스는 이름과 부서의 속성만 갖고 하위 클래스인 관리자는 보고 속성을 추가합니다.  이 경우 관리자 클래스의 인스턴스는 세가지 모든(이름, 부서, 보고) 속성을 갖게 됩니다.

자바스크립트는 prototypical 오브젝트를 어떤 생성자 함수와 연결시키는 것을 통해서 상속을 구현한다.

그래서 직원-관리자 예제를 정확하게 만들 수 있습니다.  하지만 약간의 다른 용어를 사용합니다.  직원 생성자 함수를 정의하고 이름과 부서 속성을 지정합니다.  그런 다음 관리자 생성자 함수를 정의하고 보고서 속성을 지정합니다.  마지막으로 관리자 생성자 함수를 위해 prototype에 새로운 직원 오브젝트를 할당합니다.  여러분이 새로운 관리자를 생성할 때 직원 오브젝트로부터 이름과 부서의 속성을 상속 받습니다.


속성 추가addding 및 제거removing

클래스 기반 언어는 전형적으로 컴파일 될 때 클래스가 생성됩니다.  그렇지 않으면 클래스의 인스턴스는 컴파일 시간 또는 런타임 시에 인스턴스화 됩니다.  클래스의 정의된 후에는 클래스의 속성 타입이나 숫자를 변경할 수 없습니다.  그러나 자바스크립트에서는 런타임 시에 어떤 오브젝트의 속성을 추가하거나 삭제할 수 있습니다.
한 구성의 오브젝트를 위해 prototype으로 사용되는 오브젝트에 프로퍼티를 추가하면 그것이 프로토타입인 오브젝트들 또한 새로운 프로퍼티를 얻는다.

클래스 기반 (자바)	프로토 타입 – 기반 (자바 스크립트)
클래스와 인스턴스는 별개의 엔티티이다.	모든 오브젝트는 인스턴스이다.
인스턴스는 생성자 메서드와 갖는	생성자 함수를 갖는 일련의 오브젝트를 정의하고 생성
new 연산자로 단일 개체 생성	동일
기존 클래스들의 하위 클래스를 정의하기 위해 클래스 정의에 의한 오브젝트 계층 생성	생성자 함수와 관련되어 프로토타입으로 오브젝트를 할당하므로써 오브젝트의 계층구조를 생성
클래스 체인으로 프로퍼티 상속	프로토타입 체인에 따라 프로퍼티를 상속
클래스 정의는 클래스의 모든 인스턴스의 모든 속성을 지정합니다.  동적 런타임 시에는 속성을 추가할 수 없다.	생성자 함수 혹은 prototype은 일련의 속성을 지정합니다. 단일 오브젝트 혹은 일련의 오브젝트들에 동적인 메서드 추가 및 삭제할 수 있습니다.

참조 자료 : http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Class-Based_vs._Prototype-Based_Languages

Prototype 1.5.1.1 의 Ajax 중복 요청에 대한(XHR Request managment)를 만들어 보았습니다.
자세한 내용은 아래를 참고해 주세요.

  문제제기
    네트워크 병목 현상이나 서버의 부하로 인하여 XHR(XMLHTTPRequest)의 Response가 늦어져
    사용자에 의해서 동일한 중복 요청이 발생할 경우

    e.g) Ajax 게시판에서 사용자는 1페이지에서 2페이지로 이동하는 단계에서 요청한 2페이지의 결과가
           Response 되기 전에 3페이지를 누르는 경우 2페이지의 XHR는 의미 없는 요청이 된다.

  해결방안 모색
    new Ajax.Request가 발생한 다는 것은 Ajax.Request.initialize() 생성자 함수가 호출되면서
    XHR 이 Request를 발생시키는데 이때 아래 시나리오를 추가하여 해결한다.


  시나리오
    1. 현재 개발되어진 소스에 영향을 받으면 안된다.
    2. Ajax._observers 배열에 이미 요청중인 요청이 있는 체크하여 있다면 현재의 요청과 비교한다.
        만약 있다면 3, 없으면 6
    3. 다음 Ajax.Request가 동알한 url 로 생성되어 질때 이미 쌓아 놓은 배열에 동일한 URL로 요청중인
        XHR에 abort() 이벤트를 발생시켜준다.
    4. 해당 Ajax.Request 오브젝트는 null로 변경한다.(메모리 누수 발생 될 수 있음)
    5. abort가 발생한 Ajax.Request 오브젝트 레퍼런스는 배열에 splice로 삭제한다.
    6. new Ajax.Request() 가 발생할 때 Ajax.Request 오브젝트의 레퍼런스를 배열
        Ajax._observers에 쌓는다.
    7. 정상 완료된 Ajax.Request가 있다면 Ajax.Responder에 의해서 사용자 등록한 responders 배열 중
        해당 callback method "onComplete"를 호출한다.
    8. Ajax._observers에 쌓아두었던 Ajax.Request 오브젝트의 레퍼런스를 소멸시켜준다.

/** * @projectDescription Rhio Ajax Application 2008 * * @author rhio.kim@pandora.tv, tizie80@nate.com * @messanger (msn)kim2000version@hotmail.com, (nate)tizie80@nate.com * @site blog.ecmas4.com * @version 0.0.9 * @usage * * @sdoc * @namespace * @import */ Ajax._observers = []; Ajax.Request.prototype = Object.extend(Ajax.Request.prototype, { /* private * dulicated Request is aborting process * & push in Ajax._observers array * @param {string} url */ _manageDupleRequest: function(url) { var x = Ajax._observers; for(var i=0; i<x.length; i++) { var o = x[i]; if (o['url'] == url) { o.transport.abort(); o = null; /* referenced by Ajax._observers. So object reference is remove */ x.splice(i,1); break; } } x.push(this); }, /* Ajax.Request initialize method * call manageXHR * @param {string} url * @param {object} options */ initialize: function(url, options) { this.transport = Ajax.getTransport(); this.setOptions(options); this._manageDupleRequest(url); this.request(url); } }); /* onReadyState change responder callback methods * fire callback Event by reference to Ajax.Request.Events */ Ajax.Responders.register({ onComplete: function(transport) { var x = Ajax._observers; for(var i=0; i<x.length; i++) { var o = x[i]; if (o == transport) { o = null; x.splice(i,1); break; } } } });

  다양한 프레임웍(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/

Prototype Core team 멤버인 Tobie Lange씨는 Prototype 1.5 버젼 버젼에서 1.6으로 업그레이드 하려고 할때 API 변경이나 어떤 사용하지 못하는 것들에 대해서 경고해주는 스크립트를 개발하였습니다.

이 스크립트는 Firebug의 콘솔을 이용하기 때문에 Firebug에서만 동작을 합니다.


사용법은 1.5에서 1.6으로 변경할 페이지에서

1. prototype.js 를 추가한 태그 즉
   <script src="prototype.js"> 바로 아래로
2. deprecation.js 를 추가합니다.
   <script src="deprecation.js">
3. 그리고 디버깅과 함께 개발하면 됩니다.

이렇게 하면 위와 같은 console에 잘못 사용하거나, 변경되거나, 수정되거나 한 exception message가 계속 쌓입니다. 

개발은 계속 하되 단지 console의 로그 메세지만 출력하지 않을 거라면..

4. DeprecationNotifier.logDeprecation = false; 로 하면 log가 남지 않습니다.

원      문 : http://prototypejs.org/2008/2/12/deprecation-js-easing-the-1-5-1-6-transition
다운로드 : http://prototypejs.org/assets/2008/2/12/deprecation.js

PBwiki 팀의 Brian Klug 씨는 자바스크립트(javascript) 라이브러리 제공에 대해 좀더 자세히 배우기 위해서

자바스크립트(javascript) 라이브러리 테스트를 Dojo, jQuery, Prototype, YUI, Prototculous 를 로딩해서 만들었네요. 

azki 님이 이런쪽에 관심이 많을것 같은데요?? 그런가요?? ^-^

이 테스트는 압축(packed)과 최소화(minified), gzip 과 gzip 하지 않았을때, 캐시 기타 등등 테스트에

속해있습니다.   흥미로운 결과중에 하나가.. 압축(packed)를 사용하지 말라는 것입니다.. ^^;;

테스트 써머리 페이지 http://jst.pbwiki.com/summary.php


Result Calculus (cached, gzipped, minified)

자바스크립트 Alert 창과 Confirm 창을 하나로 합쳤습니다.
(약장수 버젼)자자 날마다 오는 소스가 아닙니다. 어딘가에 이미 나와있는 소스일지도 모릅니다.
그래도 아주 유용하게 쓰일 수 있다는 것, 안써본 사람은 몰라 alert(''); 신공을...
정말 불편할땐 이 소스 상단에 카피하고 example 참고해서 써바.. 완전 편해....
/** * @projectDescription Rhio 2007 Ajax Application - TSimpleAlert&Confirm * * @author riho.kim@pandora.tv, tizie80@nate.com * @author site rhio.tistory.com * @version 0.0.01 * * @sdoc none; * @namespace TSimpleAlert&Confirm * @import none */ String.prototype.msg = function(fnc1, fnc2) { var __string = this; if (typeof fnc1 != 'function') { alert(__string); return; } (confirm(__string) == true) ? fnc1() : fnc2(); } /* example */ var str = '문자열을 바로 Alert창으로'; str.msg(); '경고창도 간단하게'.msg(); var yes = '확인'; var no = '취소'; function btn_yes() { alert(yes)}; function btn_no(){ alert(no)}; '어떤 버튼을 누를까요?'.msg(btn_yes, btn_no); 　 　
편하지 않아도 어쩔 수 없어요.. ^^;;

별거 아닙니다.
FF에는 파이어 버그가 있어서window.console.log('debug'); 로 디버깅 메세지를 쉽게 볼 수 있는데요.

IE, Opera, Safari(최근 버젼에서는 지원하죠?) 에서는 원활히 지원되지 않아서..

급작스럽게 만든 티가 엄청 납니다.. ^-^;
나만 쓸껀데 뭐 ㅎㅎㅎ

그럼 머한데 공개했냐..?
자랑하려구요 ㅠ.ㅠ

갑자기 만들걸 자랑한다고? 
그럼 어쩌라구요?



간단하게 String native에 추가를 해버렸습니다.

/** * @projectDescription Rhio 2007 Ajax Application - TSimpleDebugMessage * * @author riho.kim@pandora.tv, tizie80@nate.com * @author site rhio.tistory.com * @version 0.0.02 * @usage 'debug message'.log(5); * * @sdoc none; * @namespace TSimpleDebugMssage * @import none * @changlog * console.log(String(this)); */ String.prototype.log = function(time) { var time = time || 999; var css = 'border:3px solid #000; font-size:12px; '+ 'font-family:"tahoma"; z-index:999;'; if(window.console) console.log(String(this)); /* FireBug */ else { /* IE, Opera, Safari */ var debugWindow = document.getElementById('__rhioDebugWindow'); if (!debugWindow) { var oDiv = document.createElement('div'); oDiv.id = '__rhioDebugWindow'; oDiv.style.cssText = css; debugWindow = document.body.appendChild(oDiv); } debugWindow.innerHTML += this +'<br />'; window.setTimeout( function() { debugWindow.style.display = 'none'; }, time*1000 ); } return this; }
사용법은 매우 아니 너무 간단합니다.

document.body.innerHTML.log(); //-> document.body 의 innerHTML을 동적 생성된 div에 오랫동안 뿌립니다. document.body.innerHTML.log(1); //-> document.body 의 innerHTML을 동적 생성된 div에 1초동안 뿌리고 사라집니다. 'Rhio 2007 Ajax Application'.log(); //-> Rhio 2007 Ajax Application 을 동적 생성된 div에 오랫동안 뿌립니다.

John-David Dalton 씨는 최근(?) 업데이트된 120k가 넘는 Prototype.js 를 압축한 라이브러리를
구글 그룹스에 올렸네요.

1.4 버젼부터 대부분의 릴리즈 버젼을 압축하였네요.
용량은 상당히 많이 줄었네요..

Prototype’s lowest weighs in at 20.4kb.
Scriptaculous’ lowest weighs in at: 19.7kb.
Protoculous’ lowest weighs in at: 38.4kb.

또한 Script.aculos.us 와 Protoculous

http://groups.google.com/group/prototype-core
사실 오픈된 Compressor 를 적용시키면 에러가 많이 나는데 좋은 작업 해주었네요..