배포된 "Atlas" Control Toolkit은 2가지 버젼이 있는데, 소스 포함 버젼과 소스가 포함되지 않은 버젼입니다. 단순히 이 샘플들이 어떻게 생겨먹었고, 수정 없이 사용하고자 한다면, 소스가 포함되지 않은 버젼을 받으면 됩니다. 하지만, 자신의 구미에 맞게 좀 수정하고자 한다면, 소스가 포함된 버젼을 받으세여.
소스가 포담된 버젼을 대상으로 설명하자면..
7 월 31일에 배포된 "Atlas" Control Toolkit 패키지에 포함된 내용들은 다음과 같습니당. (1) AtlasControlToolkit - Atlas 컨트롤의 샘플들과 소스코드가 들어있는 폴더입니다. (2) SampleWebSite - AtlasControlToolkit에 포함된 샘플들을 모두 이용해 만든 데모 사이트입니다. (3) ToolkitTests - 모든 컨트롤에 대해 각 각의 테스트를 위해 만든 사이트입니다. (4) AtlasControlExtender - Visual Studio 2005를 이용해 새로운 Atlas extender 컨트롤의 생성을 가능하 게 하기 위한 템플릿을 사용자의 PC에 인스톨하는데 필요한 VSI 인스톨러가 포함되어 있습니다.
샘플들의 내용을 확인하는 방법은 SampleWebSite의 웹 페이지를 실행해보면 알 수 있습니다.
샘플들을 수정해(소스 레벨이 아닌...) 웹 페이지에 응용하는 방법은 다음과 같습니다.
1. Visual Studio 2005를 실행시킨 다음, 새로 만들기 -> 웹 사이트를 선택합니다. (이 때, Atlas Website 템플릿을 선택합니다.)
2. 생성된 프로젝트에서 eura.rtf 파일과 deafault.asxp, 그리고 readme.txt 파일은 불필요하므로 삭제를 합니다.
3. SampleWebSite\Bin 폴더로부터 AtlasControlToolkit.dll, AtlasControlToolkit.pdb, Microsoft.AtlasControlExtender.dll 파일을 새로 생성된 프로젝트의 Bin 디렉토리에 추가를 시킵니다.
4. 그런 다음, 샘플들의 소스를 보고 적당히 사용합니다..(무책임하군-_-)
1. Extenders
컨트롤 Extenders는 ASP.NET server 컨트롤에 클라이언트의 기능을 덧붙일 수 있는 방법을 제공합니다. 자세한 내용은 ASP.NET 페이지에서 TextBox 컨트롤에 자동완성기능을 추가한 AutoCompleteExtenders의 예를 보면서 이해하면 됩니다.
컨트롤 Extender는 extender 속성들의 모임들을 정의합니다. 각 속성은 특정한 컨트롤(TargetControlID)에 extender 기능을 추가합니다. 즉, 사용자는 페이지에서 하나의 컨트롤 extender을 여러개의 컨트롤에 사용할 수 있다는 것을 의미합니다. ASP.NET "Atlas"는 다음과 같은 컨트롤 Extender를 포함합니다.
▶ AutoCompleteExtender: 자동완성기능과 drop-down list 기능을 컨트롤에 부여할 수 있습니다. 이 Extender는 AutoCompleteProperties을 가집니다.
▶ DragOverlayExtender: 웹 페이지의 특정한 섹션을 drag-and-drop을 가능하게 하는 기능을 부여할 수 있습니다. (다시말하면, 특정 컨트롤 또는 영역을 페이지 내부의 어느 위치든 옮길 수 있다는 것을 의미합니다. 웹페이지 내의 컨트롤 재배치가 가능함을 의미합니다.)
2. Timer Control
ASP.NET "Atlas" TimerControl은 사용자로 하여금 어떠한 동작을 경과 시간에 기반해 가능하게 합니다. (다시말하면, 예를 들어 몇 초 단위로 텍스트 박스의 메시지를 변경하게끔 하는 동작도 가능하게 함을 의미함..) 다음 예를 보면 보다 명확하게 알 수 있습니다.
ASP.NET "Atlas" Server Controls가 무엇인지..? 그리고 ScriptManger 컨트롤이 무엇인지에 대해서는 이전 게시물(ASP.NET "Atlas" Sample Program #1)을 참고하기 바랍니다..
앞선 게시물에서 언급했습니다만.. ASP.NET "Atlas" Server Controls에는 다음과 같은 Controls & UI가 존재합니다.
(1) ScriptManager (2) UpdatePanels
(3) Trigger
(4) Extenders
(5) Time Control
1. UpdatePanels
일반적인 ASP.NET 2.0 응용 프로그램에서, postback이 발생하면, 그 페이지 전체가 새로 렌더링됩니다. 페이지가 렌더링 되면 브라우저에서는 깜빡이는 현상이 발생하죠. postback이 진행되는 동안 서버에서는 페이지의 생명주기가 진행됩니다. 이것은 결국에 poskback을 발생시키고 이벤트 핸들러를 실행시키는 컨트롤 이벤트가 일어난 것을 말합니다.(예를 들어, 버튼 컨트롤의 클릭 핸들러 같은... )
ASP.NET "Atlas"의 UpdatePanel 컨트롤은 이러한 전체 페이지의 새로고침을 제거했습니다. (오우-_-) UpdatePanel 컨트롤은 페이지의 어떠한 부분을 담당(mark)하는데 사용되어 집니다. (그 어떠한 부분은 postback이 발생했을 때, 업데이트가 이루어질 부분..) 그러나, 그 부분은 UpdatePanel 컨트롤을 사용하게 되면, 클라이언트에서 전통적인 postback이 발생하지 않습니다. (즉, 페이지 전체가 새로고침 되지 않다는 것이죠.)
반면에 서버에서 페이지는 여전히 postback을 다루고 있으며, 정상적으로 작동하고 있습니다. (이벤트 핸들러를 발생시키는 것처럼) 하지만! 페이지의 렌더링 마지막 까지 오직 생성된 UpdatePanel 컨트롤에 의해 정의된 부분만 포스트백이 일어나는 것이죠~ (그렇군요..-_-) 이것을 부분적 렌더링이라고 합니다.
UpdatePanel 컨트롤은 ScriptManager 컨트롤(클라이언트의 ASP.NET "Atlas" script와 관련된 참조들과 부분적 렌더링 모델을 관리하기 위해..)을 필요로 합니다. ScriptManager 컨트롤은 부분적 페이지 업뎃을 관리하며, 오직 UpdatePanel 컨트롤과 거기에 속한 녀석들에 대한 렌더링만 허용합니다.
UpdatePanel 컨트롤은 컨텐츠를 위한 컨테이너(일반적으로 ASP.NET Server 컨트롤들)로 동작하는 ContentTamplate란 element를 포함하고 있습니다. ContentTemplate은 부분적으로 업뎃이 될 부분을 <ContentTemplate>란 태크로 감싸야합니다.
Mode 속성은 UpdatePanel 컨트롤이 자신에 속한 컨텐츠를 갱신할 때를 명시합니다. 만약, Mode 속성이 Always로 설정한다면, UpdatePanel에 속한 컨텐츠가 모든 postback 상황마다 갱신됩니다. 하지만, Mode 속성이 Conditional로 설정한다면, UpdatePanel은 서버 기반의 하나 또는 그 이상의 Triggers(또 다른 Server Controls 중 하나)에 의해 렌더링됩니다. (마치, 어떠한 특정 속성의 값이 변화하였다던지, 특정한 이벤트가 발생했을 때와 같이...)
UpdatePanel컨트롤과 함께 Trigger를 사용하기..
앞서 언급한 바와 같이 UpdatePanel컨트롤의 Mode 속성이 Conditional로 설정되어 있다면, 패널은 오직 Triggers에 대한 응답으로만 렌더링됩니다. UpdatePanel 컨트롤은 Triggers의 collection(한글로 바꾸자니 개념이 좀 애매해서.. 그냥 Triggers들의 멤버들 정도로..) 들을 포함합니다. Triggers에는 2가지 형태가 있습니다.
(a) ControlEventTrigger - 이 녀석은 페이지의 임의의 컨트롤(ControlID)에서 발생시키는 어떤 특정한 이벤트(EventName)와 연관되어 정의됩니다. 즉, 연관된 컨트롤에서 어떤 이벤트가 발생하면, 이 녀석은 "빵!"하고 UpdatePanel 컨트롤에 알려줍니다. 그러면 UpdatePanel 컨트롤은 서버의 페이지 부분에서 부분적으로 렌더링해야할 부분을 렌더링하게 될 것입니다.
(b) ControlValueTrigger - 이 녀석은 페이지의 임의의 컨트롤(ControlID)의 특정한 속성(PropertyName)과 연관되어 정의됩니다. 즉, 연관된 컨트롤에서 그 특정한 속성의 값이 변할 경우, 이 녀석은 "빵!"하고 UpdatePanel 컨트롤에 알려줍니다. 그러면 UpdatePanel의 컨텐츠들은 postback이 진행되는 동안 새로 갱신될 것입니다.
이번 시간은 UpdatePanel 컨트롤과 Triggers란 녀석에 대해서 알아보았습니다. UpdatePanel 컨트롤은 자신의 태그 내에 포함된 컨텐츠들만 부분적으로 갱신을 가능하게 해주는 녀석입니다.(물론, ScriptManager에서 미리 정의해두어야 하지만.. 자세한 내용은 이전 글을 찾아보세요.)
UpdatePanel 컨트롤의 처리 방법에는 크게 2가지, Mode가 Always일 때와 Conditional 일 때, 2가지가 있는데, Always일 때는, postback이 발생할 때 마다 UpdatePanel의 컨텐츠들도 갱신하게 하였습니다.
반면에, Conditional일 때는 Triggers에 따라서 반응하게 하였죠! 어떤 컨트롤의 이벤트가 발생했을 때를 감지하여, UpdatePanel의 컨텐츠들을 갱신할 것인가?! 아니면! 어떤 컨트롤의 속성 값이 바뀌었을 대를 감지하여, UpdatePanel의 컨텐츠들을 갱신할 것인가로 구분되었습니다!
3. Atlas 코드에 대한 설명
동영상에 등장하는 프로그램의 코드들을 보면, Atlas에 대한 부분이 등장합니다. 물론, 동영상에 등장하는 강사(?)가 매우 친절하게도 영어로 설명해줍니다만.. 사실 왜 저 코드들을 써야되는지에 대한 설명은 skip하는 경향도 있고.. 못 알아 듣는 부분도 있기에.. (사실, 이게 크죠-_-)
Atlas는 프로그래머에게 크게 2가지 측면의 Control과 User Interface를 지원합니다.
(1) ASP.NET "Atlas" Client-side Controls
(2) ASP.NET "Atlas" Server Controls
이 두가지는 네임에서 느낌이 오시겠지만.. 서버와 클라이언트 중 어디를 기반으로 컨트롤이 수행되느냐로 구분됩니다.
동영상에 등장하는 프로그램의 경우, Server Controls로만 구현되었기 때문에, 이번엔 Server Controls에 대해서만 설명하도록 하겠습니다.
● ASP.NET "Atlas" Server Control
Atlas에 포함된 Server Control을 사용하면 페이지를 다시 게시할 때(새로 고침과 같은..) 일시적으로 상호 작용(interact)이 중단되는 것을 방지할 수 있습니다. 다시 말하면, 서버 컨트롤이 백그라운드에서 렌더링을 업뎃하는 동안 사용자는 웹 페이지와 상호 작용할 수 있습니다.
▷ ScriptManager - Atlas 기능을 사용할 모든 페이지에 포함되어야 합니다.
ScriptManager 컨트롤은 클라이언트에서 서버로의 다시 게시 동작을 변경하며 두 번째 컨트롤인 UpdatePanel 컨트롤은 변경 작업을 위해 서버에서 페이지의 수명 주기를 관리합니다.
ScriptManager 컨트롤은 클라이언트로 보내는 JavaScript를 제어하는 역할을 하는데, 서버 컨트롤은 클라이언트에 JavaScript를 제공할 수 있으며 이 동작을 제어하기 위해 ScriptManager 컨트롤을 이용합니다.
ScriptManager 컨트롤은 UpdatePanel 컨트롤과 같이 부분적인 페이지 렌더링을 관리하기 위한 많은 일들에 대해서도 책임을 집니다. UpdatePanel 컨트롤은 부분적인 렌더링 요청을 찾고, 그것이 렌더링 되어야 하는지 결정하기 위해서 ScriptManager 컨트롤과 상호 작용(interact)을 합니다.
ScriptManager 컨트롤의 EnableScriptComponents 속성이 true일 경우, ScriptManager 컨트롤은 ASP.NET에 .js 라이브러리를 참조할 것을 알립니다. (이 때, 라이브러리는 단지 JavaScript 형태 뿐만 아니라, 클라이언트 UI 컴포넌트들과 행동(behaviors) 등에 대한 정의도 포함합니다.)
반면에 ScriptManager 컨트롤의 EnableScriptComponents 속성이 false(default 입니다.)일 경우, 페이지는 runtime 라이브러리만 참조합니다. 이것은 페이지에서 UI 컴포넌트들이나 행동(behaviors)을 다운로드 할 필요가 없는 경우에 대해 보다 경량화(lightweight)와 최적화(optimum)를 가능하게 합니다.
EnablePartialRendering 속성은 ScriptManager 컨트롤이 부분적 페이지 렌더링을 어떻게 할 것인지를 결정하게 합니다. 만약 이 속성이 true로 설정되면, ScriptManager 컨트롤은 UpdatePanel 컨트롤과 함게 웹 페이지에서 부분적 렌더링을 생성하고 제어하기 위해 많은 연산을 수행하게 됩니다.
반면에 이 속성이 false로 설정되면, 부분적 페이지 렌더링은 disable시키고, 오직 일반적인 postback만 지원하게 됩니다.
Service 속성은 클라이언트에서 위임된 JavaScript의 collection에 대해 설정합니다.
Script 속성은 ScriptReference 컨트롤의 collection에 대해 설정합니다.
3. 'Cross-browser': 어떠한 브라우저에서도 같은 화면을 보고 싶다. 우리 나라의 많은 웹사이트들은 지나치게 많은 것을 ActiveX에 모든 것을 의존하고 있다. 하지만, Active-X는 MS꺼라 IE에 대해서만 잘~ 동작한다.
결론, Atlas는 AJAX를 ASP.NET에서 구현의 편이성을 제공하기 위한 공짜 프레임워크이다.
"Atlas"의 기술적 기반인 'XMLHttpRequest'
프로토콜이란 녀석의 정체도 모르는 사람들조차 인터넷을 할 때 매번 보개되는 'http' ..
AJAX를 통해 해결하려는 일반적인 문제들은 대부분 HTTP 자체의 특성에서 비롯된다.
HTTP는?
브라우저가 웹 서버와 통신하여 웹페이지를 가져오고 데이터를 웹 서버에 다시 게시하기 위해 사용되는 표준 프로토콜이다. 이 녀석은 상태를 저장하지 못하는 방식의 프로토콜이므로 페이지를 새로 고침하기 전에는 사용자의 입력이 서버의 코드에 전달되지 않는다. 따라서 사용자가 입력한 페이지 내용은 새로 고침을 통해 서버에서 처리하고, 이 결과를 다시 HTML로 바뀌어 브라우저에 보여지게 된다.
결국, 기존의 웹 어플리케이션은 한마디로 페이지의 부분이 바뀌어도 페이지 전체가 새로 고침이 되어야 한다는 것이다. (새로 고침하는 중에는 사용자가 웹 페이지와 interaction도 불가능하다!-_-;)
AJAX는 이런 문제점을 개선하기 위해 전체 페이지를 새로 고침하지 않고! XMLHttpRequest를 사용한다.
How?!
XMLHttpRequest를 사용하면 수신한 XML을 기반으로 페이지의 업데이트할 부분을 JavaScript에서 직접 수정할 수 있다! (응? 결국 AJAX 엔진이 XML 문서만 분석하고서 알아서 수정할 부분을 고칠 수 있다는 의미다. 따라서, 서버에 전송하고, 새로 고침할 필요가 없어진다.)
따라서, 통신은 백그라운드로 진행되고, 나머지 작업을 진행할 수 있으므로.. 웹페이지와의 Interaction이 지속적으로 가능할뿐더러.. 사용자는 새로 고침이 일어나는 것을 느낄 수 없다. (물론, 부분적으로 업뎃이 발생하는 부분은 새로이 렌더링이 일어난다. 하지만, 페이지 전체가 새로 고침하지 않기 때문에.. 소위 깜빡임이 나타나지 않는 것.ㄷㄷㄷ)
ATLAS란.. ASP.NET에서 AJAX를 이용 가능하게 하기 위해 MS에서 내놓은 녀석이다.
아이러니 하게도 MS는 자신들이 만든 기술인 XMLHttpRequest로 인해 AJAX를 탄생하게 하였고, 그로 인해
MS를 새로이 위협(?)하는 구글이란 존재를 돋보이게 만들었다. (사실, 구글이 최근에 주목 받게 된 이유인 GMail, 구글맵, 구글 개인화 등이 모두 AJAX를 사용하였다.)
이러한 AJAX에 대한 비약적인 관심은 마찬가지로 MS의 기술인 ActiveX의 존재마저 위협하게 되며, MS는 울며 겨자먹기(?)로 .NET에서 AJAX의 구현이 가능하게 하기 위해 ATLAS란 녀석을 탄생시킨 것이다. (한마디로, 죽 써서 개줬다. 아닌가?-_-)
어쨌거나.. ATLAS를 이용한 Auto Completion 프로그램을 실행시키면 다음과 같다.
[그림 1. 첫 글자만 치면.. 연구실 사람들의 풀네임이 뜬다.]
[그림 2. Search를 누르면 인사말과 함께 현재 시간이 나온다.]
AJAX 기술을 이용해 만든 홈페이지에 가본 사람이라면 알겠지만.. 자동 완성 리스트가 뜰 때도 페이지 갱신(화면 새로 고침)은 일어나지 않으며! Search를 눌러도 페이지 갱신이 일어나지 않는다.
작지만 엄청난 AJAX의 능력이다..
마음 같아서는 구현한 웹페이지를 서버에 올려서 돌리고 싶었지만.. 아쉽게도 회사 방화벽으로 인해~ 외부에서 웹페이지에 접근할 수 없게 되어 있었다-ㅁ-
1. 웹 응용 프로그램
(1) 장점 (데스크톱 응용 프로그램에 비교해서...)
- 플랫폼에 독립적이다.
- 개발을 위한 방법이 간단하다.
(2) 단점
- 사용자 인터페이스의 종류가 단순하다.
- 응답 성능의 문제점.
ex) 웹 페이지에 로그인을 시도했을 때, 나타나는 페이지의 새로 고침하는 현상.
사용자의 응답 처리 시 발생하는 잦은 UI 끊김 현상
2. AJAX?! (1) AJAX는 뭘까?
- Asynchronous JavaScript And XML - AJAX = XHTML + CSS + JavaScript + DOM(Document Object Model) + XMLHttpRequest + etc...
- AJAX는 XML 기반의 웹서비스 언어를 사용 & 클라이언트에서는 JavaScript를 이용해 서버에 응답
- 브라우저와 웹서버 간의 데이터량 감소
- 웹 응용프로그램에서 보다 부드러운 응답 성능과 느낌을 유지.
- 별도의 프로그램을 설치할 필요성이 없음 <-> ActiveX Control, Flash, etc...
- AJAX의 구조
<제시 제임스 가렛이 비교한 이전의 웹응용 모델과 Ajax 웹응용 모델의 차이>
3. AJAX가 왜 혁신적인가?! - 비동기식 자바스크립트(Asynchronous JavaScript)의 강력함
- 서버의 응답을 기다리지 않고 작업이 가능하므로 대기 시간이 줄어든다. (고로, 서버의 부담도 준다.)
- 동기 방식은 사용자가 아이콘을 누르면 서버에 일일이 결과를 요청하고, 서버의 결과를 받아 받아 브라우저 화면에 보여주었다. (즉, JavaScript와 Browser는 전달자 역할만 했다.)
- Ajax를 이용하면 일일이 서버에 묻지 않고, Browser가 스스로 생각하면서 작업을 한다. (즉, Browser의 JavaScript는 부지런하게 사용자가 요청한 일을 하고, 서버와의 통신은 백그라운드로 처리, 그리고 JavaScript로 xmlhttp를 통해 XML 자료를 관리하기 때문에 페이지 재로딩이 불필요함.)
4. AJAX를 이용해 구현된 웹사이트의 예 - GMail(http://www.gmail.com)
- Google에서 구현함.
- 처음 편지를 읽어올 때만 Loading하고, 그 이후에는 JavaScript 차원에서 처리함.
- 편지나 그림, 글씨 등을 감추거나 보여줄 때 일단 JavaScript가 재빠르게 알아서 처리함. 따라서 로그인 후, 매우 빠른 속도를 보임.
- 구글지도(http://maps.google.com)
- 새로운 방식의 웹 접근이 가능함을 보여주는 예.
- 마우스를 따라 지도가 움직임.
- 구글지도의 진정한 힘(AJAX의 진정한 힘)
- HTML 문서 안에서 이루어짐.
- 별도의 기능을 갖춘 새창이 불필요.
- 별도의 프로그램 다운로드 불필요
Comments