'Ajax'에 해당되는 글 38건

  1. 2009.03.04 후기 - 제 10회 한국 자바 컨퍼런스를 다녀와 II… (2)
  2. 2008.10.11 JavaScript Injection Attack
  3. 2008.10.03 JavaScript Game “Find Equal” (같은 그림 찾기) (2)
  4. 2008.08.19 Ajax/Rich UI 개발 방법론 - CRUD Pattern (6)
  5. 2008.07.01 Ajax/Rich UI 개발 방법론 - Design by Design Pattern (10)
  6. 2008.05.07 ExtJS 기본 이해하기 - I
  7. 2008.03.14 Data Caching Structure in Ajax(XHR) Pattern (2)
  8. 2008.02.22 slickspeed - speed/validity selectors test for frameworks
  9. 2008.02.20 Ajax-based social bookmark widget (Ajax 북마크 위젯)
  10. 2008.02.19 Aptana Jaxer Talk
  11. 2008.02.11 Dynamic rendering with many HTTP Request - anti pattern
  12. 2008.02.10 이건 과연 뭐에 쓰는 물건인고? (2)
  13. 2008.01.31 Rhio Ajax Game - TFastClick v0.1.0 (5)
  14. 2008.01.28 Ajax Performance Issue - 에이잭스 퍼포먼스 문제
  15. 2008.01.22 YAHOO UI 2.4.0 - core 분석 발표자료.
  16. 2008.01.11 크로스 도메인 Ajax in FireFox 3
  17. 2008.01.01 High Performance Ajax Applications ( 고성능 에이잭스 어플리케이션 )
  18. 2007.12.18 Ajax Anti Pattern! 퍼포먼스 향상 (2)
  19. 2007.12.18 Ajax IM3.2 자바스크립트 버디버디
  20. 2007.12.18 2007 Ajax tool 사용률
  21. 2007.12.07 웹 2.0 에 더욱더 강력한 지원 - YSlow 0.9 Release
  22. 2007.12.03 Ajax connection module in 4 Huge Browsers(FF, IE, Opera, Safari) (3)
  23. 2007.11.30 닌텐도 사이트 런칭 with Dojo, Mootools
  24. 2007.11.29 깜찍한 캘린더 - MooTools Calendar Component
  25. 2007.11.28 Javascript Date 라이브러리 - Mad Cool Date Library (2)

부제 : RIA를 위한 JavaFX 그리고 그의 진화

첫번째 세션에는 Prototype.js 저자 이신 김영보 선생님의 MethodChain과 Ajax 애플리케이션 아키텍처에 대한 내용이였습니다. 

하나의 점으로 시작한 이번 PT는 원리와 개념적인 설명부터 이어졌고 작은 점 하나의 의미는 보는 사람들에 따라 다르고 이 점이 아키텍처에 비추어 설명해 주셨습니다.

 


좀 다른 면이 있지만 <쎙떽쥐페리의 어린왕자 中에서> 코끼리를 삼킨 보아뱀과도 같다 라는 느낌을 받았습니다.  

아키텍처의 본질은 작은 점으로 시작되었지만 그 깊이는 알 수 없이 깊어 수많은 문제점에서 유연하게 대처하고 그 넓이는 무한히 넓게 확장성을 갖어야 한다는 의미를 담고 있었던 거 같습니다.

“새소리, 물소리” 
군인은 지도를 보면 새소리와 물소리가 들려야 한다 라는 선임하사의 말을 연상하시며 역시 아키텍처에 사전적인 것이 아닌 본질을 이해하기 위한 설명이 이어졌습니다. 

이어 설명한 HTML, CSS, DOM, JavaScript, XML, JSON, Ajax 까지 Ajax Application를 위한 기본 도구(언어, 디자인 등)들이 갖는 일반적인 특징과 기술적인 특징에 대해서 간략하게 설명했고. Ajax Application에서 getElementById()가 갖는 개념에 대한 중요한 포인트를 지적하였는데 간단히 넘어가서 다시 한번 언급하자면

var dom = document.getElementById( ‘domBook’ ); 
위의 코드가 갖는 개념, 목적, 관련 기술에 대해 정확히 알아야 한다는 것 이였다.

짧고 간단하게 집고 넘어간 부분이지만 Ajax Application 개발에 있어서 가장 중요한 부분이라 생각합니다..  우리가 많이 사용하고 있는 Porototype, jQuery, Script.aculo.us와 같은 라이브러리들 역시 이런 도구들의 원리와 본질을 잘 파악하고 있고 발전에 잘 대응하고 있기 때문에 성공한 JavaScript 라이브러리도 탄생할 수 있었을 것입니다.

Framework의 범주는 주요 라이브러리들과 MethodChain에서 기술적으로 고려하였던 부분을 비교해서 간락햐게 설명하셨데 MethodChain도 범주에 속한 조건(?)들을 대부분 만족하고 있는 것 같습니다.  하지만 많은 라이브러리가 이미 기본 범주를 뛰어넘어 RIA를 위한 좀더 나은 프레임웍 이상으로 발전해가고 있죠.  빨리 MethodChian도 세계적인 라이브러리들에 동일 선상에 위치하도록 발전되었으면 하는 바램입니다.

이로써 국내 오픈 JavaScript 라이브러리가 3개가 되었습니다.
레이쥬님 swaf 2.0 - http://reizes.egloos.com/ (개발 중단 하신 듯)
김영보님 MethodChain - http://www.methodchain.com/ 

마지막으로 Framework의 핵심은 "접근성과 확장성" MethodChain이 풀어야할 숙제들 중에 하나가 아닐까 생각이 듭니다.   jQuery가 세계적인 라이브러리가 된 것은 바로 두 가지 “접근성”, “확장성” 의 두 마리 토끼를 잡기 위해 노력했기 때문일 것입니다.

jQuery의 문서화가 꾀 잘되어있고 이는 개발자들이 쉽게 개발에 참고할 수 있는데 큰 도움을 주엇습니다.  그로 많은 개발자들이 확장기능이나 플러그인을 개발하여 공유하는 커뮤니티가 형성되다 보니 점차 jQuery의 사용률은 높아갔던 것입니다.  더불어 노키아, MS 등과 같은 기업에서도 웹 런타임 환경으로 임베드 되는 것들이 jQuery를 세계적인 라이브러리로 만드는데 보탬이 되었습니다.

이번 1세션에서는 MethodChain 에 대한 기술적 이슈보다 Ajax Application 아키텍처에 대한 기본으로 가져야 할 사상에 대해서 좀더 이해할 수 있는 시간이 되지 않았나 싶습니다.  

다른 주요 라이브러리와 MethodChian에 기술적인 비교에 대한 내용이 이어졌지만 실제 구현이 아닌 Firebug를 통한 코드 Trace를 하여 설명하기가 난해하군요. ^^;

MethodChain를 포함 대부분의 JavaScript 라이브러리가 갖는 기능들 중 MethodChain이 다른 라이브러리들 보다 좀더 개선된 메커니즘을 갖는 다는 내용이였습니다.
PT자료를 보시면 어떤 부분에서 차이가 있는지 간략하게 정리가 되어있으니 좀더 자세한 내용은 JCO의 PT 자료를 참고하면 됩니다.

