HOME | EXPERIENCE | GUESTBOOK | ADMIN | ABOUT
 
 
CATEGORY
TAGS
CALENDAR
RECENT

All Articles
2008     1
  • AshScrollPane LivePrevi...
  • AshScrollPane
  • 유니코드 문자열 아랍어(Arab) 검사
  • 네...ㅎㅎ 머니클립으로 바꾸고 나서 외...
  • 나와 같은 고민을 하는 사람이 또 있다고 ...
  • 안녕하세요. 물론 MB를 지지하는 편에...
  • AdobeApple의 공격에 대응할 전...
  • 스티브 잡스가 멍석 깔아준 다양한 이야기
  • 말의 힘과 사이비 과학, 그리고 사이비 종...
  • 본인이 개발한 Javascript Library 이다.

    2년전으로 거슬러 올라가는데... 당시 본인은 JS를 거의 사용치 않는 시절이었다.
    발단은 S사 프로젝트 코웍때 페이지로딩 완료 되는시점에 브라우져 버젼체크를 해서 Flash쪽으로
    던져주면 플래시에서 상태확인 후 사용자에게 최신 브라우져를 다운로드하도록 안내하는 방식이었는데...
    여기저기 많은 개발자들과 같이 협력작업을 하다보니 페이지 onload 에 대한 이벤트를 다른 업체에서 이미 사용하고
    있어 원하는 요구를 수용해주기가 힘들다는 것이였다.
    당시 내가 알고 있던 유일한 이벤트 처리는 body(window) onload 였는데 이건 큰 규모의 작업에선 불가능할것이고
    그래서 iframe을 생성해서 onload처리를 해주길 바랬지만 이역시도 임의 생성은 불가하다는 것이었다.
    결국 꽁수로 플래시가 로딩되어 첫프레임이 실행될때 인터벌로 0.31초 준 후에 나름 체크했다는 이런 황당무개한 얘기가.^^;

    물론 그때 나름 애통함에 페이지 소스를 이리저리  뜯어본 기억으론 분명 페이지 상단에 prototype.js라는 걸 확인했었고
    그곳에서 EventObserver통해서 onload 처리를 하는것은 확인을 했지만 웹개발을 총괄하시는 분이 이것을 사용하면
    된다라고 힌트를 주시진 않았다.
    당시엔 그게 IEattachEvent와 동일한 역할을 한다고 생각지도 못하는 시절이었다.
    거기서 이미 사용하면 하단에선 더이상 사용불가라고 생각했었고 물론 웹개발하시는분들도 그렇게 얘길했었고..
    지금 생각해보면 참으로 황당한 일소 이겠지만..ㅎㅎ

    훗날.. 나는 이것이 오늘날 가장 많이 사용되는 공개 라이브러리라는 그해 겨울 알게되었다.
    더불어 작년말 문득 8년만에 개인홈페이지의 필요성을 느끼고 묵혀두었던 이 라이브러리를 보강하기 시작하면서
    JS기반 여러 라이브러리(Ext, Dojo, jQuery, YUI, Prototculous, Jindo, Method Chain) 들이 많이 개발되고 공개되었다는
    것도 역시 올초에 알게됬다.
    불과 얼마전까지도 참 무지 했었던것 같다..^^;
    지금도 사실 prototype.js가 위의 열거한 프레임웍들의 주목할만한 패턴, 피쳐가 어떤 건지도 거의 알지 못한다.
    개인적으로 JQuery는 한번 맛보고 싶은 맘이 강하지만 소스찾아서 분석 하는것 처럼 나에게 고행의 길은 없기 때문이다.

    단지 그해 겨울 시간적인 여유가 남아 플래시쪽에서 JS와 교신을 통해 Browser History에 대한 Anchor
    남길 필요성이 요구됬었는데 이벤트 처리로 힘들었던 6개월 전의 S사 프로젝트가 문득 떠올라서 부랴부랴 필요할때
    뭔가 해야겠다는 일념으로 2틀동안 이 자바스크립터 라이브러리의 초안을 만들게 된것이 지금의 전초이자 시작이었다.
    그냥 단지 당장에 가려움을 긁어줄 뭔가가 필요했을뿐, JS에 대한 애착이 강해서 아님 새로운 라이브러리를 공표하고
    개발하고 배포하고 뭐 이런 거창한거에 대한 기대욕구나 욕심때문은 아닌것같다.
    그럼 이제와서 왜? 이유가 간단...이미 만들어진 것이니..행여나 필요한 사람에게 도움이 되면 좋을것 같아서..^^;

    아무튼 위에서도 언급했지만 그때 기억났었던 prototype.js의 EventObserver방식이 아닌 EventDispatcher 방식이
    내가 생각하기엔 더 좋은 모델이라고 생각했다.
    물론 그땐 AS의 코딩에 익숙해져있던 탓도 있었겠지만 의미적으로 이벤트 감시가 아닌 이벤트를 대상 자체에서 직접
    발송하는 능동적인 의미가 더 맞지 않을까 싶었던 것이다.
    즉, 시각적인 객체는 이미 태생적으로 이벤트 처리기를 가지고 태어나는게 더 유연하지 않을까 라는 생각이었다.
    요즘도 개발을 하면서 항상 느끼고 고민하는 바이지만  패러다임쉬프트의 이행과 실천은 항상 달콤하지만 그 맛이
    어떤것이다 라고 절대적으로 단정하고 감히 정의할수 있는 가치 기준은 절대로 아닌것 같다.
    누군가에겐 양주가 가미된 초콜릿이 더 풍미로울수도 있겠지만 누군가에겐 쓴맛으로 더 강하게 느껴질 수 도 있기때문에...
    따라서 시점이 이벤트 감시이건 발송의 역할이건 중요한건 적제적소에 편리하게 잘 사용하며 최고의 결과물을 산출하는데
    일조하면 그 자체가 베스트가 아닌가 생각해본다.

    여튼 여기까지가 AshAPI가 만들어지게 된 나름의 비하인드였다.
    그냥 왠지 모르게 말하고 싶었다. 대단한게 아님을 강조하기 위함인가?ㅎㅎ
    아래는 간략하게 핵심 기능들에 대한 설명만 추가한다. 전체 클래스에 대한 내용은 Classes article를 참조하면 되겠다.
    한가지 확실한것은 이미 공개된 다른 강력한 라이브러리들이 기본에 충실한 역할모델을 중시한다면 AshAPI는 실무에서
    현업에서 당장에 필요한 기능들을 좀더 추구하고자 하는게 기본 목적이자 방향이다.

    Ash(core class)
    코어 클래스이며 주로 클래스생성과 확장,상속에 관련된 기능을 수행한다.  모든 클래스의 최상위 클래스이다.

    AshUtil package (document, color, filter ...)
    유틸클래스이며 패키지로 하위 클래스를 포함하고 있다.  엘리먼트에 대한 bounds, hitTest, contains, color(gradation pallet, mix) 등의
    유용한 Asset을 제공한다.

    AshEvent , AshEventDispatcher(이벤트 처리및 조작)
    AshAPI에서 가장 차별을 두고있는 핵심 포인터이다.
    임의의 사용자 객체에 대한 이벤트처리와 DOM엘리먼트들에 대한 Delegate가 가능하다.

    AshMotionAgent & Agent
    모션처리를 담당하고 있는 전용클래스로 역시 AshAPI의 핵심 기능과 역할을 하고 있다. 모든 DOM엘리먼트들에 대한 모션처리를
    런타임 상에서 바로 처리 구현이 가능하다.

    AshDrag, AshDrag&Drop, AshResize, AshDepthManager, AshPopUp
    기본 UI 인터렉션에 대한 처리를 담당하고 있는 클래스들이다.

    AshHtmlEditor & Panel
    위지윅에디터 생성및 실행과 관련된 기능을 제공하고 있다.

    AshAccordion
    간단하면서도 강력한 아코디언 처리를 런타임에 수행할 수 있다.


    그외 기재하지 않은 다수의 클래스들이 존재한다. 현재버젼까지 총 26개의 클래스가 포함되어 있다.

    EDIT | DELETE
    LINK • SUMMARY