시간이 여유로웠다면 여러 JavaScript 라이브러리들의 차이점들에 대해서 자세히 알 수 있었을 텐데요. 아쉽습니다.



제 2세션 JavaFX : RIA를 위한 새로운 플랫폼
이번 세션을 많은 분들이 기대가 컸던 것 같습니다.  새로운 플랫폼에 대한 관심도도 관심도지만 발표자가 신상철 박사님이라는 것 때문이였는데요.  신상철 박사님의 히스토리를 보니 열정이 대단하신 분이라고 생각이 들었습니다.  이번 세션을 통해 처음 뵈었지만 발표하는 내내 정말 열정이 묻어 나왔던 시간이였습니다.  

모든 PT가 영어로 되어있고 중간 중간 영어를 사용하신다고 하시더니 문장만 영어가 아니였지 60~70%는 영어를 사용하시더군요.. 새로운 용어도 있어서 생소했지만 그래도 적응할 만 했습니다.

신상철 박사님은 http://www.javapassion.com 을 통해서 자세히 만나보실 수 있습니다.
대부분의 컨퍼런스 참여자가 개발자일 것이라는 배려로 개념적인 부분들은 중요한 부분만 집고 넘어갔습니다.  JCO의 PT자료를 참고하시면 JavaFX의 특징에 대해서 쉽게 이해하실 수 있고 위에서 언급한 사이트에서 JavaFX의 좀더 상세한 강좌를 볼 수 있다고 하니 관심있는 분이라면 꼭 챙겨 보시기 바랍니다.

 

JavaFX Script의 특징
• Declarative, statically-typed scripting language
• Facilitates rapid GUI development
• Many cool, interesting language features
• Runs on Virtual Machine for the Java™ platform
• Deployment options same as Java programs
• Fully utilizes Java class libraries behind the scenes
• For content designers and Media engineers

를 소개로 실제 구현을 위한 위의 내용을 세세히 설명해 나가기 시작했습니다.
JavaFX Script라고 해서 그런지 왠지 JSON(Javascript Object Notation)과 별반 달라 보이지 않았다. PT자료를 보시면 아시겠지만 표기법의 차이가 조금 있을 뿐 매우 흡사해 보였습니다.  그 뒤에 보지 못한 다양한 기술들이 있겠지만 ^^;

그외에 Binding 이라는 개념에 있어서는 Callback 함수와 유사한 느낌을 받았지만 JavaFX에서는 bind 라는 메커니즘을 사용한 것 같습니다.



PT자료 소스코드 발췌
// Code in the previous slide
// The bind keyword, placed just before the invocation of makePoint,
// binds the newly created Point object (pt) to the outcome of the
// makePoint function.
var myX = 3.0;
var myY = 3.0;
def pt = bind makePoint(myX, myY);
println(pt.x); // 3.0

myX = 10.0;
println(pt.x); // 10.0

scale = 2.0;
println(pt.x); // 20.0

특별히 어려운 점은 없어 보입니다.  매우 손쉽게 접근할 수 있지 않을까 생각이 듭니다.  그 뒤로 이어지는 구현 설명으로 NetBeans에서 실제 준비된 예제와 디버깅을 통해서 개발자들에게 매우 쉽게 설명해 주셨습니다.


마지막으로 가장 인상 깊었던 내용이였는데 JavaFX를 이용한 모션 트위닝(Motion Tweening)과 이펙트(Effect) 예시를 아주 세세히 모든 단계로 쪼개어서 보여주셨습니다.

예제 소스를 JCO에 올린다고 하셨던 것 같은데 잘 모르겠네요.  위에서 언급한 사이트에서도 보실 수 있다고 하니 예제는
 그곳을 통해서 받아서 보셔도 될 것 같네요.




PT자료 소스코드 발췌
import javafx.scene.paint.Color;
import javafx.scene.Scene;
import javafx.scene.shape.Circle;
import javafx.stage.Stage;

Stage {
   title: "My circle"
   width: 100
   height: 100
   scene: Scene {
     content: [
        Circle {
          centerX: 50,
          centerY: 50,
          radius: 40,
          fill: Color.RED
        }
     ]
   }
}


3번째 세션 : RIA Technology Introduction
좋은 내용의 발표 내용이 많았지만 발표장 인터넷 환경 때문인지 조금 어수선했음 발표자료가 올라오는 데로 좀더 요약해서 올릴 예정



마감하며….
일단 발표하신 모든 분들과 컨퍼런스를 준비하신 분들께 감사함을 전합니다.  이번 컨퍼런스를 통해서 RIA 플랫폼을 위한 Java의 변화와 기술에 대해 간략하게 알 수 있게 되었던 기회가 되었던 것 같습니다.  

아쉬운 점은 Java개발자들에게도 상당히 많은 웹 개발 이슈가 있을 텐데 Java의 RIA 관련 세션이 3개 밖에 되지 않았다는 것입니다.  아마 내년엔 Java와 RIA는 더욱 끈끈한 관계로 세션이 개설되리라 확신을 합니다.  
그리고 세션이 주제별로 분류되다 보니 둘 중에 하나는 포기해야 하는 문제도 생기더군요. 

내년 내 후년에는 좀더 발전된 모습으로 개발자들에게 좋은 내용으로 다시 볼 수 있으면 좋겠습니다.  경품은 좀더 많아지고 여성 개발자들도 더욱 많이 올 수 있는 이벤트도 좀 ^-^
웹 앱스콘에 비해 여성분들이 몹시 작음은 솔로 개발자들에게 JCO 컨퍼런스에 참가에 대한 동기 유발이 그만큼 작아진다는 것 -.-;

고무님 말씀 했던처럼 10년 후에는 가족들과 함께 모이려면 쏠로 탈출구가 되어야 되지 않을까요?  (잘못된 해석인지 알지만 ^-^;;)



신고
Posted by Rhio.kim
JavaScript Injection Attack - 자바스크립트 인젝션 공격

JavaScript 보안 관련 자료가 있어 번역하여 올립니다.
웹 기술의 변화와 관심이 달라지는 만큼 함께 신경써야 할 부분도 많아지고 그만큼 복잡해지나 봅니다.


최근 JavaScript 인젝션 공격이 유행하고 있습니다.  Malware 감염을 전파하는 효과적인 수단으로 이러한 종류의 공격을 활용하는 악성웨어들이 늘고 있다.

불과 1 년 전만해도 악의적인 공격자가 의지하고 있던 것은 공격용 Web 사이트를 가리키는 이메일, 검색 링크 또는 인스턴트 메시징 웜 등의 연결로 사람들을 유도하는 방식이었다.

지금은 JavaScript 인젝션 공격을 이용하여 Web 사이트의 방문자를 "납치"하고 만다. 이 공격은, 이른바 어둠 세계의 해커들이 악성웨어가 만연하도록 하는데 사용하는 맥가이버 칼과도 같다.


예시


우리는 다수의 높은 트래픽을 보았고, 합법적인 웹 사이트들은 이 기술을 이용해 공격을 받았다.  최근  알렉사 랭크 3172의 미국의 매우 유명한 게임 포털인 MegaGame도 하나의 예이다. 자바스크립트 인젝션 공격은 MegaGame 서버 중 하나의 서버에 몇 줄의 코드를 성공적으로 추가하였고 이 추가는 아무것도 모른체 웹 사이트를 접속한 방문자들을 악의적인 유럽 사이트로 이동시키고 악성웨어에 감염시키려 시도되었다.

그 악의적인 사이트는 두 가지 다른 방법을 통해 방문자들에게 공격을 시도하였다.  첫 번째는 Microsoft MDAC RDS.Dataspace ActiveX Control Remote Code Execution Vulnerability (MS06-014).
를 시도했다.

 


이 공격은 Microsoft's Internet Explorer (IE) 브라우저를 사용하는 방문자에게만 성공할 수 있었다.
왜냐하면 이 Web 사이트는 기본적으로 ActiveX 컨트롤의 사용을 요구하고 ActiveX 컨트롤 및 IE 간의 상호 작용에 존재하는 허점 (루프 홀)을 통해 원격으로 컴퓨터를 공중 납치하기 때문이다.

두 번째 공격은 다운로드 시 실행되고 IE뿐만 아니라 "Firefox"버전 1.0이 2.0이 대상이다. 이 공격에서는 JavaScript를 사용하여 Web 브라우저 종류를 확인하고 그 후에 미국 어도비 시스템의 Flash의 악용을 통해 공격에 대한 바이너리 파일을 PC에 다운로드하고 실행한다.

 


MegaGames의 Web 사이트는 여전히 감염된 상태. 불행히도 이것이 바로 현재의 상황을 말해 준다

인터넷 이용자의 대부분은 "pr0n"(포르노) 나 "warez"(와레즈 : 불법 복제 소프트웨어) 와 같은 계시의 위험이 높다.  (dodgy: 자못 의심스러운) Web 사이트를 방문한 경우 감염도 없다고 생각하고 듯하지만,  불행이도 그것은 잘못된 생각이다.

Malware 수법은 이전보다 성공화되고 있으며, 현재는 제대로 된 뉴스 사이트 및 비즈니스 관련 사이트도 감염되어있을 가능성이 있다.

"안전한 Web 사이트는 존재하지 않는다"는 것을 보여주는 또 경우가 BusinessWeek.com이다.  아주 정통으로 접근할 수가 많은 이 사이트가 SQL 주입 공격 타겟이 됐다.  이 같은 SQL 인젝션 공격이  JavaScript 인젝션 공격으로 연결 된다.

출처 : http://www.f-secure.com/weblog/archives/00001502.html


포스팅하려고 준비해 둔 JavaScript Injection 공격에 대한 자료를 첨부합니다.
상세한 자료는 아니고 아웃라인(흐름)에 대한 내용입니다.


신고
Posted by Rhio.kim

Find Equal게임이란?
  간단히 같은 이미지 찾기를 JavaScript로 개발한 게임입니다.

모티브
  외국 사람들도 JavaScript, SVG, Canvas를 이용해서 게임을 만드는데 국내 개발자도 알고리즘과 아이디어로 게임을 만들 수 있다는 것을 보여주고 싶어설까? 

  한가지 본연의 동기부여를 추가한다면 Ajax/Rich Application을 개발할 때 HTML 구조, CSS, JavaScript의 DOM과의 작동에 대한 잘된 설계와 UX(사용자 경험)가 잘 혼합된다면 어플리케이션의 성능 향상과 실 사용자(end user)에게 분명 유용한 서비스 혹은 어플리케이션이 된다는 것을 보여주고 싶어서입니다.

왜 그런지는 다음 설명들을 통해서 살펴 보겠습니다.


요구
1.    게임용 이미지 리소스는 요소별로 따로 관리하지 않고 게임에 필요한 리소스를 하나의 파일로 관리한다.
2.    HTML, CSS, JavaScript의 완벽한 구분을 꾀한 Unobtrusive JavaScript를 지향한다.
3.    DOM, CSS 제어를 위해 Prototype.js Framework를 사용한다.


구현 방식
요구사항
A.    게임을 구동하고 사용자가 사용함에 필요한 기본 리소스는 초기 HTML과 함께 로딩한다.
B.    초급자, 중급자, 고급자별 Game Panel의 요소의 개수는 변할 수 있다.
C.    다양한 이미지로 화면이 리프래쉬 되거나 유저에 의해 reset 버튼을 이용할 경우에 다양한 이미지를 제공하여 식상하지 않도록 한다.
D.    틀린 그림 찾기 게임의 룰을 만족시킨다.

첫번째 요구사항은 매우 간단합니다. 하지만 왜 이렇게 하는 이유는 알아야겠네요.

<img src=”image_resource.jpg” style=”display:none;” />


  이렇게 html 페이지에 위와 같이하게 되면 이미지 리소스는 화면상에 노출되지 않은 채 로딩됩니다. 이는 유저에 의해서 게임을 할 때 이미지 리소스를 가져오거나 잘못된 CSS Background-Image 속성을 사용하게 되면 동일 한 이미지를 캐시를 활용하지 못할 수가 있기 때문입니다.  그래서 미리 HTML에서 로딩을 하게 되면 캐시를 활용할 수 있어 게임 동작 시 성능을 향상할 수 있습니다.

사용자 삽입 이미지


  두번째 요구사항을 만족하기 위해서는 위의 Game Panel을 Table구조나 Div 구조로 개발되어야 합니다.  하지만 틀린 그림 특성상 Table 구조도 적합하기 때문에 Table 구조를 선택하였고 동적으로 n*n(cel * row) 의 table을 생성할 수 있도록 하였습니다.

  자! 지금부터 설명할 부분이 이 게임을 구현하는데 있어서 필수적인 요소가 되겠습니다.  위에서 언급한 개발 시 요구사항 부분에서 언급한 내용처럼 이미 게임의 동작을 위한 Image Resource는 미리 제작되어 있습니다.  이것은 위의 Game Panel의 TD에 들어갈 요소들로 요소 별 하나의 이미지가 아닌 이 게임(틀린 그림 찾기)에서 사용될 수 있는 모든 요소 이미지를 하나의 이미지로 만들었습니다.  다음 그림과 같아집니다.

 
사용자 삽입 이미지


  흐름과 틀리지만 예를 들어 위의 Game Panel의 Table을 동적으로 만들 때 TD에 blank 이미지를 설정해 놓고 클릭할 때 해당 blank 이미지에 JavaScript를 이용해 src 속성에 이미지의 위치를 지정하는 방식도 있습니다. 하지만 그렇게 하면 다양한 요구사항을 받아들이기가 어려워지고 원격지의 이미지를 HTTP를 통해 가져오는 동안 문제가 발생하는 경우 표시를 못하게 되거나 다양한 문제점이 게임 진행중에 발생할 수 있습니다.

  그래서 위의 이미지 리소스와 같이 하나의 이미지 파일에 다양한 요소를 지정해 놓았습니다.  적어도 게임이 진행중에는 오류로 인한 문제는 최소화 해야 하기 때문입니다.  만약 초기 로딩 시 이미지를 가져오지 못한 경우에는 체크해서 사용자에게 알려주어 게임 진행에 대한 상황을 사용자에게 전달 할 수 있습니다.

  그러면 이 하나의 이미지를 어떻게 Game Panel에 표시할 것인가가 문제입니다.  큰 문제는 아닙니다. 누구든지 아는 부분일 것입니다.

  이미 로딩된 Image Resource를 Game Panel의 각 요소(TD)에 Style 제어를 통해서 표시할 수 있습니다.
각 TD에 style.backgroundPosition = ‘-0px -0px’; 와 같은 방식으로 부여를 하면 됩니다.

 
사용자 삽입 이미지


  위의 좌표처럼 TD에 backgroundImage는 Image Resource로 설정해주고 backgroundPosition을 제어하면 하나의 이미지 리소스로 다양한 위치를 각 요소에 설정할 수 있습니다.

  마지막 요구사항은 각 요소에 표시될 이미지가 순차적이라면 틀린 그림 찾기의 게임 룰을 만족할 수 없기 때문에 이미지 리소스에 있는 이미지 요소들을 랜덤으로 Game Panel에 설정하는 부분만 처리하면 유저가 게임을 할 수 있는 기본적인 설정이 갖춰집니다.

랜덤 설정은 알고리즘이니 조금만 고민하면 위의 조건들을 만족하는 렌덤 배열을 생성할 수 있을 것입니다.

랜덤 배열 범위 = ( ImageResource 가로요소 개수 * ImageResource 세로요소 개수) – 1;

 
사용자 삽입 이미지


랜덤 배열의 범위 즉 [0, 1 ,…, 195] 를 random 알고리즘을 이용하여 뒤섞어 줍니다.

_random: function(arr){
	var i = arr.length;
	if (i == 0) 
		return false;
	
	while (--i) {
		var j = Math.floor(Math.random() * (i + 1));
		
		var ti = arr[i];
		var tj = arr[j];
		arr[i] = tj;
		arr[j] = ti;
	}
		
	return arr;
}


 섞여진 배열(return arr)은 Image Resource의 index를 가리킵니다.  즉 TD의 backgroundPositon 을 제어할 때 바로 이 섞여진 배열을 통해서 지정하게 됩니다.  하지만 틀린 그림 찾기는 위의 섞여진 배열로만은 이용할 수 없습니다. 

  Arr = [ 28, 13, 99, 2, 84, 50, 38 ];
  Arr = [ 28, 13, 99, 2, 84, 50, 38, 28, 13, 99, 2, 84, 50, 38 ];
  Arr = [ 84, 28, 38, 13, 2, 13, 84, 50, 2, 38, 28, 99, 99, 50 ];

위의 과정을 거치면 정말로 틀린 그림을 찾기의 배열 요소가 갖춰집니다.  이 배열을 이용해 Game Panel의 각 구성 요소에 Image를 지정할 때 Image Resource의 이미지 index와 매칭하여 Position을 TD의 CSS Style로 부여합니다.


요약
여기까지는 게임을 만들면서 생겼던 주요 이슈에 대한 정리입니다.  대단한 건 아니지만 여러 가지 이유는 숨어있습니다. 

요약해보자면 HTML에 미리 <img> 를 이용하여 Image Resource를 로딩한 이유 또한 이미지를 하나의 파일에 넣어둔 이유, CSS Style 제어를 통해서 이미지를 렌더링 한 이유 좀더 찾아보면 몇 가지가 더 있겠네요.

구현의 초점은 게임을 즐기는 유저에게 게임을 즐기는 동안에는 최대한의 성능과 오류가 발생할 요인을 최대한 줄이는데 있습니다.  간단한 게임을 가지고 복잡하게 설명한 건 아닌지.


웹 서비스도 마찬가지 입니다.  Ajax/Rich Application 개발 시에 간과해서는 안될 상황들이 매우 많습니다.  아시다시피 크로스 브라우징부터 검색에 노출에 대한 부분,  HTTP에 대한 이해, 다국어 지원 여부,  Embeding 에 대한 부분… 나열하자면 매우 많겠네요.

그만큼 단순 요구사항에 대한 구현이 아닌 웹 서비스에서는 다양한 환경과 사용자 경험에 대한 바탕으로 설계가 일차적으로 되고(머리 속의 설계도 좋을 것 같습니다.) 개발이 되어진다면 좋지 않을까요?

사용법
이미 TFindEqual.js 파일에 기본 설정값이 지정되어 있어서 4*6의 게임이 자동으로 생성됩니다. 개수를 늘리거나 줄이고 싶으면 row와 cel 속성을 수정해주면 됩니다. 나머지 속성은 고정된 속성입니다.
//기존 소스
var FindEqual = new TFindEqual(this);
Event.observe(window, 'load', FindEqual.set.bind(FindEqual));

//이렇게
var FindEqual = new TFindEqual(this, {
            target: 'panel', //Game Panel이 그려질 target 엘리먼트 id
            row:    4,    //게임 row 개수
            cel:    6,    //게임 cel 개수
            bgrow:    14,  //Image Resource 가로 개수
            bgcel:    14,  //Image Resource 세로 개수
            width:    57, //이미지 너비
            height:    56 //이미지 폭
        });
Event.observe(window, 'load', FindEqual.set.bind(FindEqual));


작성된 게임 소스와 작성된 PDF를 첨부합니다.

신고
Posted by Rhio.kim
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의 특정한 개발을 위한 방법론에 가깝다고 봐도 무방합니다.  또한 개인적인 경험에 의한 정리이며 일반적인 시스템 설계에서 말하는 패턴의 정의와는 상이하거나 다른 의미를 갖을 수 있습니다.

신고
Posted by Rhio.kim

Design by Design Pattern정의


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

목적 및 장점 :
1.    HTML로 구성되어진 레이아웃을 ( HTML 파일 자체를) 개발자에 의해서 추가되거나 수정되지 않는데 목적을 둡니다.  즉 디자인과 개발의 완벽한 분리를 꾀하는데 목적을 둠
2.    유지보수에 있어 디자인과 개발의 업무량을 최소화 하기 위함
3.    초기 접속 시 불필요한 동적 렌더링을 피할 수 있다.

조건 :
1.    디자인 시 거의 모든 부분이 Div 구조로 디자인 되어야 한다.  Table과 같이 다른 특성을 가지고 있는 영역끼리 하나의 Layout으로 연관되어 질 경우 개발자에 의해서 처리되는 로직이 매우 복잡해진다.
2.    디자인 시 특징이 다른 Div Element에는 유니크 한 ID를 부여할 수 있어야 한다.
3.    개발자가 ID를 부여할 경우에 개발 설계에 의한 최소한의 ID만 부여해야 한다.
4.    부분적으로 Table 을 사용해야 할 경우 개발자의 협의가 필요할 수도 있다.


제약 :
1.    개발자뿐만 아니라 디자이너도 DOM 에 대한 기술적 이해가 필요하다.

단점 :
1.    HTML의 구조가 변경되면 구조에 맞게 javascript개발 부분도 변경되어야 한다.
즉 HTML 버전관리와 Javascript 버전관리가 함께 이뤄져야 합니다.
2.    페이지 접속 시 디자인 레이아웃의 흐트러짐 현상이 있을 수 있다.


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

이 내용은Ajax/Rich UI의 특정한 개발을 위한 방법론에 가깝다고 봐도 무방합니다.  또한 개인적인 경험에 의한 정리이며 일반적인 시스템 설계에서 말하는 패턴의 정의와는 상이하거나 다른 의미를 갖을 수 있습니다.
신고
Posted by Rhio.kim
ExtJS의 기본 이해하기 ( Component Class의 inheritance 구현 및 계층 구조의 이해 )



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의 맴버로서 수행되어집니다.



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

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

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

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




이 코드는 이벤트 리스너를 설정하게 됩니다.  최근에 릴리즈한 자바스크립트 프레임웍에는 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 이 인스턴스화 될 때 비로소 리스너가 작동이 가능하게 됩니다.

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

사용자 삽입 이미지


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



신고
Posted by Rhio.kim
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을 개발하는 목적을 달성시켜주는 패턴중에 하나라고 말할 수 있습니다.

간단한 예제 소스입니다.

위의 예제처럼 storage에 서버에 요청했던 정보들을 저장해놓게 되면 재 요청이 이뤄지지 않고 기존 데이터를 그대로 활용할 수 있습니다.

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

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

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

신고
Posted by Rhio.kim
사용자 삽입 이미지





  다양한 프레임웍(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/
신고
Posted by Rhio.kim
사용자 삽입 이미지

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

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

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

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


신고
Posted by Rhio.kim
사용자 삽입 이미지


Aptana Jaxer: An interview with the Aptanians from Dion Almaer on Vimeo.

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/
신고
Posted by Rhio.kim
좀더 안정된 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 합니다.


신고
Posted by Rhio.kim
사용자 삽입 이미지

요건 머에다 쓰는 물건일까요?
같은 그림 찾기에 사용할 이미지 입니다.. ^-^;

TFastClick 에 이은 불후의 고전 게임 -_-?

prototype 만들어 보았습니다.
@import prototype.1.6.0.2


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

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

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

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

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

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

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

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

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

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

신고
Posted by Rhio.kim
사용자 삽입 이미지
Ajax 와 DOM 스크립팅에 현재 가장 이슈가 되는 것은 아무래도 고성능을 낼 수 있는 웹 어플리케이션을 만들 수 있느냐라고 생각합니다.

웹 자체는 가벼우면서 사용자들에게 손쉽게 다가갈 수 있고 사용자들에게 가장 쉽게 어필 할 수 있는 것 역시 웹(web) 입니다.

최근 RIA 개발에 Ajax가 가미되면서 Client-side 와 Server-side 가 완전히 분리되고 Client 에서는 UI에 전념할 수 있게 되었습니다.

하지만 이에 "대화형 웹 어플리케이션"을 위한 Ajax와 DOM 스크립팅이 그 만큼 중요하게 되었는데요.

크로스브라우징, 사용자 리소스 최적화 등의 이슈가 되고 있습니다. 그렇게 좀더 가볍고 저사양에서도
또한 글로벌 스탠다드가 되기 위하여 최고의 퍼포먼스를 낼 수 있는 RIA 설계가 중요하게 되었습니다.

우리는 IE, FF, Opera, Safari 의 크게 4가지의 브라우저를 기본으로 크로스 브라우저에 대응합니다.
이에 몇가지 브라우저별 퍼포먼스를 비교해봅니다.


DOM 스크립팅 퍼포먼스 (HTML DOM Operation Performance)
                                        IE7             FireFox            Safari       
HTML DOM Operation Time(ns) % Time(ns) % Time(ns) %
Change text using innerHTML 469.0 9979% 234.0 6000% 109.0 7032%
Create a text node on HTML Dom 1093.0 23255% 156.0 4000% 110.0 7097%
Change the class name of an element 422.0 8979% 47.0 1205% 109.0 7032%
getElementById 86.8 1846% 15.7 401% 3.9 252%
getElementsByTagName("div") 153.1 3257% 18.0 462% 5.5 352%
getElementsByName 93.8 1995% 44.6 1142% 4.7 303%
placeDiv.getAttribute("id") 29.7 632% 46.8 1200% 5.5 352%
placeDiv.attributes["id"] 31.3 665% 225.0 5769% 6.3 403%

IE7의 결과는 UI 개발자의 손목에 수갑을 채우고 있습니다. 꼭 이런 문제뿐만 아닙니다.
IE8에는 많은 문제가 해결되고 표준에 의거하여 개발에 임했으면 합니다.



eval function의 수행 퍼포먼스(2번)
IE7 172ns and 94ns
FireFox 546ns and 749ns
Safari 9.4ns and 22.7ns

과연 eval은 크로스 브라우징 대응에 있어서 사용을 줄여야합니다.


Object 생성 수행 퍼포먼스
“var myObject = new MyObject (17, 250);
“var slowCar = {m_tireSize:17, m_maxSpeed:250};”

IE7 11.7ns and 8.6ns
FireFox 23.4ns and 23.4ns
Safari 3.2ns and 2.4ns

Ajax 개발 시 Server-side 에서 JSON 을 받아올 경우 Firefox의 경우 Object화 하여 사용할 경우
경우에 따라 퍼포먼스에 많은 영향을 미칩니다.


in 수행 퍼포먼스
IE7 10.3ns
FireFox 62.8ns
Safari 7.6ns


Firefox 도 Ajax 개발 시 경우에 따라 상당히 느려지는 부분을 보이고 있습니다.
하지만 IE6의 경우보다는 매우 양호합니다. IE6의 경우는 대부분의 Ajax 개발 관련 Performance 테스트에서
몇 백 퍼센트의 차이를 보이고 있습니다.
특히 IE의 경우 String 퍼포먼스에서 매우 낮은 결과를 보입니다.

DOM 스크립팅시에 우리는 DOM 구조를 일일이 생성하는 것 보다 String innerHTML을 자주하게 활용하는데요.
IE의 경우 퍼포먼스에 지대한 영향을 미칩니다.
그래서 우리는 Array 를 이용 string buffer 기능을 사용하여 효율적으로 처리하고 있지만 전체적으로 IE의
경우 String에 낮은 퍼포먼스를 보입니다.

마지막으로 Safari 의 경우 다른 브라우저들에 비해 상당히 안정되고 최고의 퍼포먼스를 자랑하고 있습니다.
역시 아직까지 다른 브라우저에 비해 기능 차이가 있기 때문입니다.

체감하는 렌더링 속도도 상당히 차이가 있음을 느낍니다.


Internet Explorer 7

      FireFox

     Safari

Description

Time (ns)

% of base

Time (ns)

% of base

Time (ns)

% of base

Normal Empty function call (Base Operation)

4.7

100%

3.9

100%

1.6

100%

Basic Function Calls







Function call using function.call(this)

5.5

116%

2.4

60%

1.6

100%

Normal Empty function using apply

5.5

117%

7.0

179%

2.4

152%

Normal Empty function using apply with 3 parameters

7.0

149%

7.1

181%

2.4

152%

Eval a function

172.0

3660%

546.0

14000%

9.4

603%

Eval an object

94.0

2000%

749.0

19205%

22.7

1461%

Basic Operations







Access Properties through a getter

13.3

282%

6.3

160%

5.5

352%

Access Properties directly

4.7

100%

3.2

81%

2.4

152%




 

 



Simple string concatenation

4.7

100%

2.3

59%

1.6

100%

Simple string compare

3.9

83%

2.4

60%

0.8

48%

Change string to upper case

11.7

249%

3.9

100%

4.7

303%

Replace string reg expression

12.5

266%

7.1

181%

9.4

603%

String concat with integer

7.1

150%

4.7

119%

2.4

152%

String concat with float

6.3

133%

4.7

121%

2.4

152%

Index of Bob in string, not found, length = 71

6.3

133%

6.3

160%

2.4

152%

Match of Bob in string, not found, length = 71

14.9

316%

25.0

640%

3.9

252%

charAt(10) in string

11.7

249%

6.3

160%

3.1

200%




 

 



Create object constructor initialized

11.7

249%

23.4

600%

3.2

203%

create simple object

8.6

182%

23.4

600%

2.4

152%



0%

 

 



Variable declaration

4.0

84%

2.3

59%

0.8

48%

Multiple variable declaration, multiple var

3.9

83%

2.4

60%

2.4

152%

Multiple variable declaration single var

3.9

83%

2.4

60%

1.6

100%

Variable declaration set to null

3.9

83%

2.4

60%

1.6

100%



0%

 

 



Variable assignment++

4.7

100%

5.5

140%

1.6

103%

Variable assignment + 1

5.5

116%

7.1

181%

1.6

100%




 

 



Four levels of property access

5.5

116%

5.5

140%

1.6

100%

Three levels of property access

4.7

100%

4.7

121%

2.4

152%

Two levels of property access

4.7

100%

4.7

119%

1.6

100%

One level of property access

3.9

83%

4.7

121%

1.6

103%



0%

 

 



Using the typeof function

3.9

83%

4.7

119%

1.6

100%

Array Operations







Array access

7.1

150%

7.0

179%

1.6

100%

Array index value change

3.9

83%

4.7

121%

1.6

103%

Empty Array index value change

8.6

183%

8.6

221%

6.3

403%

Empty Array add three values

10.2

216%

11.7

300%

3.1

200%

Empty Array with set size

11.0

233%

11.0

281%

3.2

203%

Empty Array using constructor

9.4

199%

25.8

662%

2.3

148%




 

 



Push element onto an Array

25.0

532%

6.3

160%

1.5

98%

Pop element of an Array

165.6

3523%

6.3

160%

249.7

16112%

Push element onto an Array

6.2

132%

7.1

181%

1.4

92%

Shift elements off the front of an Array

2030.0

43191%

5620.0

144103%

1250.0

80645%

Join the array into a string

125000

2659574%

47000

1205128%

16000

1032258%

Push element onto an Array

7.1

150%

7.0

179%

3.9

252%

Sorting of an Array

93.0

1979%

45.3

1162%

32.9

2119%




 

 



Math.max(7.25,7.30)

5.5

116%

4.7

121%

3.9

252%

Math.min(7.25,7.30)

5.5

117%

4.7

121%

3.2

203%

HTML DOM Operations







Change text using innerHTML

469.0

9979%

234.0

6000%

109.0

7032%

Create a text node on HTML Dom

1093.0

23255%

156.0

4000%

110.0

7097%

Change the class name of an element

422.0

8979%

47.0

1205%

109.0

7032%




 

 



getElementById

86.8

1846%

15.7

401%

3.9

252%

getElementsByTagName("div")

153.1

3257%

18.0

462%

5.5

352%

getElementsByTagName("spa")

142.2

3024%

18.8

481%

5.5

355%

getElementsByName

93.8

1995%

44.6

1142%

4.7

303%




 

 



placeDiv.getAttribute("id")

29.7

632%

46.8

1200%

5.5

352%

placeDiv.attributes["id"]

31.3

665%

225.0

5769%

6.3

403%

var atts = placeDiv.attributes; atts["id"].name

11.7

249%

18.8

482%

4.7

303%

var atts = placeDiv.attributes; atts.id.name

12.5

266%

18.8

482%

3.9

252%

Try/Catch







Function call using function.call(this)

7.1

150%

4.0

101%

2.4

152%

Try catch

7.1

150%

6.3

160%

5.5

352%

Try catch with throw

17.2

365%

7.8

200%

5.5

355%

Try catch finally

9.4

199%

7.8

200%

4.7

303%

Try catch finally with throw

16.5

350%

11.0

281%

6.3

403%

If statement and Date object







Create a date object

12.5

266%

10.2

260%

3.1

200%

Create a date object and call getDate()

28.1

598%

50.8

1303%

10.2

658%




 

 



The switch statement

4.7

99%

2.4

60%

2.4

152%

An if statement

4.0

84%

2.4

60%

2.4

152%




 

 



Simple if else

4.1

86%

2.2

56%

1.9

121%

turinary operator

3.9

83%

2.3

60%

2.0

131%




 

 



Compare of matching string ==

4.7

100%

7.1

181%

2.4

152%

Compare of matching string ===

4.7

100%

7.0

179%

2.4

152%

Compare of non-matching string

4.7

100%

3.9

100%

2.4

152%




 

 



Compare  TEST_INT == 5

4.1

86%

4.2

108%

1.7

111%

Compare  5 == 5

4.1

87%

2.0

52%

1.6

101%

Looping Performance Statistics







Loop through an array using in

10.3

219%

62.8

1610%

7.8

503%

Loop through an array using for (i++)

6.3

133%

10.6

273%

3.4

222%

Loop through an array using for (i < myArray.length)

6.2

133%

10.9

281%

3.1

201%

Loop through an array using for (i = 0; i < len; i++)

5.0

106%

4.7

120%

4.1

262%

Loop through an array using for (i = 0; i < len; i++)

5.3

113%

5.0

128%

4.1

262%

Loop through an array using while {i++}

5.3

113%

5.3

136%

4.7

302%

Loop through an array using while (i++ < len)

5.0

106%

5.0

128%

4.4

283%



원본 : http://www.coachwei.com/blog/_archives/2008/1/22/3480119.html
퍼포먼스 테스트 : http://www.rockstarapps.com/samples/performance/
신고
Posted by Rhio.kim
사용자 삽입 이미지

YUI2.4.0 - Yahoo User Interface 분석 자료입니다.
yahoo.js 에 들어있는 global object 에 대한 내용을 다루고 있습니다.

번역에 있어 다소 오류가 있을 수 있습니다.
정확한 정보는 developer.yahoo.com 에서 확인하시기 바랍니다.

pdf :



신고

'JavaScript > Study-YUI' 카테고리의 다른 글

야후! YUI 2.5 released  (6) 2008.02.21
YAHOO UI 2.4.0 - core 분석 발표자료.  (0) 2008.01.22
YUI Library: The YAHOO Global Object  (2) 2008.01.12
Posted by Rhio.kim
사용자 삽입 이미지

크로스 도메인 Ajax 가 파이어 폭스(firefox 3) 에서 지원을 하게 되었습니다.
W3C 표준에 Access Control working draft 에 대한 기사가 있는데요.

파이어폭스 3에서는 이부분을 벌써 적용중이네요.










php code

javascript
신고
Posted by Rhio.kim
몇일 전 Julien recomte 씨가 Yahoo! 에서 발표한 고성능 Ajax Application 자료입니다.
다룬 내용은
  • Developing for high performance
  • High performance page load
  • High performance JavaScript
  • High performance DHTML
  • High performance layout and CSS
  • High performance Ajax
  • Performance measurement tools
ppt 자료 :




신고
Posted by Rhio.kim
퍼포먼스 향상을 위한 Ajax Anti Pattern
기존에 ibm에서 발표한 자료와는 조금 틀립니다.

당연히 알고 있는 부분일 수도 있지만 다시 한번 되새기고 모르시는 분들과 알지만 간과했던 부분일 수 있음을
분명히 인지하시면 좋겠습니다.

Ajax 패턴이라 하기 보다는 웹에서 javascript 로 동적 처리를 할 경우에 꼭 체크해야할 사항입니다.

사용자 삽입 이미지






위의 이미지는 jsProc.htm 파일에서 jsProc1.js 와 jsProc2.js 를 로딩하는 과정에서 발생하는 Cost에 대해서 분석했습니다. 

기본적으로 브라우저에서 js파일을 HTTP Request 할때 parallel download 가 이뤄집니다.
즉 1개의 js가 다운로드 되고 나면 그 다음에 오게될 js를 다운로드 하게 됩니다. 다른말로 block download 라고도 하는데요.

위의 이미지는 js 파일에 아무런 내용이 없을때 다운로드 되는 속도입니다.
0 byte의 js 파일을 HTTP Request 하는데에도 약 32ms 가 발생하네요. 작은 거지만
10만 모이더라도 3ms 가 발생합니다.  웹 페이지에서는 치명적입니다.


사용자 삽입 이미지






위의 내용은 jsProc1.js 에 아래의 코드를 수행하도록 처리해 놓은 것입니다. 
이는 각 모듈별로 js가 로드되면서 js가 수행하는 일이 있을때 과연 어떻게 브라우저에서는 작용을 하는지 체크하였습니다.

jsProc1.js 안의 명령들이 수행이 완료되고 나면 비로소 나머지 js파일을 로딩합니다.
jsProc1.js 의 download 시간은 313ms 가 소요되었습니다.
아무것도 없을 때에 비해 282ms 더 걸렸습니다.

이는 js 내에서 처리되는 명령들이 수행이 되고나서 다음 js 가 비로소 다운로드 됨을 의미합니다.

좀더 복합적으로 image 라들지 css, flash 등의 component 들 역시 javascript에 의해서 딜레이 되게 됩니다.

그렇기 때문에 javascript 라이브러리들은 HTML document 의 하단 부분에 넣기를 권장합니다.
그리고 js에서 페이지 로딩단계에서 처리해야 될 부분을 최소화 시켜야합니다.


TPerformance v0.0.001 - Rhio Ajax Application 2007
------------------------------------------------------------------------------
 시작 : 1197982303953/ms
 종료 : 1197982304718/ms
------------------------------------------------------------------------------
수행시간 : 765/ms
신고
Posted by Rhio.kim
사용자 삽입 이미지











Prototype 기반의 Ajax 버디버디 IM 3.2 입니다.

깔끔한 인터페이스 Javascript로 개발되어진 버디버디입니다.  실시간 메시징 처리가 됩니다.

개인 블로그며 홈페이지 원하는 곳에 플러그인 처럼 연동해서 사용할 수 있습니다.

PHP와 JS를 통한 OO 개발이 되었구요. 기존에는 prototype 기반이 아니여서 이번 버젼에는

기존 버전에 비해 많은 부분이 수정되었답니다.  다중 언어도 지원할 뿐더러. PHP 기반 세션 처리로

아이디와 비번을 메세지 날릴때마다 체크하지 않아도 됩니다.

테마(스킨) 기능도 지원됩니다. 블랙 테마가 추가 되었나 보내요..

국내 유저들은 언제쯤 이런 라이브러리를 개발해서 paypal 붙여볼까요??

붙인다고 후훤해주는 분들도 없으시곘지만요... ^^ 외국인에게라도 지원 받을 수 있지 않을까요???

그리고 참고로 한가지..

Copyright (c) 2006-2008, Joshua Gross (unwieldy studios)  All rights reserved.

사용자 삽입 이미지

신고
Posted by Rhio.kim
사용자 삽입 이미지
Ajaxian 의 2007 Ajax tool 투표 결과입니다.

올 한해 다양한 Javascript Library 들이 출시 되고 출시되었던 라이브러리들도 기능 강화와 OOP 개발이 가능하도록 라이브러리화 되었습니다.

Prototype 의 강세는 여전하네요..
다만 jQuery가 그 뒤를 바로 뒤쫓아오네요..

Ext JS 가 3위에 등극했다는 것은 상당히 !!

외국에서는 그리드 형식의 Ajax 어플리케이션을 선호하나봅니다.

웹 상에서 구현하기 힘든 그리드 형식의 어플리케이션 개발이 한결 수월해졌기 때문인데요.

아마 웹 기반 CRM 같은 개발 혹은 관공서나 국가 기간같은 디자인적인 부분을 많이 신경 쓰지 않고 기능 위주의 인터페이스에서 아주 효율적인 어플리케이션 개발이 가능하다는 것이죠.

상당히 발전할 수 있어 보입니다.

Script.aculo.us 는 Prototype을 모태로 상당히 많은 유저층을 이루고 있습니다.  둘이 함께 이용한다면...
60% 정도를 장악하고 있네요.  하지만 이제 jQuery와 interfaceElement 까지 나와서 내년 2008년은 어떻게 바뀔지 모르겠네요...

내년은 아무래도 더 많은 javascript library가 발표 되리라 예상됩니다.

또한 UI 라이브러리인 Mootools와 Yahoo 인터페이스에 최적화 되어있는 YUI 아주 많이 사용하고 있네요..
Mootools 는 깔끔한 UI 처리가 가능하고 Effect 별 모듈러를 지원해 필요한 UI 모듈만 따로 모아 js 라이브러리 파일을 생성해서 사용할 수 있습니다.

YUI는 야후의 javascript 아키텍쳐인 douglas crockford 씨의 개발 설계가 숨어있고 Yahoo라는 대형 서비스에서 검증된 실로 Prototype 못지않게 공부해 볼만한 UI 라이브러리라 생각되어집니다.

하지만 단점이라면 Yahoo에 최적화된 라이브러리이고 국내 정서에 자신의 사이트에 Yahoo라는 라이브러리를
써야한다는 자존심 괘난 자존심도 생기게 되구요.!!   다른 이유도 많이 있겠죠...

마지막으로 여전히 자체 개발한 Ajax Tool을 사용한다는 것..
어쩌면 내년에는 더 많아질지 모르겠다는 생각이 입니다.

사실 그랬으면 좋겠습니다.
좀더 많은 소스타입의 다양한 형태의 라이브러리가 많이 출시 되었으면 좋겠습니다.
신고
Posted by Rhio.kim
사용자 삽입 이미지

YSlow 0.9.2 릴리즈 소식입니다.

참 좋은 녀석입니다.  크게 2가지의 기능이 추가 되었습니다.
Components 부분에 기존에 없던 Ajax Request 정보와 Image beacon과 같은 DOM Object가 아닌 것들도
정보를 볼 수 있습니다.

개발자에게는 좀더 강력한 Web 2.0 개발의 디버깅 및 테스트 보안에 좀더 보완할 수 있게 되었습니다.

그리고 하나는 페이지 내의 느릿느릿한 iframe 나 frame 의 컨텐츠를 분석할 수 있도록 되었습니다.
국내에서는 iframe 이나 frame을 거의 쓰지 않기 때문에 설명은 하지 않습니다.

또 여러가지 버그가 수정되었고 다른 몇몇 기능 중 404 not found 강조, CSS 구문의 접근, Javascript 최소화
YSlow 판넬에 검색기능이 포함되었습니다.

이번 릴리즈로 고 성능의 Web2.0 어플리케이션 개발을 위한 더 강력하게 바뀌였네요.

좀더 정확한 릴리즈 정보는 여기서
신고
Posted by Rhio.kim
Ajax 브라우저별 HTTP Connection 에 대한 테스트 및 고찰!!
그동안 Ajax 통신은 Wininet.dll (Window 32 Internet API) 로만 통신을 하는 줄 알았습니다.

FF에서 Ajax 최대 커넥션 및 HTML document component 병렬(parallel Downloads)다운로드 테스트 하다가
알게 되었습니다.

사용자 삽입 이미지







각 Ajax 요청에 따른 서버 모듈은 PHP 입니다.

<?php
  sleep(5);
  echo "{ complete : 'ok' }";
?>

즉 단지 5초 동안 대기 한 후 결과값을 반환합니다.

테스트한 결과에 대해 살펴 보겠습니다.


Internet Explore 의 경우

사용 모듈 wininet.dll 을 사용합니다.
그리고 Max-Connection 개수는 아래의 레지스트리 값을 참고합니다.  따로 레지스트리를 건드리지 않은 상태라면 아래의 dword 의 값은 00000002 입니다.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
  "MaxConnectionsPer1_0Server"=dword:00000002
  "MaxConnectionsPerServer"=dword:00000002

기본 적으로 Ajax 통신은 2개의 커넥션만 가능하게 됩니다.

위의 테스트 할때 커넥션이 몇개 만들어지는지 TCP/IP 커넥션 개수를 보겠습니다.
사용자 삽입 이미지

좌측에서 보는것과 같이
3개의 커넥션이 맺어집니다.

제 레지스트리이에는
00000040 으로 설정되어
있습니다.

16진수로 64개의 커넥션을
허용해 놓은 상태입니다.

그래서 기본적으로 권고하는 2개의 커넥션보다 더 많은 Ajax 요청을 허용하게 됩니다.

Ajax 통신이 완료되면 자동으로 커넥션은 close 됩니다.












이때 과연 어떤 window 모듈을 사용할까요...
사용자 삽입 이미지
좌측에서 보이는 것 처럼 IE에서는 WININET.dll을 사용합니다.















FireFox 의 경우

network.http.max.-persistent-connections-per-server
사용자 삽입 이미지
좌측은 firefox의 config 정보 입니다. IE에서의 레지스트리와 동일한 일을 하는데요.

firefox 의 경우 주소 부분에 "about:config" 라고 입력해서 이동하시면 좌측과 같은 창이 보입니다.  필터 부분에 "network.http.max" 라 입력하시면 IE 의 레지스트리 부분과 유사한 기능을 하는 부분이 보입니다. 위 이미지에서는 파랗게 처리된 부분이 그 부분입니다.

저 같은 경우는 값이 2로 셋팅되어있습니다. 예제 페이지에서는 3개의 Ajax 요청을 합니다.


사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지





























































































위의 이미지 처럼 순차적으로 2개가 완료되고 나면 나머지 1개를 처리하게 됩니다.
당연한 이야기죠..

이어서 과연 Firefox도 Wininet 을 사용하지 않습니다.
사용자 삽입 이미지
mswsock.dll 을 사용해서 Ajax통신을 하게 됩니다.

사실 여기까지만 테스트를 하려고 했으나

혹 Opera 나 Safari 도 궁금할까 해서 간단하게 내부적으로 어떤 모듈을 사용하는지 찾아봤습니다.








Opera의 경우
역시 Opera 도 브라우저에 Config 를 따로 지원합니다. 당연히 브라우저기 때문에 브라우저에 설정 기능이 있어야 하는데.. IE 만 유달리 윈도우 레지스트리에 종속적으로 움직이네요...  별로 싫어집니다..

오페라의 경우도 주소줄에 opera:config 라고 입력하면 뜹니다.
사용자 삽입 이미지
















위의 값 중 Max Connections Server 값입니다. Opera의 경우 기본 값이 8입니다. FF와 같이 동일합니다.

사용자 삽입 이미지
Opera 의 경우도 mswsock.dll 을 사용하여 Ajax 요청을 처리하고 있습니다.














Safari의 경우
Safari 는 Info.plist 파일에 정보를 가지고 있다고 해서 찾아 열어봤지만 어떤 파일인지 찾지 못했습니다.
ㅠ.ㅠ 아무튼 유사한 방식으로 Max Connection 을 설정하고 있습니다.
Safari의 경우도 8정도로 설정되어 있는 것 같습니다. Ajax 요청을 한꺼번에 3개를 요청했는데 이상없이
3개를 동시에 처리 하더군요...

사용자 삽입 이미지
Safari 역시 mswsock.dll 을 사용하여 Ajax 요청을 하는 걸로 들통 났습니다.

















그런데 왜 굳이 IE는 지금 시스템을 고치려 하지 않을 까요?
Window 에서 돌아가는 브라우저들이라 해서 IE는 윈도우 깔면 자동으로 깔리는 임베디드형 어플리케이션이라서 W3C에서 권고한 DOM Standard도 따르지 않고 레지스트리에다가 설정하고 Wininet.dll 을 사용하고

기본 설정이 왜 2여야만 하는지 좀 다른 브라우저하고 표준에 대해서 Standard 에 대해서 논의 해보고 좀 맞추면 안되나?? 
신고
Posted by Rhio.kim
사용자 삽입 이미지
























적절한 프레임웍을 이용한것 같네요.  Dojo와 Mootools 대부분의 UI 부분은 Mootools 로 처리된거 같네요.

신기한 부분이있네요..

인라인 템플릿을 사용했는데요... 제로보드도 아니고.. ^^;  이 부분은 퍼포먼스만 좋다면 꼭 써보고 싶네요.


신고
Posted by Rhio.kim
사용자 삽입 이미지
Mootools 에서 Calendar 컴포넌트가 나왔네요.

몇일전에도 심플리티 캘린더라이브러리를 소개했었는데요.

이번 라이브러리는 깜찍하네요.  활용도가 높을꺼 같아요.

CSS-styling hooks 과 적절한 element 사용으로 사용자 정의 UI(?) 가능하게 구현하였네요.




API
신고
Posted by Rhio.kim
사용자 삽입 이미지
Javascript Ajax Date 라이브러리 입니다.

다양한 Method를 지원하네요. 왠지 Prototype 의 엘리먼트 부분하고 유사하네요.

today().next() 이런식으로 접근하는게 왠지 ^^

특이한게 Date.parse() 메서드인데요.

Date.parse('today'); 를 통해서 오늘 날짜를 구할 수 있다는거..

이런 방식으로 정규화된 string 파싱을 통해서 Date 포멧을 넘겨준다는 것

너무 Date라는 라이브러리에 입각해서 만든것 같다는 생각이

참 멋진 생각인거 같기도 하구요 반면에 이런걸 얼마나 사용할까? 라는 생각도 들었습니다.

사이트 : http://www.datejs.com/?
다운로드 : http://code.google.com/p/datejs/downloads/list


API





신고
Posted by Rhio.kim