라이브러리
프로그래밍언어, 각종코드, 관련동향, 논문 등의 저장소
Technology/WEB 2.0 (27)
[Trend of IT] What is Web2.0 ?

What is Web2.0 ?

 

내가 Web2.0이라는 개념을 알게 된 것은 2006년 1월 쯤이였을 것이다. 때마침 사용하고 있던 블로그와 맞물려 심심치 않게 듣게 되었던 Web2.0은 당시의 반짝 이슈가 아닌 웹의 트렌드로서 당당히 자리 매김 하였다. 이미 Web2.0은 뜬구름형 개념이 아닌 어느정도 규격화를 거치면서 마케팅과 각종 웹 서비스 기업에 필수적으로 알고 넘어가야할 지식이 되었다.

 

벌써 심심치 않게 Web3.0을 이야기 해보고자 하는 사람들이 생겨나고 있지만 트렌드의 지속성이 꽤나 오래갈 것으로 예상 되므로 즉, 시멘틱웹이 실현되기 위해서는 원론적, 기술적 한계성이 아직 존재하므로, Web2.0을 사적인 일과 맞물려 간단히 정리해보고자 한다.

 

시멘틱 웹

:: 웹을 자율적인 데이터베이스로서 가능하게끔하게하는 시도의 일환(웹 = 데이터베이스)

 

작년 컨퍼런스 참가 때 나는 마케터로서의 입장과 기술자로의 입장, 이 두가지 입장에서 Web2.0을 바라볼 수 있게되어 너무나 즐거웠다. 우선 원론적으로 정리하고 차후에 기술적으로 정리하려 한다.

 

참고서적은 '웹2.0이노베이션'이며 Oreilly의 Oreillynet.com에서 영어공부를 병행하며(-_-a) 즐거히 정리하고 있음을 알려드립니다.

 

 
::
 

사용자 삽입 이미지

 

Web2.0 ?

:: 웹의 자연적인 흐름에 따른 웹의 새로운 트렌드

:: 웹 데이터를 구조화(데이터베이스화) 하며 웹서비스(웹 표준규격을 사용하여 다른 플랫폼 상의 어플리케이션을 연결하는 기능)가 가능

:: 데이터구조화를 위해 적합한 언어인 XML을 주요 이용

:: 롱테일의 법칙 적용 (파레토의 법칙과는 달리 2:8 중 8의 비중이 전체에 중요한 비중을 두고있음)

 

 

Oreilly의 Web2.0기업 정의

::서비스제공자로서 역할 - 패키지소프트웨어가 아닌 서비스를 제공하고 있을 것(ex- MSN)

:: 데이터 소스를 구축하고 제공 역할- 웹2.0이라는 데이터베이스에 데이터를 제공할 것 

:: 사용자의 무의식적인 참여 촉구- 사용자를 신뢰하고 사용자로부터 피드백을 개발에 반영할 것

::Collective Intelligence를 이용- 사용자 전체를 데이터베이스화

::롱테일을 이해 할 것- 틈새 시장을 대상으로 한 비지니스 모델을 구축

::플랫폼을 가리지 않을 것- PC, 휴대전화등 여러 플랫폼에서 서비스를 제공

::Rich User Experience- 오픈소스기술(ex-ajax)을 다양하게 사용 재활용하기 좋은 서비스 제공

 

 

Web2.0 서비스 모델의 필수 요소

::정보의 수신- 유저가 웹에서 효율적인 정보 습득 가능

::정보의 발신- 유저가 웹에 효율적인 정보 제공 가능

::정보의 검색- 유저가 웹에서 쉽게 검색 가능

::정보공유- 다른 유저들과의 정보공유가 가능

 

 

웹의 탄생과 Web2.0, 그리고 구글

1. 월드와이드웹 탄생 : 여러개의 HTML문서가 하이퍼링크를 통해 연결되어 있는 네트워크

2. 하이퍼링크는 상호링크가 아니기 때문에 HTML을 통해 구성된 웹은 비구조적 -> web2.0탄생

3. 모자이크 탄생 : 이미지까지 표시가능한 웹 브라우져

4. 네스케이프 탄생 : 웹을 일반인들에게도 사용하게 끔 한 시발점인 셈(SSL -> RSS)

5. 브라우져 경쟁시대 : 네스케이프 -> Explorer 주도권 전이

6. 포털사이트 등장 : 야후(포털사이트의 비지니스화 기여:베너광고 등)

7. 포털사이트의 미디어화 : 트레픽의 집중화 노력(포털 스스로 컨텐츠 제공)

8. 구글- 로봇형 검색구조 재부활 : 분산모델에 따른 스케일러블 크롤러 + 피크링수에 따른 웹사이트 구분

9, 검색서비스의 중요성 대두 : 야후와 구글의 검색서비스 계약 체결 -> 구글의 성장 원동력

10. 포털 웹 비지니스 수입원천 변화 : 배너광고에서 검색결과 연동 광고(구글 애드센스)

11. SEO(Search Engine Opimizing)와 블로그에 따른 웹의 구조화

12. RSS(Really Simple syndication)피드, Ajax, Open API 제공등 웹2.0실현을 위한 기술 보급

13. 소셜태깅에 의한 Folksonomy 등장 : 참여형 아키텍쳐의 시작

Final. 웹 = 플랫폼 : -> 데이터베이스 구조화에 따른 유비쿼터스 시대의 디딤돌 역활.

 


 
  Comments,     Trackbacks
[Ajax] Ajax 마스터하기 - DOM 다루기 [PART 05]

[Ajax] Ajax 마스터하기 - DOM 다루기 [PART 05]

 

개요
PART 01/ Ajax 소개
PART 02/ JavaScript와 Ajax를 이용한 비동기식 요청
PART 03/ Ajax의 고급 요청 및 응답
PART 04/ 웹 응답에 DOM 활용하기
PART 05/ DOM 다루기


 

HTML, JavaScript™, DHTML, DOM으로 구성된 Ajax는 볼품없는 웹 인터페이스를 인터랙티브 Ajax 애플리케이션으로 변형하는 획기적인 방식이다. Ajax 전문가인 필자는 이러한 기술들이 어떻게 작용하는지 전체적인 개요를 비롯하여 세부사항 까지 설명한다. 또한 XMLHttpRequest 객체 같은 Ajax의 중심적인 개념들을 소개한다.

 

5년 전, XML에 대해 무지했다면 아무도 얘기할 상대가 없는 미운 오리 새끼 신세가 되었을지도 모르겠다. Ruby 프로그램이 주목을 받았던 8개월 전, Ruby 프로그램 언어 기능에 대해 알지 못했던 프로그래머들은 냉수기 관련 산업세계에서 환영 받지 못했다. 그런 것처럼, 최신 기술단계로 입문하고자 한다면 Ajax에 대해 알아야 한다.

하지만 Ajax는 일시적으로 유행하는 툴이 아니다. 웹 사이트를 구축하는 강력한 방식이며 완전히 새로운 언어를 배우는 것보다는 그다지 어렵지 않다.

Ajax에 관해 자세히 들어가기 전에 잠시 Ajax의 기능에 대해 알아보자. 오늘날 애플리케이션을 작성할 시 두 가지 애플리케이션이 있다.

  • 데스크톱 애플리케이션
  • 웹 애플리케이션

두 애플리케이션은 다 친숙한 것들이다. 일반적으로 데스크톱 애플리케이션은 CD상에 배치된 다음 (또는 웹 사이트에서 다운로드) 컴퓨터에 완전 설치된다. 이 애플리케이션은 인터넷을 이용해 업데이트를 다운로드하기도 하지만 애플리케이션 실행 코드는 데스크톱 상에 상주해 있다. 전혀 새로운 것이 아닌 웹 애플리케이션은 웹 서버 상에서 실행되며 웹 브라우저 상에서 접속된다.

하지만 두 애플리케이션에 대한 코드 실행 위치보다 애플리케이션 작동방식 및 애플리케이션과 사용자와의 상호작용방식이 중요하다. 일반적으로 데스크톱 애플리케이션은 상당히 빠르고 (컴퓨터 상에서 실행되고 인터넷 상에서 대기 중인 상태가 안 나온다.), 대형 사용자 인터페이스(일반적으로 운영체제와 상호작용)를 갖추며 상당히 동적이다. 거의 대기시간 없이 메뉴 및 하위 메뉴를 클릭, 지시, 입력하고 풀업한다.

반면 웹 애플리케이션은 가장 최신 것이며 데스크톱에서는 전혀 얻을 수 없는 서비스를 제공한다.(Amazon.com 및 eBay를 생각해 볼 것.) 하지만 웹 애플리케이션 기능으로 인해 서버 응답 대기, 스크린 재생 대기, Request 컴백 및 새 페이지 생성에 관한 대기 기능 등이 부수된다.

분명 지나친 단순화 과정임에는 틀림없지만 기본 개념은 얻게 된다. 이미 눈치를 챘겠지만 Ajax는 데스크톱 애플리케이션 및 항상 업데이트 되는 웹 애플리케이션의 기능 및 상호작용 간의 차이를 줄여주는 역할을 한다. 여러분은 마치 데스크톱 애플리케이션에서 찾은 것처럼 동적 사용자 인터페이스 및 가상 제어기능을 사용한다. 하지만 웹 애플리케이션 상에서 데스크톱 애플리케이션을 이용할 수 있다. 그러면 대기 중인 것이 무엇인가? Ajax 및 볼품없는 웹 인터페이스가 응답 Ajax 애플리케이션으로 변환되는 과정에 대해 살펴보기로 하자.

그러면 대기 중인 것이 무엇인가? Ajax 및 볼품없는 웹 인터페이스가 응답 Ajax 애플리케이션으로 변환되는 과정에 대해 살펴보기로 하자.

 

 

오래된 기술, 새로운 기법

 

Ajax에 관해 살펴보면 Ajax는 실지로 많은 기술들이 응집되어 있다. Ajax의 기본을 마치고 넘어가려면 몇 가지 다른 기술들(필자는 첫 번째 이 시리즈에서 각각의 기술에 관해 설명할 것이다.)을 면밀히 살펴보아야 한다. 하지만 이들 기술 가운데 어느 정도 알고 있는 것이 많은 건 다행이다. 더군다나 각각의 기술 대부분은 Java/Ruby같은 프로그래밍 언어만큼 어려운 게 아니라서 배우기 쉽다.

Ajax 애플리케이션에 포함된 기본기술은 다음과 같다.

  • 웹 양식을 구축하고 애플리케이션 완료 때까지 사용되는 필드를 식별하는 데 HTML을 사용한다.
  • 자바 스크립트 코드는 Ajax 애플리케이션을 실행하는 중심 코드며 서버 애플리케이션과의 커뮤니케이션을 용이하게 한다.
  • DHTML(동적 HTML)은 웹 양식을 동적으로 업데이트 한다. div, span및 기타 동적 HTML 요소를 사용해 HTML을 마크업 한다.
  • 서버에서 복귀된 HTML 및 (때로) XML 구조를 다루는 데 있어 DOM, 즉 문서 객체 모델(Document Object Model)을 사용한다.

    이 기술들에 대해 간략히 요약하고 각 기술의 기능에 대해 좀 더 알아보기로 하는데 각 기술에 관한 자세한 사항은 차후 글에서 다룰 것이다. 우선은 Ajax의 구성요소 및 기술에 대해 친숙해 지는 데 초점을 맞추기로 한다. 자바 스크립트에 익숙할수록 Ajax에 담긴 기술에 관한 일반적인 지식 단계에서 각 기술에 관한 자세한 지식으로 넘어가는 게 더 쉬워진다.(또한 이로 인해 웹 애플리케이션 개발에 관한 문이 열리게 된다.)

     

    Ajax 정의
    Ajax는 비동기 JavaScript 및 XML의 약어이다.(DHTML도 마찬가지다.) Adaptive Path사의 Jesse James Garrett이 이 약어를 만들어냈으며(참고자료 참조), Jesse에 따르면 이 약어는 두문자어는 아니라고 한다.

     

     

     

    XMLHttpRequest 객체

     

    알고자 하는 객체 중 첫 번째는 아마도 가장 생소한 것이 아닌가 싶다. 그 객체는 일명 XMLHttpRequest인데 자바 스크립트 객체의 일종이며 Listing 1에 나와 있는 것처럼 단순하게 생성된다

     

    Listing 1. 새로운 XMLHttpRequest 객체 생성


    <script language="javascript" type="text/javascript">
    var xmlHttp = new XMLHttpRequest();
    </script>

     

    필자는 다음 글에서 이 객체에 대해 더 논의할 것이다. 하지만 지금 상태에서는 모든 서버 커뮤니케이션을 다루는 객체라는 사실만 알아둔다. 다음 사항으로 가기 전에 잠깐 생각해 보면 자바 스크립트 객체는 XMLHttpRequest를 통해 서버에 전달하는 자바 스크립트 기술의 일종이다. 이 객체는 애플리케이션 흐름이 정상적이지 않으며 Ajax 기술의 많은 부분을 차지하고 있다.

    정상적인 웹 애플리케이션에서 사용자는 양식 필드를 기입하며 제출 버튼을 클릭한다. 그러면 전 양식을 서버에 보내며 서버는 처리과정을 통해 양식을 스크립트(일반적으로 PHP, 자바 또는 CGI 과정/이와 유사한 과정)에 전송한다. 스크립트를 실행할 때 스트립트를 통해 완전히 새로운 페이지가 전송된다. 그 페이지는 데이터가 작성된 새로운 양식의 HTML/확인 페이지 또는 원 양식에 기입된 데이터에 근거해 선택된 옵션이 포함된 페이지일 수 있다. 물론, 서버 상의 스크립트/프로그램이 처리되면서 새로운 양식을 다시 보내는 동안 사용자는 대기해야 한다. 서버로부터 데이터를 다시 받을 때까지는 스크린 상에 아무 것도 없게 되며 결국 대화성은 낮게 된다. 사용자는 즉각적으로 응답을 받지 못하며 데스크톱 애플리케이션 상에서 작업하는 기분이 들지 않게 된다.

    Ajax는 근본적으로 자바 스크립트 기술 및 웹 양식 및 서버 간의 XMLHttpRequest 객체를 결합한다. 사용자가 웹 양식을 기입할 때 데이터는 직접 서버 스크립트에 전송되지 않고 자바 스크립트 코드에 전달된다. 대신 자바 스크립트 코드는 양식 데이터를 포착해 Request를 서버에 전송한다. 이 과정이 일어나는 동안, 사용자 스크린 상의 양식은 순식간에 나타나거나 깜빡이거나 사라지거나 정지하지 않는다. 즉 자바 스크립트 코드는 몰래 Request를 전송하며 사용자는 Request가 만들어졌는지도 알지 못한다. 게다가 Request를 비동기적으로 전송하기 때문에 더 좋은 상황이 된다. 이는 자바 스크립트에서 서버 응답을 그냥 대기하지 않는다는 것을 의미한다. 따라서, 사용자는 데이터를 계속 기입하고 화면이동하고 애플리케이션을 사용한다.

    그런 다음 서버는 자바 스크립트 코드(웹 양식에 대해 아직도 대기 중임)에 데이터를 다시 전송한다. 자바 스크립트 코드에서는 데이터와의 상호기능을 결정하며 연속적으로 양식 필드를 업데이트 하면서 애플리케이션에 즉각적인 응답을 준다. 결국 사용자는 양식을 제출/재생하는 작업 없이 새로운 데이터를 얻게 된다. 자바 스크립트 코드는 데이터를 얻고 계산도 수행하며 또 다른 Request를 전송하며 이런 모든 과정은 사용자 개입 없이도 된다! 이것이 바로 XMLHttpRequest 객체의 장점이다. XMLHttpRequest 객체는 서버와 같이 커뮤니케이션을 주고받고 사용자는 그 과정에서 벌어지는 과정을 알지 못한다. 이로 인해 데스크톱 애플리케이션과 마찬가지로 동적, 상호 반응적인 고도의 양방향 경험을 얻게 되지만 그 속에 인터넷의 모든 장점이 담겨 있다.

     

     

    자바 스크립트에 대한 부가사항

     

    일단 XMLHttpRequest에 대해 다루게 되면 나머지 자바 스크립트 코드는 상당히 평범한 것들이다. 사실 다음과 같은 기본적인 작업에 자바 스크립트 코드를 이용한다.

  • 양식 데이터 얻기: 자바 스크립트 코드로 HTML 양식에서 데이터를 꺼내 이를 서버에 전송하는 작업이 간단해진다.
  • 양식 상의 값 변환: 필드 값 설정에서 연속적인 이미지 교체작업에 이르는 양식 업데이트 작업 또한 간단하다.
  • HTML 및 XML 구문분석: 자바 스크립트 코드를 이용해 DOM(다음 섹션 참조)을 처리하고 서버에서 다시 전송하는 HTML 양식 및 임의의 XML 데이터에 관한 구조를 다루게 된다.

    첫 번째 두 항목에 대해서 여러분은 Listing 2에 나온 대로 getElementById()에 익숙해지려 할 것이다.

     

    Listing 2. 자바 스크립트 코드에서의 필드 값 포착 및 설정

    // Get the value of the "phone" field and stuff it in a variable called phone
    var phone = document.getElementById("phone").value;

    // Set some values on a form using an array called response
    document.getElementById("order").value = response[0];
    document.getElementById("address").value = response[1];

     

    Ajax 애플리케이션에서 특별히 획기적인 사항은 없고 상기 사항 정도면 충분하다. 이에 대해 상당히 복잡한 건 없다는 사실을 깨달아야 한다. 일단 XMLHttpRequest만 정복하면 Ajax 애플리케이션에서 나머지는 대부분 Listing 2에 나온 바와 같이 상당히 독창적인 HTML과 결합된 단순 자바 스크립트 코드다. 그런 다음 가끔 약간의 DOM 작업이 발생하게 된다. 이에 관해 살펴 보자.

     

     

    DOM으로 종료하기

     

    DOM, 즉 문서 객체 모델이라는 것이 있는데 이는 아주 중요하다. DOM에 대해 듣는 것은 그다지 어렵지 않다고 하는 사람들이 있다. HTML 디자이너에 의해서는 종종 사용되지 않으며 하이-엔드 프로그래밍 작업으로 들어가지 않는 한은 JavaScript 코더에서 흔치 않은 것이 바로 DOM이다. 종종 과중-업무 Java 및 C/C++ 프로그램 상에서 DOM을 종종 많이 활용하게 된다. 사실은 DOM이 배우기 어려운 특성 때문에 명성이 자자해 그 프로그램 상에서 종종 사용하는 것이 아닌가 싶다.

    다행히도 JavaScript 기술에 있어 DOM을 활용하는 일은 쉽고 대부분 직관적이다. 이 시점에서 필자는 DOM 사용법에 관해 보여 주고 적어도 이에 대한 몇 가지 코드 예를 제시하려 하지만 이 글의 의도와는 벗어나는 것 같다. DOM에 관해 대략적으로 다루는 것 없이도 Ajax에 대해 깊이 다룰 수 있다. 필자는 차후의 글에서 다시 DOM에 관해 다루려 한다. 하지만 지금 상황에서는 언급하지 않으려 한다. JavaScript 코드와 서버 사이에 XML을 이리저리 전송하고 HTML 양식을 변화시킬 때 DOM에 대해 자세히 다루게 될 것이다. 지금은 DOM없이 효과적인 Ajax 애플리케이션을 작동하는 게 쉬우므로DOM은 논외로 한다.

     

     

    Request 객체 얻기

     

    Ajax 애플리케이션에 관한 기본적 개념에 대해 배웠으면 몇 가지 특수사항에 대해 살펴 보자. XMLHttpRequest 객체는 Ajax 애플리케이션에서 중요하므로, 아마도 많은 이들에게는 생소한 것일 수도 있다. 거기서 필자는 논의를 시작한다. Listing 1에서 보다시피, XMLHttpRequest 객체를 생성, 사용하는 것은 상당히 쉬워야 한다. 잠깐만 기다려 보시라.

    수년 동안 브라우저에 관한 논란은 끊이지 않았고 동일한 브라우저로는 아무 것도 얻을 수 없다는 사실을 기억하는가? 믿건 말건, 소규모 브라우저에서도 이와 같은 논쟁은 끊이지 않고 있다. 더군다나 놀라운 사실은 XMLHttpRequest가 이 논란의 희생양 중 하나라는 것이다. 따라서 XMLHttpRequest 객체를 작동시키기 위해선 몇 가지 다른 작업을 해야 한다. 단계별로 설명하겠다.

     

     

    Microsoft 브라우저 다루기

     

    Microsoft 브라우저, Internet Explorer는 XML을 다룰 시 MSXML 구문분석계를 사용한다.(참고자료 참조) Internet Explorer 상에서 다뤄야 할 Ajax 애플리케이션을 작성할 시 독특한 방식으로 XMLHttpRequest 객체를 작성해야 한다.

    하지만 그렇게 간단한 작업은 아니다. Internet Explorer에 설치된 JavaScript 기술 버전에 따라 MSXML 버전도 변하게 되며 실지로 2개의 버전이 있다. 따라서 두 경우를 다루는 코드를 작성해야 한다. Microsoft 브라우저 상에서 XMLHttpRequest 객체를 생성하는 데 필요한 코드에 관해선 Listing 3을 보라.

     

    Listing 3. Microsoft 브라우저 상에서 XMLHttpRequest 객체 생성

    var xmlHttp = false;
    try {
    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e2) {
    xmlHttp = false;
    }
    }

     

    모든 작업이 정확히 맞아떨어지는 것은 아니다. 하지만 그래도 상관없다. 이 시리즈가 끝나기 전에 JavaScript 프로그래밍, 에러 취급 및 조건부 번역 및 기타 사항에 관해 자세히 다루게 될 것이다. 지금 현 상태에서는 두 가지 중심 라인만 다루고자 한다.

     

    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    and
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");.

     

    간단히 말해서, 이 코드로 MSXML의 한 버전을 이용해 XMLHttpRequest 객체 생성을 기한다. 하지만 객체가 생성되지 않는 경우 다른 버전을 사용해 XMLHttpRequest 객체를 생성한다. 두 코드 다 작동되지 않는 경우 xmlHttp 변수는 거짓으로 설정되고 작동되지 않는 것이 있다는 것을 코드에 알려 준다. 그럴 경우, 비-Microsoft 브라우저가 있을 가능성이 있다. 따라서 객체 생성을 위해선 다른 코드를 사용해야 한다.

     

     

    Mozilla 및 Microsoft 브라우저 다루기

     

    인터넷 브라우저를 선택하지 않거나 비-Microsoft 브라우저를 작성할 경우 다른 코드가 필요하다. 사실, 이 라인은 Listing 1에서 봤던 단순 코드라인이다.

     

    var xmlHttp = new XMLHttpRequest object;.

     

    이 단순한 라인으로 Mozilla, Firefox, Safari, Opera 및 임의의 양식/형태에서 Ajax애플리케이션을 지원하는 기타 비-Microsoft 브라우저에서 XMLHttpRequest 객체를 생성한다.

     

     

    지원기능 통합

     

    여기서 모든 브라우저를 지원하는 것이 중요하다. Internet Explorer/비-Microsoft 브라우저에서만 작동되는 애플리케이션을 작성하는 사람이 어디 있겠는가? 또한 더 심한 경우, 애플리케이션을 두 번 작성하고자 하는가? 물론 아니라고 믿는다. 따라서 코드에선 Internet Explorer 및 비-Microsoft 브라우저를 지원하는 기능이 포함되어야 한다. Listing 4에서는 다중-브라우저 방식으로 작동하는 코드에 대해 나와 있다.

     

    Listing 4. 다중 브라우저 방식으로 XMLHttpRequest 객체 생성하기

    /* Create a new XMLHttpRequest object to talk to the Web server */
    var xmlHttp = false;
    /*@cc_on @*/
    /*@if (@_jscript_version >= 5)
    try {
    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e2) {
    xmlHttp = false;
    }
    }
    @end @*/

    if (!xmlHttp && typeof XMLHttpRequest != 'undefined') {
    xmlHttp = new XMLHttpRequest();
    }

     

    지금 현재로선, 주석 및 @cc_on와 같은 어려운 태그를 무시한다. 이들은 다음 글에서 깊이 다룰 JavaScript 컴파일러 명령으로 오로지 XMLHttpRequest 객체 상에만 초점이 맞추어져 있다. 이 코드에 관한 핵심은 세 가지 과정으로 요약된다.

    1. 변수 xmlHttp를 생성해 앞으로 생성할 XMLHttpRequest 객체를 참조한다.
    2. Microsoft 브라우저에서의 객체를 시도, 생성한다.

    • Msxml2.XMLHTTP 객체를 사용해 XMLHttpRequest 객체를 시도, 생성한다.
    • 과정이 실패할 경우, Microsoft.XMLHTTP 객체를 사용해 XMLHttpRequest 객체를 시도, 생성한다.

    3. xmlHttp가 아직도 설정되지 않은 경우 비-Microsoft 방식으로 XMLHttpRequest 객체를 생성한다.

    위 과정 끝 단계 시 사용자가 실행하는 브라우저 종류에 관계없이 xmlHttp의 경우 유효한 XMLHttpRequest 객체를 인용한다.

     

     

    보안

     

    보안이란 무엇인가? 오늘날 브라우저는 사용자들에게 보안 레벨을 올리고 JavaScript 기술을 생성하며 브라우저 옵션을 해제하는 기능을 제공한다. 이 경우 코드가 작동되지 않는 경우도 있을 수 있다. 그 때 발생하는 문제를 적절하게 다뤄야 한다. 이에 관한 내용은 적어도 기사 한 분량을 차지할 정도라 나중에 다루기로 하겠다.(긴 시리즈가 될 것 같다, 그렇지 않은가? 하지만 걱정 마시라. 과정을 다 배우고 나면 이와 관련된 모든 사항을 숙달할 테니까.) 현재로선 강력하지만 완전하지 않은 코드를 작성하는 중이다. 이 코드는 Ajax 애플리케이션을 관리하는 데 좋다.

     

     

    Ajax 세계에서의 Request/Response

     

    인제 Ajax 애플리케이션에 대해 이해하고 XMLHttpRequest 객체 및 객체 생성에 관한 기본적인 개념을 얻는다. 자세히 읽다 보면 Ajax 애플리케이션은 웹 애플리케이션에 제출되는 HTML 양식보단 서버 상의 임의의 웹 애플리케이션에 대화하는 JavaScript 기술이라는 사실을 알게 된다.

    그러면 빠진 부분은 어떤 것인가? 실질적인 XMLHttpRequest 객체 사용법이다. 이 객체는 작성하는 각각의 Ajax 애플리케이션에서 일정 형태로 사용하는 중요 코드라 Ajax 애플리케이션이 포함된 기본 Request/응답 모델 모양을 통해 객체 사용법을 빨리 익힌다.

     

     

    Request 만들기

     

    새로운 XMLHttpRequest 객체가 있는 경우 이를 시험해 보자. 먼저 웹 페이지에서 호출하는 JavaScript 방법이 필요하다.(사용자가 텍스트에서 입력하거나 메뉴에서 옵션을 선택할 시와 같음.) 그 다음, 거의 모든 Ajax 애플리케이션에서의 동일한 기본 아웃라인을 따른다.

    1. 웹 양식으로부터 필요한 모든 데이터 얻기
    2. 연결할 URL 구축
    3. 서버 연결
    4. 서버 실행 종료 시 서버 실행 기능 설정
    5. Request 전송

    Listing 5는 위의 순서대로 5단계를 진행하는 Ajax 방법의 예에 관해 나와 있다.

     

    Listing 5. Ajax가 포함된 Request 만들기

    function callServer() {
    // Get the city and state from the web form
    var city = document.getElementById("city").value;
    var state = document.getElementById("state").value;
    // Only go on if there are values for both fields
    if ((city == null) || (city == "")) return;
    if ((state == null) || (state == "")) return;

    // Build the URL to connect to
    var url = "/scripts/getZipCode.php?city=" + escape(city) + "&state=" + escape(state);

    // Open a connection to the server
    xmlHttp.open("GET", url, true);

    // Setup a function for the server to run when it's done
    xmlHttp.onreadystatechange = updatePage;

    // Send the request
    xmlHttp.send(null);
    }

     

    Ajax 코드에 관한 많은 것이 명백하다. Ajax 코드의 첫번째 비트는 몇 가지 양식 필드 값을 포착하는 기본 JavaScript 코드를 사용한다. 그런 다음 이 코드에서는 연결 최종 목적지로 PHP 스크립트를 설정한다.

    PHP 스크립트의 URL을 지정한 다음(양식에서 나온) 단순한 GET 매개변수를 이용해 이 URL에 도시 및 국가를 추가한다. 그 다음 연결하면 먼저 XMLHttpRequest 객체가 작동되는 것을 보게 된다. 연결방법은 연결 URL 뿐만 아니라, GET 매개변수에도 나와 있다. 최종 매개변수를 true로 설정한 경우, 이 매개변수에선 비동기식 연결(Ajax를 만든다.)을 요구한다. false로 설정한 경우엔 Request를 만들 시 서버 상에서 Ajax에서의 JavaScript 코드가 대기하고 응답을 받을 때 코드가 지속된다. 사용자는 최종 매개변수를 true로 설정하면서 서버에서 배경에 있는 Request를 처리하는 동안 사용자는 웹 양식(심지어는 기타 JavaScript 방식)을 여전히 사용한다.

    한편 xmlHttp(이것은 XMLHttpRequest 객체의 인스턴스라는 사실을 기억하라.)의 onreadystatechange 속성으로 서버 실행이 종료될 시(5분/5시간 내에 종료될 수 있음) 서버 기능을 명령한다. 이 코드는 서버 상에서 대기하지 않기 때문에 서버가 기능을 인식해 서버에 응답할 수 있도록 하는 게 필요하다. 이 경우 서버에서 Request를 처리하면서 종료 시 이른바 updatePage()라 불리는 특수 방법을 트리거한다.

    최종적으로 send() 코드를 0(null) 값으로 호출한다. 데이터를 추가해 이를 서버에 전송하므로 Request에는 추가해서 보낼 게 없다. 이렇게 되면 Request를 발송하고 서버는 서버에 요구된 기능을 실행한다.

    이 코드에서 나오는 것이 없는 경우, 코드가 상당히 간단하다는 것을 명심하라. 이 코드는 Ajax 애플리케이션의 비동기적 특성을 제외하고는 상당히 단순하다. 이 코드를 통해 복잡한 HTTP Request/응답 코드보다는 근사한 애플리케이션 및 인터페이스에 완전 초점을 맞추도록 한다는 사실을 여러분은 높게 평가할 것이다.

    Listing 5의 코드는 코드를 얻는 방법만큼이나 쉽다. 데이터는 단순 텍스트이고 Request URL의 일부로 포함된다. GET 매개변수는 더 복잡한 POST대신 Request를 전송한다. 여기에 덧붙일 XML/컨텐츠 헤더가 없고 Request 본체에 전송할 데이터도 없다. 이게 바로 Ajax 유토피아다.

    그렇다고 미리 겁먹지 마라. 시리즈가 계속될수록 문제는 더 복잡해진다. 그 때는 POST Request를 전송하는 방법, Request 헤더 및 컨텐츠 형식을 설정하는 방법, 메시지에 XML을 설정하는 방법 및 Request에 보안기능을 추가하는 방법을 배우게 되는데 배우는 목록만 해도 상당히 길다! 지금은 이런 어려운 주제에 대해 신경 쓰지 말자! 그냥 기본만 충실하게 익히면 Ajax 전체 툴을 구축하게 된다

     

     

    응답 취급과정

     

    이제 서버 응답을 실지로 취급해야 한다. 이 시점에서는 정말로 두 가지 사항만 알면 된다.

  • xmlHttp.readyState 속성이 4와 같을 때까지는 어떤 작업도 해선 안 된다.
  • 서버는 xmlHttp.responseText 속성에 응답한다.

    2가지 항목 중 첫번째 항목인 준비 상태에 관해선 다음 글에서 대부분 다룰 것이다. 그 때는 HTTP Request 단계에 대해 알고 싶은 것 이상으로 배우게 된다. 지금 현재로선, xmlHttp.responseText 속성 값 4를 단순 점검하는 경우, 작업이 계속 진행된다.(다음 글에서 기대할 만한 사항이 나오게 된다.) 서버 응답을 얻기 위해 xmlHttp.readyState 속성을 사용하는 과정인 두 번째 항목은 쉽다. Listing 6은 Listing 5에서 전송된 값에 근거해 서버에서 호출하는 방법에 관한 예를 보여준다.

     

    Listing 6. 서버 응답 취급하기

    function updatePage() {
    if (xmlHttp.readyState == 4) {
    var response = xmlHttp.responseText;
    document.getElementById("zipCode").value = response;
    }
    }

     

    다시 보면, xmlHttp.readyState 코드는 그리 어렵거나 복잡하지 않다. 이 코드는 서버에서 해당 준비 상태로의 호출을 대기하고 서버에서 다시 복귀되는 값(이 경우, 사용자 기입 도시 및 국가에 대한 ZIP 코드)을 사용해 또 다른 형태의 양식 필드를 설정한다. 그 결과, zipCode 필드는 ZIP 코드와 함께 갑자기 나타난다. 하지만 사용자는 버튼을 클릭해서는 안 된다! 그게 바로 이전에 말했던 데스크톱 애플리케이션이다. Ajax 코드에는 응답성, 동적 상태 외의 더 많은 것이 있다. 독자들은 zipCode가 정상 텍스트 필드라는 것을 눈치챘을지도 모른다.

    일단 서버에서 zipCode를 복귀시키고 updatePage() 방식으로 도시/국가 ZIP 코드와 함께 zipCode 필드 값을 설정하는 경우 사용자는 값을 무효로 한다. 값을 무효로 하는 데는 두 가지 이유가 있다. 예에서 나오는 상황을 단순화시키고, 때로는 사용자가 서버에서 명령하는 것을 무효로 하기 위해서다. 이 두 가지를 명심하라. 좋은 사용자-인터페이스 설계를 위해 중요하다.

     

     

    웹 양식 다루기

     

    그러면 이 글에서 다룰 게 남아 있는가? 그다지 많지 않다. 양식에 기입할 정보를 포착해 이를 서버에 전송하고 응답에 관해 취급할 또 다른 JavaScript 방법을 제공하면서 심지어는 다시 응답될 때 필드 값을 설정하기까지 하는 JavaScript 방법을 다룬다. 여기서는 첫번째 JavaScript 방법을 호출해 전 과정을 시작하기만 하면 된다. 분명 HTTL 양식에 버튼을 추가하지만 2001년 버전과 거의 동일하다고 생각되지 않는가? Listing 7과 같이 JavaScript 기술을 활용한다.

     

    Listing 7. Ajax 프로세스 시작

    <form>
    <p>City: <input type="text" name="city" id="city" size="25"
    onChange="callServer();" /></p>
    <p>State: <input type="text" name="state" id="state" size="25"
    onChange="callServer();" /></p>
    <p>Zip Code: <input type="text" name="zipCode" id="zipCode" size="5" /></p>
    </form>

     

    이런 단면이 루틴 코드의 한 단면 이상을 보여준다고 생각된다면 맞는 말이다. ? 그렇다! 사용자가 도시/국가 필드에 관한 새로운 값을 입력할 경우 callServer() 방식을 전송한 다음 Ajax 애플리케이션이 시작된다. 이제 여러 상황을 다룰 만하다고 느껴지기 시작하는가? 좋다! 바로 그거다!

     

     

    맺음말

     

    이 시점에서 적어도 리소스 란에서 Ajax 애플리케이션에 관해 깊숙이 알려고 하는 경우, 첫번째 Ajax 애플리케이션을 작성할 준비가 되어 있지 않을 게다. 하지만 이런 애플리케이션이 작동하는 기본 개념 및 XMLHttpRequest 객체의 기본 개념을 이해하기 시작한 경우 이 객체, JavaScript-서버 간 대화 취급방식, HTML 양식 취급 및 심지어 DOM 관리 방식까지 모든 것을 배워야 한다.

    지금 현재로선, Ajax 애플리케이션이 얼마나 강력한 툴인지 생각하는 데 시간을 보낸다. 버튼만 클릭할 뿐만 아니라 필드에 입력하고 콤보 상자에서 옵션을 선택하고 심지어는 마우스를 스크린 주위에 끄는 경우 응답하는 웹 형식을 상상해 본다. 비동기식의 정확한 의미 및 Request 상에서 응답하기 위해 서버 상에서 실행하지만 대기하지 않는 JavaScript 코드에 관해 생각해 본다. 여러분이 부딪치는 문제의 종류는 어떤 것인가? 어떤 영역의 문제에 주의를 기울일 것인가? 프로그래밍에 이 새로운 접근방식을 설명하기 위해 양식 설계를 변환하는 방법은 어떤 것인가?

    이런 문제에 관해 실지로 생각할 시간을 보낸다면 잘라 붙이는 코드를 가지고 이를 잘 이해하지 못하는 애플리케이션에 포함시키는 것보다는 훨씬 더 낫다. 다음 글에서는 이와 같은 개념을 실제 작업에 응용해 본 작업에서처럼 애플리케이션을 만들어야 하는 코드에 관한 자세한 정보를 제공하기로 한다. 그 때까지 Ajax 애플리케이션의 가능성을 마음껏 즐겨라.

     

     

    참고자료

    교육
    - Adaptive Path
    - Jesse James Garrett, Ajax.
    - XMLHttpRequest object.
    - Microsoft Developer Network's XML Developer Center.
    - 자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현 (developerWorks, September 2005)
    - 자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화 (developerWorks, October 2005)
    - Using Ajax with PHP and Sajax (developerWorks, October 2005)
    - Call SOAP Web services with AJAX, Part 1: Build the Web services client (developerWorks, October 2005)
    - XML Matters: Beyond the DOM (developerWorks, May 2005)
    - Build apps with Asynchronous JavaScript with XML, or AJAX (developerWorks, November 2005)
    - Ajax for Java developers: Ajax with Direct Web Remoting (developerWorks, November 2005)
    - surveys AJAX/JavaScript libraries.
    - XUL Planet's object reference section details XMLHttpRequest
    - strategy white paper
    - Flickr.com.
    - GMail
    - Head Rush Ajax (O'Reilly Media, Inc., February 2006)
    - JavaScript: The Definitive Guide, 4th Edition (O'Reilly Media, Inc., November 2001)
    - developerWorks Web Architecture zone

    토론
    -포럼에 참여하기.
    -Ajax.NET Professional
    -developerWorks blogs.

     

    사용자 삽입 이미지



    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3052


     

    대부분의 웹 애플리케이션들은 서버에서 전체 HTML 페이지를 얻는 요청/응답 모델을 사용합니다. 다시 말해서, 이 모델은 버튼을 클릭하고, 서버를 기다리고, 또 다른 버튼을 클릭하고, 다시 기다리는 일이 다반사입니다. Ajax와 XMLHttpRequest 객체를 사용하면 서버 응답을 기다리지 않아도 되는 요청/응답 모델을 사용할 수 있습니다.

     

    지난 글(참고자료)에서는 Ajax 애플리케이션에 관한 서론 및 이 애플리케이션에 필요한 몇 가지 기본개념에 대해 알아봤다. 본 글에서는 JavaScript, HTML 및 XHTML, 동적 HTML, 심지어는 몇 가지 DOM(동적 객체 모델) 등 이미 알고 있는 수많은 기술에 대해 중점적으로 다뤘다.

    본 글에서는 모든 Ajax관련 객체 및 프로그래밍 방식의 기초인 XMLHttpRequest 객체에 대해 먼저 다룰 것이다. 이 객체는 모든 Ajax 애플리케이션 전반에 걸쳐 유일한 공통 줄기가 된다. 예상하다시피, XMLHttpRequest 객체를 완전히 이해해서 프로그래밍의 한계에 다다르고자 할 것이다. 사실, XMLHttpRequest 객체를 적절히 이용해도 분명 그 객체를 사용하지 못하는 경우가 있다. 도대체 XMLHttpRequest 객체는 무엇일까?

     

     

    Web 2.0

     

    먼저 코드에 관해 자세히 알아보기 전에 Web 2.0에 관한 개요를 살펴 보면서 확실한 개념을 얻도록 하자. Web 2.0이라는 용어를 들을 때 다음과 같이 " Web 1.0은 무엇입니까?" 라고 물어봐야 한다. Web 1.0에 대해선 거의 들어보지 못했지만 명료한 요청 및 응답 모델이 포함된 전통 웹을 가리켜 Web 1.0이라 한다. 예를 들어 Amazon.com으로 들어가서 버튼을 클릭하거나 탐색 용어를 입력하면 서버에 요청을 생성하고 이에 대한 응답이 브라우저로 다시 보낸다. 그 요청은 책, 타이틀 목록 이상으로 중요하며 실지로 또 다른 완전 HTML 페이지를 만들어낸다. 그 결과 새로운 HTML 페이지가 웹 브라우저 스크린에 다시 나타날 때 플래시/플리커링 현상이 나타나기도 한다. 사실, 각각의 새로운 페이지에서 나오는 요청, 응답을 분명히 알게 된다.

    Web 2.0은 이와 같은 왕복이동 움직임이 상당부분 필요 없다. 예를 들어, Google Maps 또는 Flickr(참고자료)를 방문하면 Google Maps 상에서는 맵을 끌어다가 재 드로잉을 약간만 해도 맵이 축소, 확대된다. 물론, 요청 및 응답은 상상을 초월할 정도로 계속 이루어진다. 이로 인해 사용자로서의 경험은 훨씬 짜릿하며 데스크톱 애플리케이션 상에 있는 것과 같이 느껴진다. 이런 새로운 느낌, 패러다임은 누군가가 Web 2.0에 대해 언급할 때 나오는 현상들이다.

    이와 같이 새로운 상호작용이 가능하도록 하는 방법에 대해 주의를 기울여야 한다. 분명 요청 및 필드 응답을 생성하지만 이로 인해 매 순간 요청/응답 상호작용에 관한 HTML 재 드로잉이 발생돼 느리고 볼품없는 웹 인터페이스를 생성하게 된다. 따라서 사용자가 요청을 생성하고 전반적인 HTML 페이지보다는 필요한 데이터만 포함하는 응답을 수신하는 방식이 필요하다. 사용자가 새로운 페이지를 보고자 할 때가 완전히 새로운 HTML을 얻는 유일한 경우다.

    하지만 대부분의 상호작용으로 인해 상세사항 추가/본문 텍스트 변환/기존 페이지에 데이터 겹쳐쓰기 등이 발생한다. 모든 경우, Ajax 및 Web 2.0방식으로 전체 HTML 페이지를 업데이트하지 않고 데이터를 전송, 수신한다. 이런 기능으로 임의의 수많은 웹 서퍼들은 애플리케이션의 속도가 빨라지고 응답성이 증가하는 것으로 느끼게 되며 상호작용이 반복적으로 이루어지게 된다.

     

     

    XMLHttpRequest

     

    이렇게 새롭고 놀라운 현상이 실지로 발생하기 위해선 XMLHttpRequest라 하는 JavaScript 객체에 관해 완전 익숙해져야 한다. 오랜 시간 동안 몇몇 브라우저에서 사용된 이 객체는 Web 2.0, Ajax 및 앞으로 이 글에서 배우게 될 기타 사항을 이해하는 데 있어 중요한 역할을 하게 된다. 실지로 빠른 이해를 위해 이 객체에서 사용되는 방법 및 속성에 대해 알아보자.

  • open(): 새로운 요청을 서버에 설정함.
  • send(): 요청을 서버에 전송함.
  • abort(): 현 요청에서 벗어남.
  • readyState: 현 HTML 준비상태를 제공함.
  • responseText: 요청에 응답하기 위해 서버에서 재전송하는 텍스트.

    위의 모든 명령을 다 이해하지 못하더라도(중요한 것을 이해하지 못한다 하더라도) 걱정하지 마라. 다음 글에서 각 명령에 대한 방법 및 속성에 관해 배우게 된다. 여기서는 XMLHttpRequest와 관련된 좋은 아이디어를 얻는 게 필요하다.여기서, 각 방법 및 속성은 요청 전송 및 응답 처리와 연관된다는 것을 명심하라. 사실, XMLHttpRequest 객체에 관한 방법, 속성을 다는 알지 못하기 때문에 이들이 매우 간단한 요청/응답 모델과 연관 있다는 것도 모르게 된다. 그래서 놀랍고도 새로운 GUI 객체, 또는 사용자 상호작용을 생성하는 흥미로운 몇 가지 방식 등에 관해서도 배우지 않는다. 별로 재미가 없는 것 같지만 XMLHttpRequest 객체 하나만 잘 사용해도 완전 애플리케이션을 변경할 수 있다.

     

     

    단순함

     

    우선, 새로운 변수를 생성한 다음 이를 XMLHttpRequest객체 인스턴스에 할당한다. JavaScript 상에서는 상당히 간단한 작업이다. 여기서 Listing 1에 보다시피, 객체 이름과 같이 new 키워드를 사용하면 된다.

     

    Listing 1. 새로운 XMLHttpRequest 객체 형성

    <script language="javascript" type="text/javascript">
    var request = new XMLHttpRequest();
    </script>

     

    새로운 객체 형성과정이 그다지 어려운 일은 아니지 않는가? JavaScript에서는 변수 상에 입력하는 과정이 필요 없어 Listing 2(자바에서 XMLHttpRequest 객체를 생성하는 과정)와 같이 값을 전혀 입력할 필요가 없다.

     

    Listing 2. XMLHttpRequest 객체를 생성하기 위한 자바 유사-코드

    XMLHttpRequest request = new XMLHttpRequest();

     

    따라서 JavaScript에서 var로 변수를 생성해 변수에 명칭("request" 등)을 부여한 다음 이를 XMLHttpRequest 객체의 새로운 인스턴스에 할당한다. 이 시점에서 XMLHttpRequest 객체를 사용할 준비가 된 것이다.

     

     

    에러 처리과정

     

    실제 세계에서, 에러가 발생할 수 있어 에러 발생코드는 에러 처리기능을 제공하지 않는다. 따라서 XMLHttpRequest를 생성한 다음 에러가 발생한 경우 이 객체의 기능을 점차 저하시킨다. 일례로, XMLHttpRequest객체를 지원하지 않는 구 브라우저들(믿건 말건, 사람들은 Netscape Navigator의 구 버전을 여전히 이용한다.)이 많아 사용자는 어디서 에러가 났는지 알 필요가 있다. Listing 3은 에러가 난 경우 XMLHttpRequest 객체를 생성하는 방식에 대해 나와 있다. 여기서 XMLHttpRequest 객체로 JavaScript 경고가 발생한다.

     

    Listing 3. 에러 처리기능으로 XMLHttpRequest 객체 생성

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (failed) {
    request = false;
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    </script>

     

    여기서 다음의 각 단계를 반드시 이해한다.

    1.request라는 새 변수를 생성한 다음 이를 거짓으로 설정한다. XMLHttpRequest 객체가 아직 생성되지 않은 상태에서 거짓 값으로 설정한다.
    2. try/catch 블록에서 추가로 다음과 같은 작업을 한다.

    1. XMLHttpRequest 객체를 시험한 다음 생성한다.
    2. 1번 과정이 실패한 경우(catch (failed)), request가 여전히 거짓으로 설정되어 있는지 확인한다.

    3. request가 여전히 거짓으로 설정되어 있는지 확인한다. (에러가 없는 경우, 거짓으로 설정되지 않는다.)
    4. 에러가 발생한 경우(request가 거짓인 경우), JavaScript 경고를 사용해 문제가 발생했다는 사실을 사용자에게 알린다.

    이런 작업은 상당히 간단하다. 실제로 대부분의 JavaScript 및 웹 개발자들은 객체를 읽고 작성하는 것보다는 이해하는 게 더 빠르다. 이제, XMLHttpRequest 객체를 생성하는 일부 에러-증명 코드가 생성되어 에러 여부를 알게 된다.

     

     

    Microsoft로 처리하기

     

    적어도 인터넷 상에서 이 코드를 적용하기 전까지는 이와 같은 작업이 무난하다. 이 코드를 적용하면 그림 1과 같이 에러가 나오게 된다.

    사용자 삽입 이미지


    그림1. 에러화면

    분명, 에러가 발생하고 있다. Internet Explorer는 구식 브라우저가 아니며, 전 세계의 70% 정도가 사용하는 툴이다. 즉, Microsoft 및 Internet Explorer를 지원하지 않는 한 웹 상에서 잘 운영하지 못하게 된다. 따라서 Microsoft 브라우저를 다룰 다른 방식이 필요하다.

    Microsoft는 Ajax를 지원하지만 이전과 다른 XMLHttpRequest 버전을 호출하며 사실은 여러 다른 버전을 호출한다. Internet Explorer의 새로운 버전을 사용하는 경우, Msxml2.XMLHTTP 라 하는 객체를 사용해야 한다. Internet Explorer의 구 버전에서는 Microsoft.XMLHTTP 객체를 사용한다. 그러므로 이와 같은 두 가지 객체 형태를 지원해야 한다. (비-Microsoft 브라우저에 대한 지원기능을 손실하지 않은 상태에서.) 이미 언급한 코드에 Microsoft 지원기능을 추가한 Listing 4를 참조하라.

     

    Microsoft가 잘 작동되는가?
    Ajax에 관해 쓴 글이 많고 Microsoft는 이 영역에 있어 점점 더 관심을 기울이고 있다. 사실 2006년 말에 출시될 것으로 예정된 Microsoft사의 Internet Explorer 최신버전인 버전 7.0은 XMLHttpRequest 객체를 직접 지원해 모든 Msxml2.XMLHTTP 생성코드 대신 new 키워드를 사용한다. 하지만 너무 빠져 들지 마라. 아직도 구 브라우저를 지원해야 하므로 크로스-브라우저 코드는 곧장 사라지지는 않을 전망이다.

     

    Listing 4. Microsoft 브라우저에 지원기능 추가

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    </script>

     

    사실 브라우저에 대한 지원기능이 손실되기 쉽다. 따라서 다음과 같이 단계별로 하길 권한다.

    1. request 명의 새 변수를 생성한 다음 이를 거짓으로 설정한다. XMLHttpRequest 객체가 아직 생성되지 않았다는 전제 하에 거짓으로 설정한다.
    2. try/catch 블록에서 추가로 다음과 같은 작업을 한다.

    1. XMLHttpRequest 객체를 시험한 다음 생성한다.
    2. 1번 과정이 실패한 경우 (catch (trymicrosoft)):
      1. 새로운 Microsoft 버전 (Msxml2.XMLHTTP)을 이용해 Microsoft 호환성 객체를 시험한 다음 생성한다.
      2. 전 과정이 실패한 경우(catch (othermicrosoft)), 이전 Microsoft 버전(Microsoft.XMLHTTP)을 이용해 Microsoft 호환성 객체를 시험한 다음 생성한다.
    3. 그래도 실패한 경우(catch (failed))에는, request가 여전히 거짓으로 설정되어 있는지 확인한다.

    3. request가 여전히 거짓으로 설정되어 있는지 다시 확인한다. (에러가 나지 않는 경우 거짓으로 설정되지 않는다.)
    4. 그래도 문제가 발생한 경우(request가 거짓인 경우), JavaScript 경고를 사용해 사용자에게 문제가 발생했다는 것을 알린다.

    코드를 변화시키고 Internet Explorer 상에서 다시 한 번 시도해 보면 에러 메시지 없이 생성한 형태를 보게 된다. 본인의 경우엔 그와 같은 시도가 그림 2와 같은 것으로 나타난다

    사용자 삽입 이미지


    그림 2. 정상적으로 작동하는 Internet Explorer

     

     

    동적/정적

     

    Listing 1, 3, 4를 다시 보면 모든 코드는 script 태그 내에 직접 포함되어 있다는 것을 알게 된다. JavaScript가 그와 같이 코드화되고 메소드/기능 본체 내에 들어가지 않은 경우, 이를 정적 JavaScript라 한다. 이는 페이지가 스크린 상에 나타나기 전 코드를 실행했다는 것을 의미한다.(코드 및 브라우저가 따로 실행될 경우, 사양과는 100% 일치하지 않지만 사용자와 페이지가 상호작용하기 전, 코드를 실행했다는 건 확실하다.) 일반적으로 그렇게 해서 대부분의 Ajax 프로그래머가 XMLHttpRequest 객체를 생성한다.

    즉, Listing 5처럼, 메소드에 이와 같은 코드를 첨가한다.

     

    Listing 5. XMLHttpRequest 생성코드를 메소드로 이동하기

    <script language="javascript" type="text/javascript">

    var request;

    function createRequest() {
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    }
    </script>

     

    이와 같이 코드를 설정하면, Ajax 작업을 하기 전 이와 같은 메소드를 호출해야 한다. 그럴 경우 Listing 6과 같은 것을 얻을 수도 있다.

     

    Listing 6. XMLHttpRequest 생성 메소드 사용

    <script language="javascript" type="text/javascript">

    var request;

    function createRequest() {
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    }

    function getCustomerInfo() {
    createRequest();
    // Do something with the request variable
    }
    </script>

     

    Listing 6을 활용하면 에러 통지기능을 지연시키므로 대부분의 Ajax 프로그래머들은 위의 방법을 활용하지 않는다. 10/15 필드가 있는 복잡한 형태에 선택상자 등등이 있다고 상상해 보면 사용자가 필드 14에 있는 텍스트를 형식에 나온 대로 기입할 때 몇 가지 Ajax 코드를 전송한다. 이 시점에서 getCustomerInfo()를 실행해 XMLHttpRequest 객체를 생성하려 했지만 실패한다. (이 예에서) 그러면 사용자에게 이 애플리케이션을 사용할 수 없다는 것을 경고로 알리게 된다 (많은 경우). 하지만 사용자는 이미 형식 상에서 데이터를 기입하느라 시간을 보냈다. 상당히 짜증을 내게 되면서 사용자는 결국엔 사이트로 관심을 기울이지 않게 된다.

    정적 JavaScript를 사용하는 경우, 사용자는 페이지에 에러가 나자마자 에러를 포착하게 된다. 또 짜증나는가? 아마도 사용자로선 웹 애플리케이션이 브라우저 상에서 작동되지 않을 때 상당히 죽을 맛일 게다. 하지만, 10분 동안 정보를 기입한 뒤 동일한 에러가 나오는 것보다는 확실히 낫다. 따라서 정적으로 코드를 설정하고 난 다음 발생할 수 있는 문제에 대해 사용자가 조기에 알도록 하는 게 중요하다고 본다.

     

     

    XMLHttpRequest로 요청 전송하기

     

    요청 객체가 있으면 요청/응답 사이클을 시작한다. 여기서 요청을 생성한 다음 응답을 수신하는 게 XMLHttpRequest 객체에서 이루고자 하는 유일한 것임을 명심하라. 사용자 인터페이스 변환, 이미지 교환 및 서버에서 재전송하는 데이터 해석 등의 작업은 페이지에 있는 JavaScript, CSS 또는 기타 코드에서 일어나는 현상이다. XMLHttpRequest 객체가 사용 대기 중일 때 서버에 요청을 생성하게 된다.

     

     

    샌드박스

     

    Ajax는 샌드박스 보안 모델이 포함되어 있다. 그 결과 Ajax 코드(특히 XMLHttpRequest 객체)는 실행 중인 동일한 도메인에만 요청을 생성한다. 다음 글에서 보안 및 Ajax에 관해 더 많은 것을 배우게 되겠지만 지금으로선 로컬 머신 상에서 작동하는 코드만으로도 로컬 머신 상의 서버측 스크립트에 요청을 생성한다는 것을 알게 된다. www.breakneckpizza.com상에서 Ajax 코드를 실행하는 경우, www.breakneckpizza.com상에서 실행하는 스크립트에 관한 요청을 생성한다.

     

     

    서버 URL 설정

     

    여기서 우선 결정할 것은 연결할 서버의 URL이다. URL은 Ajax에서만 있는 것은 아니다. 분명URL을 구성하는 방법에 대해 알아야 한다. 하지만 URL은 연결 설정 시 여전히 필수적인 것이다. 대부분의 애플리케이션에서 사용자가 다루는 형식에서 나온 데이터와 정적 데이터 세트를 결합해 URL을 구성한다. 예를 들어 Listing 7에서는 전화번호 필드의 값을 알아내고 그 데이터를 이용해 URL을 구성하는 JavaScript에 관해 나와 있다.

     

    Listing 7. 요청 URL 구축

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    }
    </script>

     

    여기서 딴지를 걸만한 게 없다. 먼저 여기 나온 코드는 phone 이라는 이름의 새로운 변수를 생성, 이를 "phone"의 ID로 형식 필드 값을 지정한다. Listing 8에는 phone 필드 및 id 속성에서 알 수 있는 특수 형태에 관한 XHTML에 관해 나와 있다.

     

    Listing 8. Break Neck Pizza 형식

    <body>
    <p><img src="breakneck-logo_4c.gif" alt="Break Neck Pizza" /></p>
    <form action="POST">
    <p>Enter your phone number:
    <input type="text" size="14" name="phone" id="phone"
    onChange="getCustomerInfo();" />
    </p>
    <p>Your order will be delivered to:</p>
    <div id="address"></div>
    <p>Type your order in here:</p>
    <p><textarea name="order" rows="6" cols="50" id="order"></textarea></p>
    <p><input type="submit" value="Order Pizza" id="submit" /></p>
    </form>
    </body>

     

    사용자가 전화번호를 입력/변경하는 경우, Listing 8에서 보는 대로 getCustomerInfo() 메소드가 나온다는 사실을 알아둔다. 이 방법으로 전화번호를 알아낸 다음 url 변수에 저장된 URL 문자열을 구성하는 데 활용한다. Ajax 코드는 묶여져 있고 동일한 도메인에만 연결되기 때문에 URL에서 도메인 명칭이 필요 없다는 사실을 명심해야 한다. 이 예에서 스크립트 명칭은 /cgi-local/lookupCustomer.php다. 결국 전화 번호는 상기 스트립트에 Get 매개변수로서 추가된다. ("phone=" + escape(phone))

    이전에 escape() 메소드를 알지 못한 경우, 이 메소드는 정확히 명백한 텍스트로 전송될 수 없는 문자로부터 벗어나는 데 사용된다. 예를 들어, 전화번호에서의 임의의 공간은 %20 문자로 바뀌며 이로 인해 URL과 같이 문자를 전송할 수 있게 된다.

    그런 다음 필요한 많은 매개변수를 추가한다. 예를 들어 또 다른 매개변수를 추가하고자 한다면 URL 상에 추가해 여러 매개변수를 ampersand(&) 문자로 분리시킨다. (첫 번째 매개변수는 의문부호(?)로 스크립트 명칭으로부터 분리되어 있다.)

     

     

    요청 열기

     

    URL이 연결된 상태에서 XMLHttpRequest 객체 상의 open() 메소드를 사용해 요청을 구성한다. 이 메소드는 5가지 매개변수가 있다.

  • request-type: 전송 요청 형태. GET/POST가 일반적인 값이고 HEAD 요청도 전송함.
  • url: 연결된 URL.
  • asynch: 비동기 요청을 설정할 경우 참값, 동기식 요청인 경우에는 거짓임. 이 매개변수는 옵션이고 기본값이 참값임.
  • username: 사용인증을 요구할 경우 사용자이름을 지정한다. 옵션 매개변수고 기본값이 없다.
    password: 사용인증을 요구할 경우 암호를 지정한다, 옵션 매개변수고 기본값이 없다.

    일반적으로 5개의 매개변수 중 3개의 첫 매개변수만 사용한다. 사실, 비동기식 요청을 원할 경우, 제3의 매개변수로 "true"을 설정한다. 그게 기본값 설정이다. 하지만 훌륭한 자체 문서화 작업으로 이 작업을 통해 항상 요청이 비동기식인지 아닌지 여부를 알 수 있다.

    기본값 설정을 완료한 다음 일반적으로 Listing 9와 비슷한 라인으로 작업을 완료한다.

     

    open() 메소드가 열릴까?
    인터넷 개발자들은 open() 메소드의 정확한 기능에 대해 서로 의견이 다르다. 실제로 이 메소드에 없는 기능은 요청 열기 기능이다. 네트워크 및 XHYML/Ajax 페이지와 연결 스크립트 간 데이터 이동을 감시했더라면 open() 메소드 호출 시 트래픽 현상이 발생하지도 않았을 것이다. Open() 명칭이 선택된 이유는 여전히 불분명하지만 분명 훌륭한 명칭선택이라 볼 수는 없다.

     

    Listing 9. 요청 열기

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    }

     

    일단 URL을 이해했으면 그 다음에는 상당히 단순하다. 대부분의 요청의 경우, GET을 사용하는 것만으로도 충분하다. (다음 글에서 POST를 사용하고자 하는 경우를 보게 된다.) URL과 같이 open() 메소드를 사용하기만 하면 된다.

     

     

    비동시성에 대한 문제

     

    이 시리즈의 후반부에서는 비동기식 코드 작성 및 사용에 관한 설명에 할애할 것이다. 하지만 open() 메소드에서 마지막 매개변수가 중요한 이유에 대해 알아야 한다. 정상 요청/응답 모델에서 Web 1.0,을 생각해 보면 클라이언트(로컬 머신 상에서 실행하는 브라우저/코드)는 서버에 요청을 생성한다. 그 요청은 동기식이다. 다시 말하면 클라이언트는 서버로부터의 응답이 올 때까지 대기한다. 클라이언트가 대기 중일 때 일반적으로 적어도 대기 중인 여러 통지 형태 중 하나만 얻으면 된다.

  • Hourglass (Windows 경우에만).
  • 회전 비치볼(일반적으로 Mac 머신에서의 경우임).
  • 애플리케이션은 기본적으로 정지되고 때로 커서가 변환되기도 한다.

    이런 특성으로 웹 애플리케이션은 볼품없거나 느린 것으로 보여진다. 즉 실제 대화성이 부족한 것이다. 버튼을 누르면 트리거된 요청이 응답되기 전까지는 애플리케이션을 사용할 수 없다. 광범위한 서버 처리작업을 요구하는 요청을 생성할 경우 대기시간은 어마어마할 것이다. (적어도 오늘날 멀티 프로세서, DSL, 비대기 세계의 경우처럼.)

    하지만 비동기식 요청은 서버가 응답할 때까지 대기하지 않는다. 요청을 전송한 다음에는 애플리케이션을 계속 실행한다. 사용자는 웹 형식에서 데이터를 기입한 다음 기타 버튼을 클릭하고 형식 기입을 종료한다. 회전하는 비치볼, 소용돌이치는 hourglass 및 대형 애플리케이션 정지 등의 현상이 생기지 않는다. 서버는 재빨리 요청에 응답하고 서버가 종료된 경우, 요청으로 인해 원 요청자는 서버가 종료되었음을 알게 된다. 결국 볼품없고 느린 대신 민감하고 대화성 있고 빠른 애플리케이션을 얻게 된다. 정확한 GUI 구성요소 및 웹 디자인 패러다임만 가지고는 느리고 동기적인 요청/응답 모델의 한계를 극복할 수 없다.

     

     

    요청 전송

     

    일단 open() 메소드로 요청을 구성하고 나면 요청 전송 준비를 한다. 다행히도, 요청을 전송하는 메소드를 open()의 경우에 비해 더 적절하게 명명한다. 명칭은 단순히 send()이다.

    send() 메소드는 단 하나의 매개변수인 전송 컨텐트만 있으면 된다. 그 메소드에 대해 너무 깊게 생각하기 이전에 이미 URL 자체를 통해 데이터를 전송했음을 기억하라.

     

    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);

     

    send() 메소드를 사용해 데이터를 전송하지만 URL자체를 통해서도 된다. 사실, GET 요청(일반 Ajax 이용률의 80%를 이루고 있음.)에서는 URL에서 데이터를 전송하는 게 더 용이하다. 안전한 정보/XML을 전송하기 시작한 경우, send() 메소드를 통한 전송 컨텐트에 대해 알아보려고 할 것이다. (이 시리즈 후반부에 안전한 데이터 및 XML 메시징에 대해 논의한다.) send()를 통해 데이터를 전송하지 않아도 되는 경우, 이 메소드에 대한 인수로 null을 전송하면 된다. 따라서 이 글을 통해 알게 된 예에서 보듯 요청 전송작업을 하는 게 필요하다.(Listing 10)

     

    Listing 10. 요청 전송

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.send(null);
    }

     

     

    콜백 메소드 지정

     

    이 시점에서, 새롭고 혁신적이거나 비동기적이라고 생각될 만한 작업을 거의 하지 못했다. open() 메소드의 키워드 "true"는 비동기식 요청을 설정한다고 하는 게 정확하다. 하지만 그거 말고도 open() 메소드 코드는 Java servlets및 JSP, PHP/Perl이 함께 어우러진 프로그래밍과 유사하다. 그렇다면 Ajax 및 Web 2.0에 담긴 커다란 비밀은 무엇일까? 그 비밀은 onreadystatechange라는 명칭의 XMLHttpRequest의 단순한 속성에서 나오게 된다.

    먼저, open() 코드에서 생성된 과정에 대해 확실히 이해한다.(Listing 10) 요청을 설정하고 생성한다. 게다가 이 XMLHttpRequest는 동기식 요청이라 자바 메소드(예에 나온 getCustomerInfo())는 서버 상에서 대기하지 않는다. open() 코드는 계속 진행되고 이 경우 자바 메소드는 정지되며 제어기능은 형태로 나오게 된다. 사용자들은 계속 정보를 입력하고 애플리케이션은 서버 상에서 대기하지 않는다.

    이렇게 되면 재미있는 질문이 나오게 된다. 서버가 요청 처리 과정을 완료할 시 발생하는 현상은 어떤 것인가? 적어도 코드가 지금 당장 유지되는 한은 아무 현상도 없다 라는 말이 정답이다. 분명 좋은 현상은 아니다. 따라서 서버에 XXMLHttpRequest객체에 의해 전송된 요청에 관한 처리과정을 완료할 경우 서버는 몇 가지 형태의 명령어를 포함해야 한다

    이런 상황에서 바로 onreadystatechange 속성이 작용한다. 이 속성으로 콜백 메소드를 지정한다. 콜백 메소드로 서버는 웹 페이지 코드로 다시 호출한다. 그러면서 서버에 어느 정도의 제어 기능이 전달된다. 또한 서버에서 요청을 종료할 때 콜백 메소드는 XMLHttpRequest 객체, 특히 onreadystatechange 속성에서 나타난다. 그 속성에서 지정된 방법이 어떤 메소드든 모두 호출된다. 웹 페이지 자체에서 벌어지는 현상에 관계없이 웹 페이지로 다시 호출할 때 서버에서 개시하기 때문에 콜백이라 부르는 것이다. 예를 들어, 사용자가 의자에 앉아 키보드를 사용하지 않는 동안 콜백 메소드를 호출하기도 한다. 하지만 사용자가 입력하고 마우스를 움직이고, 화면 이동시키고 버튼을 클릭하는 동안에도 콜백 메소드를 호출하기도 한다. 사용자가 하는 업무는 그다지 중요하지 않다.

    이런 상황에서 비동시성이 작용한다. 사용자는 다른 레벨에 있는 동안 한 레벨에 있는 형식을 작동하고 서버는 요청에 응답한 다음 onreadystatechange 속성에서 명시된 콜백 메소드를 전송한다. 따라서 Listing 11에 나온 대로 코드에 콜백 메소드를 지정해야 한다.

     

    JavaScript에서의 기능 참조
    JavaScript는 약결합 언어며 이 언어에서 모두 다 변수로 참조 가능하다. updatePage()라는 이름의 함수를 선언한 경우, JavaScript는 그 함수 이름을 변수로 취급한다. 즉 updatePage()라는 이름의 변수로 코드에 있는 함수를 참조한다.

     

    Listing 11. 콜백 메소드 설정

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

     

    특히 onreadystatechange 속성이 결정된 코드 위치에 주의를 기울인다. 그 위치는 바로 send()가 호출되기 전의 위치다. 요청을 전송하기 전 onreadystatechange 속성을 설정해야 한다. 그래야만, 서버에서 요청 응답을 종료할 때 onreadystatechange 속성을 탐지하게 된다. 인제는 이 글의 마지막 부분에서 중점적으로 다룰 updatePage() 코드에 대해 알아보겠다.

     

     

    서버 응답 처리

     

    요청을 만들면 사용자는 웹 형식에서 여유롭게 작업하며 (서버에서 요청을 처리하는 동안에는) 서버는 요청 처리과정을 완료한다. 서버는 onreadystatechange 속성에서 나타나며 호출방법을 결정한다. 그런 일이 일어나면 비동기식/동기식 애플리케이션 등의 기타 다른 애플리케이션으로 애플리케이션을 생각할 수도 있다. 즉, 서버에 응답하는 특수 액션 작성 메소드를 취할 필요가 없다. 형식을 변환하고, 사용자를 또 다른 URL에 안내하거나 서버에 응답하는 데 필요한 것들을 하면 된다. 이 단락에서 우리는 서버 응답 및 이에 대한 일반조치 및 사용자가 아는 형식의 일부를 자유롭게 변경하는 것에 대해 중점적으로 다루겠다.

     

     

    콜백 및 Ajax

     

    이미 서버가 종료될 때의 현상을 서버가 인식하는 방법에 대해 이미 알았다. 일단 XMLHttpRequest 객체의 onreadystatechange 속성을 실행함수 이름에 설정한다. 그 다음 서버에서 요청을 처리하면 서버는 자동적으로 그 함수를 호출한다. 또한 콜백 메소드에 있는 임의의 매개변수에 대해 그리 걱정하지 않아도 된다. Listing 12와 같이 단순한 메소드에서 시작하기 때문이다.

     

    Listing 12. 콜백 메소드 코드화

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

    function updatePage() {
    alert("Server is done!");
    }
    </script>

     

    이렇게 하면 간단한 경고가 울리면서 서버가 종료될 때를 알려준다. 자체 페이지에 updatePage() 코드를 시험하고 페이지를 저장한 다음 브라우저에 페이지를 끌어올린다.(이 예에서 XHTML을 원할 경우, Listing 8을 참조한다.) 전화번호를 입력하고 필드를 설정하지 않을 경우 경고는 팝업되어야 한다. 하지만 확인을 클릭한 경우에도 경고는 팝업을 연속한다.

    사용자 삽입 이미지


    그림 3. 경고를 팝업하는 Ajax 코드

    브라우저에 ‘따라 웹 형식에서 경고 팝업을 중지할 때까지 경고가 두 번, 세 번, 심지어는 네 번까지 울린다. 그러면 무슨 일이 벌어지고 있는 것인가? 요청/응답 사이클의 중요 구성요소인 HTTP 준비상태에 대해 고려하지 않았다.

     

     

    HTTP 준비 상태

     

    초기에 필자는 서버에서 요청이 종료되면 XMLHttpRequest의 onreadystatechange 속성에서 호출되는 메소드를 탐지한다고 가르쳤다. 사실, HTTP 준비 상태가 변할 때마다 서버에서는 방금 전에 언급한 메소드를 호출한다. 그러면 그 말이 의미하는 것은 무엇인가? 일단 먼저 HTTP 준비상태에 관해 이해해야 한다.

    HTTP 준비상태는 요청의 상태를 나타내며 주로 요청을 시작했는지, 요청에 응답했는지, 요청/응답 모델을 완성했는지 여부를 결정하는 데 활용된다. HTTP 준비상태는 서버에서 공급되는 모든 응답 텍스트/데이터를 읽어 들이는 데 안전한지 여부를 결정하는 데 도움이 되기도 한다. 여기서 Ajax 애플리케이션에서의 5가지 준비상태에 관해 알아야 한다.

  • 0: 요청이 개시되지 않음.(open()을 호출하기 전)
  • 1: 요청을 설정했지만 전송되지는 않았음.(send()를 호출하기 전)
  • 2: 요청을 설정한 다음 처리 중(이 시점에서 일반적으로 응답에서 나온 컨텐트 헤더를 얻는다.)
  • 3: 요청 처리 중; 종종 응답에서 부분적인 데이터를 사용할 수 있다. 하지만 서버는 자체 응답이 완료되지 않았다.
  • 4: 응답 완료. 서버 응답을 얻은 다음 이를 활용한다.

    거의 모든 크로스-브라우저 이슈에서도 그렇듯 예상치 못한 방식으로 이와 같은 준비 상태를 이용한다. 준비상태는 항상 0~1, 2, 3, 4로 단계적으로 이동한다고 예상할지도 모른다. 하지만 실지로는 그렇지 않다. 0/1상태를 보고하지 않고 곧바로 2로 건너뛰어 3,4까지 가는 브라우저도 있고 모든 상태를 보고하는 브라우저도 있다. 지난 단락에서 보듯, 서버에서는 몇 번이고 updatePage()코드를 호출하고 호출 때마다 경고 상자가 팝업된다. 그건 여러분이 의도하는 바가 아닐 것이다!

    Ajax 프로그래밍의 경우, 직접 다뤄야 할 상태는 오로지 상태 4다. 이는 서버 응답이 완료되었고 응답 데이터를 점검, 사용하는 데 안전하다는 것을 의미한다. 이를 설명하기 위해 콜백 메소드에 나온 첫 번째 라인은 Listing 13에서 나온 바여야 한다.

     

    Listing 13. 준비상태 점검

    function updatePage() {
    if (request.readyState == 4)
    alert("Server is done!");
    }

     

    이런 변환으로 서버가 정말로 그 과정을 종료했는지 확인한다. Ajax 코드의 이 버전을 실행한다. 그러면 한 번에 경고 메시지만을 얻어야 한다.

     

     

    HTTP 상태 코드

     

    Listing 13에서의 코드의 성공에도 불구하고 여전히 문제는 상존한다. 그러면 서버가 요청에 응답하고 요청 처리과정을 완료했지만 에러를 보고한 경우는 어찌 되는가? Ajax, JSP, 정규 HTML 형식 또는 기타 형태의 코드로 서버측 코드를 호출 중인 경우에 서버측 코드를 관찰해야 한다는 점을 주목한다. 웹 세계에서는 HTTP 코드로 요청에서 발생할지도 모르는 여러 가지 상황을 다룬다.

    예를 들어, URL에 관한 요청을 입력했지만, URL을 부정확하게 입력해 404 에러코드가 나와 페이지가 없어졌다고 해보자. 이 코드는 HTTP 요청을 상태로 수신하는 여러 상태 코드 가운데 하나에 지나지 않는다.(참고자료) 403, 401 코드는 둘 다 안전하거나 금지된 데이터 처리를 의미하는 것으로 역시 공통적이다. 각 경우에 있어 이런 코드들은 완전 응답에서 나오는 코드들이다. 즉, 서버는 요청을 수행하지만(HTTP 준비상태는 4임), 클라이언트가 예상한 데이터가 나오지 않을 수도 있다.

    여기서 준비 상태에 덧붙여, HTTP 상태를 점검할 필요가 있다. 단순히 확인을 의미하는 상태코드 200을 탐색하는 중에 있다. 준비상태 4와 상태코드 200인 상태에서 서버 데이터를 처리할 준비가 되어 있고 그 데이터는 반드시 요청된 형태여야 한다. (에러 또는 문제가 있는 정보 단편이 아님.) Listing 14에서 보듯이 콜백 메소드에 또 다른 상태 점검기능을 추가한다.

     

    Listing 14. HTTP 상태 코드 점검

    function updatePage() {
    if (request.readyState == 4)
    if (request.status == 200)
    alert("Server is done!");
    }

     

    복잡성을 줄이고 더 강력한 에러 처리기능을 추가하려면 기타 상태코드에 관한 점검기능/두 가지 기능을 추가할지도 모른다. Listing 15에 있는 updatePage()의 수정 버전을 점검한다.

     

    Listing 15. 간단한 에러 점검기능 추가

    function updatePage() {
    if (request.readyState == 4)
    if (request.status == 200)
    alert("Server is done!");
    else if (request.status == 404)
    alert("Request URL does not exist");
    else
    alert("Error: status code is " + request.status);
    }

     

    이제 getCustomerInfo()에 있는 URL을 비실제 URL로 변환시킨 다음 일어나는 현상을 보면 요청한 URL은 존재하지 않는다는 의미의 경고가 울린다. 이런 경고 가지고도 모든 에러상태를 거의 처리하지 않는다. 하지만 웹 애플리케이션에서 발생할 수 있는 문제의 80%는 해결하는 단순한 진전이 아닐 수 없다.

     

     

    응답 텍스트 읽기

     

    인제 요청을 준비상태를 통해 완전히 처리하고, 서버로 정상적인 확인 응답을 상태 코드를 통해 받았으므로 서버에서 재전송되는 데이터를 최종적으로 처리한다. 이 데이터는 XMLHttpRequest객체의 responseText 속성에 저장된다.

    포맷/길이에 의한 responseText 속성의 텍스트 모양에 관한 상세사항은 이 장에서는 논하지 않기로 한다. 이렇게 되면 서버는 이 텍스트를 실지로 임의로 설정한다. 예를 들어, 한 스크립트로 콤마-분리 값 및 파이프-분리 값이 나오고 또 다른 파이프-분리 값은 텍스트의 긴 문자열로 나올 수도 있다. 이런 현상은 서버에 따라 다르게 된다.

    이 글에서 사용된 예의 경우, 서버는 파이프 기호로 분리된 고객의 마지막 순서 및 주소가 나오게 된다. 형식의 구성요소 값을 설정하는 데 순서 및 고객의 마지막 순서 및 주소를 활용한다. Listing 16은 디스플레이를 업데이트하는 코드에 대해 나와 있다.

     

    Listing 16. 서버 응답 처리

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "");
    } else
    alert("status is " + request.status);
    }
    }

     

    우선 JavaScript split() 메소드를 이용해 파이프 기호 상에서 responseText를 얻고 분할한다. 값은 response의 형태로 배열된다. 고객의 마지막 순서에 관한 첫 번째 값은 response[0] 형태의 배열로 처리되고 "순서" ID와 함께 필드 값으로 설정된다. response[1]에서 두 번째 값은 고객 주소로 처리하는 데 좀 더 오랜 시간이 걸린다. 주소 라인은 정상 라인 분리자("\n" 문자) 로 분리되기 때문에 코드는 정상라인 분리자를 XHTML-형 라인 분리자(< br />)로 바꾸어야 한다. 정규 식 및 replace() 함수의 활용을 통해 분리자를 바꾸는 과정이 이루어진다. 결국 변경 텍스트는 HTML 형태에서 div 의 내부 HTML로 설정된다. 결국 그림 4에도 나오듯이 텍스트 형식은 순식간에 고객정보로 업데이트된다.

    사용자 삽입 이미지


    그림 4. 고객 데이터 검색 후의 Break Neck 형식

     

    이 글을 마치기 전에 XMLHttpRequest 객체의 중요한 속성 중 하나인 responseXML 속성에 대해 언급한다. 이 속성은 서버가 XML과의 응답을 선택한 경우, XML 응답을 포함한다. (상상이 되는가?) XML 응답 처리는 평범한 텍스트 처리과정과 상당히 다르며, 문장분석 및 문서 객체 모델(DOM)을 포함한다. 다음 글에서는 XML에 대해 다루게 된다. responseXML 은 공통적으로 responseText과 관련된 논의에서 나오기 때문에 언급할 가치가 있는 것이다. 많은 단순 Ajax 애플리케이션의 경우, responseText만 있으면 된다. 하지만 Ajax 애플리케이션을 통해 XML을 처리하는 방법에 대해서도 곧 배우게 된다.

     

     

    맺음말

     

    XMLHttpRequest 객체에 대해서는 인제 좀 지루하게 들릴지도 모른다. 필자는 단일 객체, 특히 간단한 객체에 대한 전반적인 글을 거의 읽지 못했다. 하지만 Ajax를 사용하고 작성하는 각 페이지 및 애플리케이션에서 계속 XMLHttpRequest 객체를 사용하게 된다. 아직도 XMLHttpRequest 객체에 대해 언급되지 않은 것들이 많은 건 사실이다. 다음 글에서는 요청에서 GET 및 POST를 사용하고 서버로부터의 응답 및 요청의 컨텐트 헤더를 설정하고 읽어들이는 방법을 배운다. 그러면 요청을 코드화하고 심지어는 요청/응답 모델에서 XML을 다루는 방법을 배우게 될 것이다.

    좀 더 상세하게 나가면 일반적으로 사용하는 Ajax 툴킷에 관해서도 알게 된다. 이 툴킷은 본 글에서 논의된 상세사항의 대부분을 실지로 요약한 것이다. 한편 툴킷을 손쉽게 이용하는 경우, 낮은 레벨의 상세사항을 코드화하는 이유에 대해 궁금해할 수도 있다. 사실은 애플리케이션 상에서 발생하는 현상을 이해하지 못하는 경우, 애플리케이션에서 일어나는 에러를 이해하는 게 어려워진다.

    따라서, 이와 같은 사항을 간과하거나 지나치면 안 된다. 가변성 툴킷에서 에러가 발생할 경우, 머리를 끄적이면서 e-메일을 보내지 않아도 된다. 직접 XMLHttpRequest 사용법을 이해하면 가장 이상한 문제를 디버그하고 수정하는 것도 쉬워진다. 툴킷에 집중하면서 모든 문제를 해결하지 않는 한 툴킷은 그런대로 괜찮다.

    따라서, XMLHttpRequest 객체에 대해 친숙해져라. 사실, 툴킷을 사용하는 Ajax 코드를 실행할 경우 XMLHttpRequest 객체 및 속성, 메소드를 사용해Ajax 코드를 재작성한다. 상당히 좋은 연습이 될 것이며 현재 이 객체에서 벌어지는 현상에 대해 더 잘 이해하게 될 것이다.

    다음 글에서는 XMLHttpRequest에 대해 좀 더 자세하게 들어간다. 이 객체에서 어려운 속성(responseXML등의), POST 요청 사용법 및 몇 가지 다른 포맷에서의 데이터를 전송하는 방법을 조사할 것이다. 한 달 동안 코드화 작업을 시작해 코드를 다시 점검한다.

     

    참고자료

    교육
    - Ajax 마스터, Part 1: Ajax 소개 (developerWorks, December 2005)
    - 자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현 (developerWorks, September 2005)
    - 자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화 (developerWorks, October 2005)
    - Call SOAP Web services with Ajax (developerWorks, October 2005)
    - Google GMail
    - Flickr
    - Ajax: A New Approach to Web Applications
    - Why Ajax Matters Now
    - Microsoft Developer Network's XML Developer Center.
    - online documentation.
    - HTTP status codes
    - developerWorks Web Architecture zone

    제품 및 기술 얻기
    - Head Rush Ajax by Elisabeth Freeman, Eric Freeman, and Brett McLaughlin (February 2006, O'Reilly Media, Inc.)
    - Java and XML, Second Edition by Brett McLaughlin (August 2001, O'Reilly Media, Inc.)
    - JavaScript: The Definitive Guide by David Flanagan (November 2001, O'Reilly Media, Inc.)
    - Head First HTML with CSS & XHTML by Elizabeth and Eric Freeman (December 2005, O'Reilly Media, Inc.)

    토론
    -포럼에 참여하기.
    -developerWorks blogs.

     

     

    사용자 삽입 이미지



    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3054


     

    많은 웹 개발자들에게 간단한 요청을 만들고 간단한 응답을 받는 것은 사실 그들이 필요로 하는 전부이다. 하지만 Ajax를 마스터하고자 하는 개발자들에게는 HTTP 상태 코드, 준비 상태, XMLHttpRequest 객체에 대한 완벽한 이해가 필요하다. Brett McLaughlin은 다양한 상태 코드들을 보여주고 브라우저가 이들 각각을 핸들하는 방법을 설명한다. 비교적 덜 사용되는 HTTP 요청에 대해서도 설명한다.

     

    지난 글에서는 , XMLHttpRequest 객체에 대해 구체적으로 소개했다. 이것은 서버측 애플리케이션이나 스크립트에 대한 요청을 핸들하고, 서버측 컴포넌트에서 리턴 데이터를 처리하는 Ajax 애플리케이션의 주요 특징이다. 모든 Ajax 애플리케이션은 XMLHttpRequest 객체를 사용하기 때문에 Ajax 애플리케이션의 작동은 여기에 얼마나 익숙해지냐에 달려있다.

    이번에는 지난 글에서 다루었던 기초를 넘어서 요청 객체의 세 가지 핵심 부분들에 대해 자세히 설명하겠다.

  • HTTP 준비 상태
  • HTTP 상태 코드
  • 요청 유형들

    이들 각각은 요청이라는 배관의 일부로 간주된다. 결국, 작은 상세가 이러한 주제들에 대해 기록된다. 하지만 Ajax 프로그래밍을 염두하고 있다면 준비 상태, 상태 코드, 요청에 익숙해 져야 한다. 애플리케이션에서 무엇인가 잘못되고 있다면 준비 상태, HEAD 요청을 하는 방법, 또는 400 상태 코드가 의미하는 것이 무엇인지를 이해하면 5분의 디버깅으로 끝낼 수 있거나 5시간 동안 좌절과 혼돈 속에서 방황할 수 있다.

    HTTP 준비 상태 먼저 보도록 하자.

     

     

    HTTP 준비 상태

     

    지난 글에서 XMLHttpRequest 객체는 readyState 라는 속성을 갖고 있다고 설명했다. 이 속성은 서버가 요청을 완료하고 콜백 함수가 그 서버에서 온 데이터를 사용하여 웹 폼이나 페이지를 업데이트 하도록 한다. Listing 1은 이것에 대한 예제이다.(참고자료 참조)

     

    Listing 1. 콜백 함수에서 서버의 응답 처리하기

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "< br />");
    } else
    alert("status is " + request.status);
    }
    }

     

    XMLHttpRequest 또는 XMLHttp: 또 다른 이름의 장미
    Microsoft™와 Internet Explorer는 Mozilla, Opera, Safari, 비 Microsoft 계열 브라우저에서 사용되는 XMLHttpRequest 객체 대신 XMLHttp 라는 객체를 사용한다. 단순하게 하기 위해서 이 두 가지 객체 모두 XMLHttpRequest로 칭하기로 한다. 웹을 검색하다 보면 이런 경우가 비일비재 하고 마이크로소프트도 Internet Explorer 7.0의 요청 객체의 이름으로 XMLHttpRequest를 사용하고 있다. ("JavaScript와 Ajax를 이용한 비동기식 요청" 참조)

     

    이것은 전형적인 준비 상태의 사용법이다. "4"라는 숫자에서 짐작하듯 여러 가지 다른 준비 상태들이 있다.(참고자료 참조)

  • 0: (open()을 호출하기 전에는) 요청이 초기화 되지 않는다.
  • 1: (send()를 호출하기 전에는) 요청은 설정은 되지만 보내지지 않는다.
  • 2: 요청이 보내지고 처리 중에 있다. (이 시점에서 응답에서 콘텐트 헤더를 얻을 수 있다.)
  • 3: 요청이 처리 중에 있다. 부분적인 데이터를 응답에서 사용할 수 있지만 서버는 이 응답으로는 종료되지 않는다.
  • 4: 응답이 완료된다. 서버의 응답을 받고 이를 사용한다.

    Ajax 프로그래밍의 기초 이상으로 넘어가고 싶다면 이러한 상태 뿐만 아니라 이들이 언제 발생하고 어떻게 사용하는지에 대해 알아야 한다. 우선, 가장 중요한 것은 어떤 요청 상태가 될 것인지를 배워야 한다. 이는 별로 기분 좋은 일이 아니고 몇 가지 특별한 경우가 포함되어 있다.

     

     

    숨어있는 준비 상태

     

    readyState 0 (readyState == 0)으로 표시되는 첫 번째 준비 상태는 초기화 되지 않은 요청을 나타낸다. 요청 객체에 대해 open()을 호출하면 속성은 1로 설정된다. 대부분 요청을 초기화 하면서 open()을 호출하기 때문에 readyState == 0을 보는 일은 드물다. 더욱이 초기화 되지 않은 준비 상태는 실제 애플리케이션에서는 쓸모 없다.

    Listing 2를 보면 0으로 설정된 준비 상태가 되는 방법을 알 수 있다.

     

    Listing 2. 준비 상태 0

    function getSalesData() {
    // Create a request object
    createRequest();
    alert("Ready state is: " + request.readyState);

    // Setup (initialize) the request
    var url = "/boards/servlet/UpdateBoardSales";
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

     

    이 간단한 예제에서 getSalesData()는 웹 페이지가 요청을 시작하기 위해 호출하는 함수이다. (예를 들어, 버튼이 클릭 될 때.) open()이 호출되기 전에 준비 상태를 체크 해야 한다. 그림 1은 이 애플리케이션을 실행한 결과이다.

    사용자 삽입 이미지


    그림 1. 준비 상태 0

    분명히 이것은 좋지 않다. open()이 호출되지 않았다는 것을 확인해야 한다. 실제 Ajax 프로그래밍에서 이러한 준비 상태의 유일한 사용은 다중 함수들에 같은 XMLHttpRequest 객체를 사용하여 다중 요청을 만드는 경우이다. 그러한 상황에서, 여러분은 요청 객체가 새로운 요청을 만들기 전에 초기화 되지 않은 상태(readyState == 0)에 있다는 것을 확인해야 한다. 이로서 또 다른 함수가 동시에 객체를 사용하는 것을 방지할 수 있다.

     

     

    진행중인 요청의 준비 상태 보기

     

    0 준비 상태 외에 요청 객체는 전형적인 요청 응답에서 또 다른 준비 상태를 경험하게 된다. 그리고 마지막으로는 준비 상태 4로 끝난다. 이 때는 대부분의 콜백 함수에서 if (request.readyState == 4)가 된다. 서버가 완료되고 웹 페이지를 업데이트 하거나 서버에서 받은 데이터를 기반으로 액션을 취하는 시기이다.

    프로세스를 실제로 보는 것은 간단하다. 준비 상태가 4 라면 콜백에서 단순히 코드를 실행시키는 것 대신 콜백이 호출될 때 마다 준비 상태를 출력한다.(Listing 3)

     

    Listing 3. 준비 상태 점검

    function updatePage() {
    // Output the current ready state
    alert("updatePage() called with ready state of " + request.readyState);
    }

     

    0이 4와 같을 때
    다중 JavaScript 함수들이 같은 요청 객체를 사용하는 경우, 그 요청 객체가 사용되고 있지 않다는 것을 확인하기 위해 준비 상태 0을 확인하면 문제가 많아질 수 있다. readyState == 4는 완료된 요청을 나타내기 때문에, 4로 설정된 준비 상태인 채로 사용되지 않은 요청 객체를 종종 보게 된다. abort()이라고 하는 요청 객체를 리셋하는 함수가 있지만 이는 여기에 사용하는 것이 아니다. 다중 함수들을 사용해야 한다면 다중 함수에 객체를 공유하는 것 보다 각 함수용 요청 객체를 생성 및 사용하는 것이 낫다.

     

    이것이 어떻게 실행되는지 확실히 모르겠다면 웹 페이지에서 호출할 함수를 만들고 서버측 컴포넌트로 요청을 보내도록 한다.(Listing 2) 요청을 설정할 때 콜백 함수를 updatePage()로 설정한다. 요청 객체의 onreadystatechange 속성을 updatePage()로 설정한다.

    이 코드는 onreadystatechange가 정확히 무엇을 의미하는지 잘 보여주고 있다. 요청의 준비 상태가 변할 때 마다 updatePage()가 호출되고 경고를 받는다. 그림 2는 호출되는 함수의 샘플이다. 이 경우 준비 상태는 1이다.

    사용자 삽입 이미지


    그림 2. 준비 상태 1

    코드를 직접 실행해 보라. 웹 페이지에 넣고 이벤트 핸들러를 활성화 한다. (버튼을 누르거나, 요청을 실행하기 위해 설정하는 모든 메소드를 사용하라.) 콜백 함수는 여러 번 실행될 것이다. 요청의 준비 상태가 변할 때 마다 각 준비 상태에 대한 경고를 보게 된다. 이는 각 단계를 통해 요청을 따라가는 최상의 방법이다.

     

     

    브라우저 차이

     

    이 프로세스에 대해 기본적인 개념이 쌓였다면 여러 가지 다양한 브라우저에서 웹 페이지로 액세스 해보라. 준비 상태가 처리되는 방식에 차이가 있을 것이다. 예를 들어, Firefox 1.5에서, 준비 상태는 다음과 같다.

    • 1
    • 2
    • 3
    • 4

    요청의 각 단계들이 다 나타나기 때문에 놀랍지도 않다. 하지만 Safari를 사용하여 같은 애플리케이션에 액세스 하면 재미있는 것을 발견하게 된다. 다음은 Safari 2.0.1에서 보게 되는 상태이다.

    • 2
    • 3
    • 4

    Safari는 첫 번째 준비 상태를 배제하고 그 이유에 대해서는 자세히 나와있지 않다. 바로 이것이 Safari 방식이다. 또한 중요한 포인트이기도 하다. 서버에서 데이터를 사용하기 전에 요청의 준비 상태가 4라는 것을 확인하는 것은 좋은 생각인 반면 일시적인 준비 상태에 의존하는 코드를 작성하는 것은 다른 브라우저 마다 다른 결과를 얻을 수 있는 확실한 방법이다.

    예를 들어, Opera 8.5를 사용할 때 상황은 더 악화된다.

    • 3
    • 4

    Internet Explorer는 다음과 같은 상태로 반응한다.

    • 1
    • 2
    • 3
    • 4

    요청과 관련하여 문제가 있다면 문제의 원인을 찾을 수 있는 첫 번째 장소이다. 요청의 준비 상태를 보여주는 경고를 추가하여 상황이 정상적으로 돌아가는지를 확인할 수 있다. Internet Explorer와 Firefox 모두 테스트 하면 네 개의 모든 준비 상태를 얻을 수 있고 각 요청 단계를 검사할 수 있다.

    이제는 응답 쪽을 살펴보도록 하자.

     

     

    응답 데이터

     

    요청 동안에 다양한 준비 상태가 발생할 수 있다는 것을 이해했다면 XMLHttpRequest객체의 또 다른 중요한 부분에 대해 살펴보도록 하자. 바로 responseText 속성이다. 이것은 서버에서 데이터를 얻을 때 사용되는 속성이다. 서버가 요청 처리를 완료하면 그 요청에 응답하는데 필요한 데이터를 요청의 responseText에 둔다. 그런 다음 콜백 함수가 그 데이터를 사용한다.(Listing 1과 Listing 4 참조)

     

    Listing 4. 서버에서 응답 사용하기

    function updatePage() {
    if (request.readyState == 4) {
    var newTotal = request.responseText;
    var totalSoldEl = document.getElementById("total-sold");
    var netProfitEl = document.getElementById("net-profit");
    replaceText(totalSoldEl, newTotal);

    /* Figure out the new net profit */
    var boardCostEl = document.getElementById("board-cost");
    var boardCost = getText(boardCostEl);
    var manCostEl = document.getElementById("man-cost");
    var manCost = getText(manCostEl);
    var profitPerBoard = boardCost - manCost;
    var netProfit = profitPerBoard * newTotal;

    /* Update the net profit on the sales form */
    netProfit = Math.round(netProfit * 100) / 100;
    replaceText(netProfitEl, netProfit);
    }

     

    Listing 1은 매우 간단하다. Listing 4는 좀 더 복잡하다. 시작하려면 준비 상태를 검사하고 responseText 속성에서 값을 얻어야 한다

     

     

    요청하는 동안 응답 텍스트 보기

     

    준비 상태와 마찬가지로 responseText 속성의 값은 요청의 수명 주기에 걸쳐 변화한다. Listing 5의 코드를 사용하여 요청의 응답 텍스트를 테스트한다. 준비 상태도 마찬가지로 테스트 한다.

     

    Listing 5. responseText 속성 테스트 하기

    function updatePage() {
    // Output the current ready state
    alert("updatePage() called with ready state of " + request.readyState +
    " and a response text of '" + request.responseText + "'");
    }

     

    브라우저에서 웹 애플리케이션을 열고 요청을 활성화 한다. 이 코드를 최대한 활용하려면 Firefox나 Internet Explorer를 사용한다. 이 두 개의 브라우저는 요청 동안 모든 준비 상태들을 보고하기 때문이다. 준비 상태 2에서 responseText 속성은 정의되지 않는다.(그림 3) JavaScript 콘솔이 열려있었다면 에러가 생겼을 것이다.

    사용자 삽입 이미지


    그림 3. 준비 상태 2의 응답 텍스트

    준비 상태 3에서, 서버는 responseText 속성에 값을 배치한다.(그림 4)

    사용자 삽입 이미지


    그림 4. 준비 상태 3의 응답 텍스트

    준비 상태 3의 응답은 스크립트 마다, 서버 마다, 브라우저 마다 다르다. 애플리케이션을 디버깅 하는데 매우 유용하다.

     

     

    안전한 데이터 얻기

     

    모든 문서와 스팩들에서는 준비 상태가 4가 되어야지만 데이터를 안전하게 사용할 수 있다고 나와있다. 나를 믿으라. 준비 상태가 3일 때에도 responseText 속성에서 데이터를 얻을 수 있다. 하지만 여러분의 애플리케이션에서 이것에 의존하는 것은 좋지 않은 생각이다. 준비 상태 3에서 완전한 데이터에 의존하는 코드를 작성하는 것은 데이터가 불완전하다는 증거이다.

    준비 상태가 3일 때 사용자에게 피드백을 제공하는 것이 좋은 생각이다. alert() 같은 함수를 사용하는 것은 좋지 않다. Ajax를 사용하고 사용자와 경고 다이얼로그 박스를 차단시키는 것은 좋지 않지만 준비 상태가 변할 때 마다 폼이나 페이지에 대한 필드를 업데이트 할 수 있다. 예를 들어, 프로그레스 인디케이터의 넓이를 준비 상태 1에 25 퍼센트, 준비 상태 2에 50 퍼센트, 준비 상태 3에 75 퍼센트, 준비 상태 4에 100 퍼센트를 설정한다.

    물론 알다시피, 이 방식은 좋기는 하지만, 브라우저에 의존적이다. Opera에서는 첫 번째 두 개의 준비 상태를 결코 얻지 못하고 Safari는 처음 1 상태를 누락시킨다.

    이제 상태 코드에 대해 알아보자.

     

     

    HTTP 상태 코드

     

    Ajax 프로그래밍 기술에서 준비 상태와 서버의 응답 외에도, Ajax 애플리케이션에 또 다른 고급 레벨을 추가할 수 있다. 바로 HTTP 상태 코드이다. 이 코드들은 Ajax에서는 새우울 것이 없다. 웹에 있는 한 언제나 존재하는 것들이다. 웹 브라우저를 통해 이들을 보았을 것이다.

    • 401: Unauthorized
    • 403: Forbidden
    • 404: Not Found

    이 외에도 더 있다.(참고자료) Ajax 애플리케이션에 또 다른 제어 및 응답 레이어를 추가하려면 요청과 반응에 상태 코드를 검사해야 한다.

     

    200: Everything is OK

    많은 Ajax 애플리케이션에서 준비 상태를 점검하고 서버 응답으로 온 데이터로 작업하는 콜백 함수를 볼 수 있다.(Listing 6)

     

    Listing 6. 상태 코드를 무시하는 콜백 함수

    function updatePage() {
    if (request.readyState == 4) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "
    ");
    }
    }

     

    이것은 근시안적이고 에러를 많이 만드는 Ajax 프로그래밍 방식이다. 스크립트가 인증을 필요로 하는데 요청이 유효 증명을 제공하지 않으면 서버는 403 또는 401 같은 에러를 리턴한다. 하지만 서버가 요청에 응답하기 때문에 준비 상태는 4로 설정될 것이다. 결과적으로 사용자는 유효 데이터를 얻지 못하고 JavaScript가 존재하지 않는 서버 데이터를 사용하려고 할 때 에러를 얻게 된다.

    서버가 요청을 완료하고 "Everything is OK" 상태 코드를 리턴했다는 것을 확인하는 것은 간단한 일이다. 이 코드는 "200"이고 XMLHttpRequest 객체의 status 속성을 통해서 보고된다. 서버가 요청으로 끝나고 OK 상태를 리포트 했다는 것을 확인하려면 추가 체크를 콜백 함수에 추가한다.(Listing 7)

     

    Listing 7. 유효 상태 코드 추가

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "
    ");
    } else
    alert("status is " + request.status);
    }
    }

     

    코드에 몇 줄을 추가하는 것으로 무엇이 잘못되었는지를 알 수 있고 사용자는 아무런 설명이 없는 데이터 데신 유용한 에러 메시지들을 받을 수 있다.

     

     

    리다이렉션과 재 라우팅

     

    에러에 대해 이야기 하기 전에 Ajax를 사용할 때 걱정하지 않아도 될 부분에 대해 말해두겠다. 바로 리다이렉션이다. HTTP 상태 코드에서, 이것은 300 대의 상태 코드이다.

  • 301: Moved permanently
  • 302: Found (요청이 또 다른 URL/URI로 리다이렉션 된다.)
  • 305: Use Proxy (요청은 프록시를 사용하여 요청 받은 리소스에 액세스 해야 한다.)

    Ajax 프로그래머가 리다이렉션에 대해 염려 할 필요가 없는 이유가 두 가지 있다.

  • Ajax 애플리케이션들은 특정 서버측 스크립트, 서블릿, 애플리케이션을 위해 작성된다. 그 컴포넌트를 없애거나 다른 곳으로 이동하기 위함이다. 리소스는 변경되었다는 것을 (이미 이동했기 때문에)알고, 요청에서 URL을 변경하고 이러한 종류의 결과를 절대 만나지 않게 된다.

  • 보다 관련성 있는 이유가 있다. Ajax 애플리케이션과 요청들은 샌드박스화 되어있다. Ajax 요청을 만드는 웹 페이지를 공급하는 도메인은 그러한 요청에 응답해야 하는 도메인이다. 따라서 ebay.com에서 공급 받은 웹 페이지는 Ajax 스타일의 요청을 amazon.com에서 실행되는 스크립트에 할 수 없다. ibm.com 상의 Ajax 애플리케이션은 netbeans.org에서 실행되는 서블릿으로 요청할 수 없다.

    결국, 요청은 보안 에러를 만들지 않고서는 또 따른 서버로 리다이렉션 될 수 없다. 그러한 경우에, 상태 코드를 전혀 얻을 수 없다. 디버그 콘솔에 JavaScript 에러를 갖게 된다. 따라서 많은 상태 코드에 대해 생각하는 동안 리다이렉션 코드 정도는 무시할 수 있는 것이다.

     

    엣지 케이스와 하드 케이스
    이 부분에서, 신참 프로그래머들은 이러한 혼란에 대해 궁금할 것이다. Ajax 요청의 5 퍼센트 정도는 2와 3 정도의 준비 상태와 403 같은 상태 코드로 작동해야 한다. (사실, 1 퍼센트 미만이다.) 이러한 케이스는 중요하고, 엣지 케이스(edge cases)라고 일컬어진다. 이상한 조건들이 부합되는 특수한 상황인 것이다. 일상적인 것은 아니지만 사용자를 곤란에 처하게 한다.

    일반적인 사용자들은 애플리케이션이 정확히 작동하는지 매번 잊지만 그렇지 않을 때는 분명히 기억한다. 엣지 케이스와 하드 케이스를 핸들 할 수 있다면 사이트 사용자들을 만족시킬 수 있을 것이다.

     

     

    에러

     

    일단, 상태 코드 200을 관리했고 300 계열의 상태 코드는 대충 무시하면 다양한 유형의 에러들을 나타내는 400 계열의 코드만 남게 된다. Listing 7을 보면 에러가 처리되는 동안 사용자에게 출력되는 매우 일반적인 에러 메시지라는 것을 알게 된다. 이것은 올바른 방향으로 가는 단계지만 사용자와 프로그래머에게는 매우 쓸모없는 메시지이다.

    우선 소실된 페이지에 대한 지원을 추가한다. 이는 제품 시스템에서는 실제로 발생하지는 않지만 스크립트를 이동시키는 테스트나 정확하지 않은 URL을 입력할 때 자주 일어나는 일이다. 404 에러를 보고하면 혼란스러워 하는 사용자와 프로그래머에게 더 많은 도움말을 제공할 것이다. 예를 들어, 서버 상의 스크립트가 제거되거나 Listing 7에서 그 코드를 사용하면 다음과 같은 에러가 생긴다.(그림 5)

    사용자 삽입 이미지


    그림 5. 일반적인 에러 핸들링

    사용자는 문제가 무엇인지 잘 모른다. 인증에 관련된 것인지, 소실된 스크립트 인지, 사용자 에러인지 알 수 없다. 몇 가지 간단한 코드 추가로 이 에러는 더욱 구체화 된다. Listing 8을 보면 소실된 스크립트와 인증 에러까지 구체적인 메시지와 함께 처리된다.

  •  

    Listing 8. 유효 상태 코드 점검

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "
    ");
    } else if (request.status == 404) {
    alert ("Requested URL is not found.");
    } else if (request.status == 403) {
    alert("Access denied.");

    } else
    alert("status is " + request.status);
    }
    }

     

    이는 오히려 더 간단하지만 추가 정보 까지 제공한다. 그림 6은 그림 5와 같은 에러를 보여주지만 이번에는 에러 핸들링 코드가 더 나은 그림을 제공하고 있다.

    사용자 삽입 이미지


    그림 6. 구체적인 에러 핸들링

    여러분의 애플리케이션에서 인증 때문에 오류가 발생했을 때 사용자 이름과 패스워드를 지우고 에러 메시지를 스크린에 추가하는 것을 고려할 수도 있다. 이와 비슷한 방식이 소실된 스크립트나 다른 400 유형의 에러들을 핸들하는데 사용될 수 있다. 여러분이 어떤 선택을 하든 서버에서 리턴 된 상태 코드를 핸들하는 것으로 시작한다.

     

     

    추가 요청 유형

     

    XMLHttpRequest 객체를 제어하고 싶다면 HEAD 요청을 레파토리에 추가하라. 이전 두 개의 기사에서 GET 요청을 하는 방법을 설명했다. 앞으로는 POST 요청을 사용하여 서버로 데이터를 보내는 것을 설명하도록 하겠다. 향상된 에러 핸들링과 정보 수집을 위해 HEAD 요청에 대해 배워야 한다.

     

     

    요청하기

     

    HEAD 요청은 실제로 매우 간단하다. 첫 번째 매개변수로서 "GET" 또는 "POST" 대신 "HEAD"로 open() 메소드를 호출한다.(Listing 9)

     

    Listing 9. HEAD 요청

    function getSalesData() {
    createRequest();
    var url = "/boards/servlet/UpdateBoardSales";
    request.open("HEAD", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

     

    이와 같이 HEAD 요청을 하면 서버는 GET이나 POST 요청 때 처럼 실제 응답을 리턴하지 않는다. 대신, 서버는 응답에 있는 콘텐트가 마지막으로 수정된 시간이 포함된 리소스의 헤더를 리턴한다. 게다가 몇 가지 재미있는 정보도 추가한다. 이들을 사용하여 서버가 리소스를 처리 및 리턴하기 전에 리소스에 대해 알 수 있다.

    이와 같은 요청으로 할 수 있는 가장 쉬운 일은 모든 응답 헤더들을 나누는 것이다. 이로서 HEAD 요청을 통해 무엇이 가능한지를 알 수 있다. Listing 10은 HEAD 요청에서 모든 응답 헤더를 출력하는 콜백 함수이다.

     

    Listing 10. HEAD 요청에서 모든 응답 헤더 프린트 하기

    function updatePage() {
    if (request.readyState == 4) {
    alert(request.getAllResponseHeaders());
    }
    }

     

    그림 7에서 서버에 HEAD 요청을 한 간단한 Ajax 애플리케이션에서 온 응답 헤더를 볼 수 있다.

    사용자 삽입 이미지


    그림 7. HEAD 요청에서 온 응답 헤더

    이러한 헤더들을 개별적으로 사용하여 Ajax 애플리케이션에서 추가 정보나 기능을 제공할 수 있다.

     

     

    URL 검사

     

    URL이 존재하지 않을 때 404 에러를 검사하는 방법을 이미 보았다. 이것이 일반적인 문제라면, 특정 스크립트나 서블릿이 잠시 동안 오프라인에 있었다면, GET 또는 POST 요청을 하기 전에 URL을 검사해 보는 것이 좋다. HEAD 요청을 하고 콜백 함수에서 404 에러를 검사한다. Listing 11은 샘플 콜백을 보여준다.

     

    Listing 11. URL이 존재하는지 여부 검사

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    alert("URL exists");
    } else if (request.status == 404) {
    alert("URL does not exist.");
    } else {
    alert("Status is: " + request.status);
    }
    }
    }

     

    솔직히 말하면 이것의 가치는 별로 없다. 서버는 요청에 응답해야 하고 응답을 분석하여 응답 헤더에 파퓰레이트 하기 때문에 여러분은 프로세싱 시간을 저축할 수 없다. 게다가 요청을 하고 HEAD 요청을 사용하여 URL이 존재하는지 보는 것에도 많은 시간이 걸린다. Listing 7에서 처럼 에러를 핸들링 하기 보다 GET이나 POST를 사용하여 요청하기 때문이다. 무엇을 사용할 수 있는지를 정확히 아는 데는 가끔 유용하다.

     

     

    유용한 HEAD 요청

     

    HEAD 요청이 유용한 한 가지 부분은 콘텐트 길이나 콘텐트 유형을 검사할 때이다. 요청을 처리하기 위해 많은 양의 데이터를 보낼 것인지, 서버가 HTML, 텍스트, XML 대신 바이너리 데이터를 리턴해야 할지를 결정할 수 있다. (이 세 가지 모두 바이너리 데이터 보다 JavaScript에서 처리하는 것이 더 쉽다.)

    이 경우, 적절한 헤더 이름을 사용하고 이를 XMLHttpRequest 객체의 getResponseHeader() 메소드로 보낸다. 따라서 응답의 길이를 알려면 request.getResponseHeader("Content-Length");를 호출한다. 콘텐트 유형을 알려면 request.getResponseHeader("Content-Type");를 사용한다.

    많은 애플리케이션에서 HEAD 요청을 하면 어떤 기능도 추가하지 않고 요청의 속도를 늦출 수 있다. (HEAD 요청을 실행하여 응답에 대한 데이터를 얻고 후속 GET 또는 POST 요청을 통해 응답을 실제로 받는다.) 하지만 스크립트나 서버측 컴포넌트에 대해 확실하지 않은 경우 HEAD 요청으로 기본적인 데이터를 받을 수 있다.

     

     

    결론

     

    Ajax와 웹 프로그래머에게 이 글은 다소 어려울 것이다. HEAD 요청을 하는 것의 가치는 무엇인가? JavaScript에서 리다이렉션 상태 코드를 핸들해야 하는 때는 언제인가? 이 모두 좋은 질문이다. 간단한 애플리케이션의 경우, 이 모든 것은 가치가 별로 없다.

    하지만 웹이 단순한 애플리케이션만 수용하는 것은 아니다. 사용자는 점점 고급화 되고 고객들도 강력한 에러 리포팅을 원한다. 관리자 역시 애플리케이션이 조금만 느려져도 해고를 당하게 된다.

    간단한 애플리케이션을 넘어 XMLHttpRequest에 대한 이해를 높여야 할 때이다.

  • 다양한 준비 상태를 이해하고 이들이 브라우저 마다 어떻게 다른지를 이해하면 애플리케이션을 빠르게 디버깅 할 수 있다. 준비 상태에 기반하여 창조적인 기능을 만들고 요청자의 상태에 대해 사용자와 고객에게 보고할 수 있다.

  • 상태 코드를 핸들했다면 스크립트 에러, 예기치 못한 응답들, 엣지 케이스들을 다룰 수 있다. 결국, 애플리케이션은 언제나 잘 작동될 것이다.

  • 여기에 더하여 HEAD 요청을 만들고, URL의 존재를 검사하고 파일이 언제 수정되었는지를 파악하고 사용자가 유효 페이지를 얻었는지를 확인할 수 있다면 언제나 최신의 정보와 강력한 기능으로 사용자들을 만족시킬 수 있을 것이다.

    이들은 모두 Ajax의 강점이지만 극히 일부분이다. Ajax를 사용하여 애플리케이션이 에러와 문제들을 부드럽게 해결할 수 있는 강력한 토대를 구현한다면 사용자는 여러분의 사이트를 방문할 것이다. 다음 글에서는 보다 더 재미있고 흥미 있는 주제들을 나누도록 하겠다.

     

    다운로드 하십시오

    설명 이름 크기 다운로드 방식
    Example code for this article wa-ajaxintro3_ajax-xhr_adv.zip 183 KB HTTP

     

     

    참고자료

    교육
    - "Ajax 마스터, Part 1: Ajax 소개" (developerWorks, December 2005)
    - "Ajax 마스터하기, Part 2: JavaScript와 Ajax를 이용한 비동기식 요청" (developerWorks, January 2006)
    - "자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현" (developerWorks, September 2005)
    - "자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화" (developerWorks, October 2005)
    - "Call SOAP Web services with Ajax, Part 1: Build the Web services client" (developerWorks, October 2005)
    - Google GMail, Google Maps
    - Flickr
    - "Ajax: A New Approach to Web Applications
    - HTTP status codes
    - Head Rush Ajax by Elisabeth Freeman, Eric Freeman, and Brett McLaughlin (February 2006, O'Reilly Media, Inc.)
    - Java and XML , Second Edition by Brett McLaughlin (August 2001, O'Reilly Media, Inc.)
    - JavaScript: The Definitive Guide by David Flanagan (November 2001, O'Reilly Media, Inc.)
    - Head First HTML with CSS & XHTML by Elizabeth and Eric Freeman (December 2005, O'Reilly Media, Inc.)
    - developerWorks Web architecture zone
    - developerWorks technical events and Webcasts

    제품 및 기술 얻기
    -IBM trial software

    토론
    -포럼에 참여하기.
    -developerWorks blogs.

     

     

    사용자 삽입 이미지



    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3055


     

     

    프로그래머(백엔드 애플리케이션)와 웹 프로그래머(주로 HTML, CSS, JavaScript를 작성)사이에는 오래 전부터 엄격한 구분이 있었습니다. 하지만 Document Object Model (DOM)이 그 틈을 메우면서 백 엔드에서는 XML과, 프론트 엔드에서는 HTML과의 작업이 가능해 졌습니다.

     

    많은 웹 프로그래머들과 마찬가지로 여러분도 HTML로 작업을 해봤을 것이다. HTML은 프로그래머들이 웹 페이지 상에서 작업할 때 사용한다. HTML은 애플리케이션이나 사이트를 마감하면서 수행하는 마지막 작업이고, 배치, 색상, 스타일 등을 끝까지 작업한다. 웹 페이지의 디자인과 공급과 관련한 프로세스를 명확히 파악할 필요가 있다.

    1. 누군가가(대개는 여러분이) 텍스트 에디터나 IDE에서 HTML을 만든다.
    2. 그런 다음, HTML을 Apache HTTPD 같은 웹 서버에 업로딩하고 이것을 인터넷이나 인트라넷에 퍼블리시 한다.
    3. 사용자는 Firefox 또는 Safari 같은 브라우저를 사용하여 웹 페이지에 요청한다.
    4. 사용자의 브라우저는 여러분의 웹 브라우저에 HTML용 요청을 만든다.
    5. 브라우저는 서버에서 받는 페이지를 그래픽 또는 테스트로 렌더링 한다. 사용자는 웹 페이지를 보고 활성화 한다.

    매우 기본적인 것처럼 보이지만 실상은 매우 흥미롭다. 사실, 엄청난 양의 “성분(stuff)”들이 있다. 이것은 주로 4 단계와 5 단계 사이에 발생하고 바로, 이 부분을 이 글에서 중점적으로 다룰 것이다. 대부분의 프로그래머들은 사용자의 브라우저가 이것을 디스플레이 하도록 요청 받으면 대부분의 프로그래머들은 자신들의 마크업에 어떤 일이 발생하는지 정확히 고려하지 않기 때문이다.

  • 브라우저가 단순히 HTML에 있는 텍스트를 읽고 디스플레이 하는가?
  • CSS가 외부 파일에 있을 경우, CSS는 어떤가?
  • 외부 파일에 있는 JavaScript는 어떤가?
  • 브라우저는 이러한 아이템들을 어떻게 핸들하며 이벤트 핸들러, 기능, 스타일들을 텍스트 마크업으로 어떻게 매핑하는가?

    이 모든 질문들에 대한 답은 Document Object Model이다. 이제 본격적으로 DOM을 논해보자.

     

     

    웹 프로그래머와 마크업

     

    프로그래머의 작업이 끝날 때 웹 브라우저가 시작된다. 다시 말해서, HTML 파일을 웹 서버 상의 디렉토리에 얹어 놓으면 보통 이것을 "완료된 것 "으로 정리해 놓고 절대로 다시는 생각하지 않는다! 깨끗하고, 구성이 잘된 페이지를 작성할 때도 이것은 너무 멋진 목표이다. 여러분의 마크업이 브라우저를 통해 다양한 버전의 CSS와 JavaScript로 디스플레이 하기를 원하는데 이것도 잘못은 아니다.

    문제는 이러한 접근 방식이 브라우저에서 실제로 무슨 일이 일어나는지에 대해 프로그래머가 알 수 있는 범위를 제한한다는 점이다. 더욱이 클라이언트 측 JavaScript를 사용하여 웹 페이지를 동적으로 업데이트, 변경, 재구현 할 수 있는 기능 까지 제한한다. 이러한 한계를 제거하고 더 나아가 웹 사이트에서 더 나은 인터랙션과 생산성을 도모할 수 있다.

     

     

    프로그래머가 하는 일

     

    웹 프로그래머로서 여러분은 텍스트 에디터와 IDE를 시작하고 HTML, CSS, 심지어 JavaScript를 입력하기 시작한다. 태그, 셀렉터, 애트리뷰트를 사이트가 올바르게 보일 수 있도록 하는 작은 태스크라고 생각하기 쉽다. 하지만 그러한 관점을 좀더 확장 할 필요가 있다. 여러분이 콘텐트를 구성하고 있다는 것을 깨달아야 한다. 걱정하지 말라. 마크업의 가치에 대해 일장 연설을 늘어놓으려는 것은 아니다. 웹 페이지의 진정한 가치를 깨닫는 방법 내지는 형이상학적인 무엇인가를 설명하려는 것도 아니다. 여러분이 이해해야 할 것은 웹 개발 시 여러분의 역할이 정확히 무엇인가를 이해해야 한다.

    페이지를 보이게 해야 하는 시점에 와서 여러분은 제안만 할 수 있을 뿐이다. 여러분이 CSS 스타일시트를 제공하면 사용자는 여러분의 스타일을 무시할 수 있다. 폰트 사이즈를 제공하면 사용자의 브라우저는 그러한 사이즈를 변경할 수 있고 모니터에 맞게 스케일링 할 수 있다. 폰트와 컬러도 사용자의 모니터에 맞게 선택할 수 있다. 페이지를 스타일링 할 때 최선을 다하는 것도 중요하지만 이는 웹 페이지에 큰 영향을 주지 못한다.

    여러분이 완벽히 제어하는 것은 웹 페이지의 구조이다. 여러분의 마크업은 변경할 수 없고 사용자는 이것을 망칠 수 없다. 브라우저는 웹 서버에서 이것을 가져와서 디스플레이 한다. (여러분의 구미 보다 사용자의 구미에 따라 스타일로) 하지만 이 페이지의 구성은-이 단어가 그 문단 내에 있든 다른 div에 있든-전적으로 여러분에 달려있다. 페이지를 실제로 변경할 때(이것은 대부분의 Ajax 애플리케이션들이 집중하는 것이다.) 이것은 여러분이 운영하는 페이지의 구조이다. 텍스트의 조각의 색상을 변경하는 것이 좋지만 텍스트나 전체 섹션을 기존 페이지에 추가하는 것이 훨씬 더 좋다. 사용자가 그 섹션을 어떻게 스타일링 하던지 간에 페이지 그 자체의 구성을 가지고 작업한다.

     

     

    마크업이 수행하는 일

     

    마크업이 구성에 관한 것이라는 것을 깨달으면 이것을 달리 볼 수 있다. h1이 텍스트를 크고, 검고, 두껍게 만든다고 생각하는 대신 h1을 헤딩으로서 생각하라. 사용자가 어떻게 보는가, 그리고 사용자가 여러분의 CSS를 사용하는 자신들의 것을 사용하든 두 개를 결합하여 사용하든 이것은 두 번째 문제이다. 대신 마크업은 이 정도의 구성을 제공하는 것이라는 것을 깨달아라. P는 텍스트가 단락(paragraph)이라는 것을 나타내고, img는 이미지를, div는 페이지를 섹션으로 나눈다.

    스타일과 작동(이벤트 핸들러와 JavaScript)가 fact 뒤에 이 구성에 적용된다는 것도 명확해 진다. 마크업은 적소에서 작동되거나 스타일링 되어야 한다. 따라서 HTML에 대한 외부 파일에 CSS를 갖는 것처럼 마크업의 구성도 스타일, 포맷팅, 작동과 분리된다. 엘리먼트의 스타일 또는 텍스트 조각을 JavaScript로부터 확실히 변화시킬 수 있고 마크업이 레이아웃 한 구성을 실제로 바꿀 수 있다는 것은 더 흥미 있는 사실이다.

    마크업이 페이지에 구성 또는 프레임웍만 제공한다는 것을 마음에 새긴다면 본격적인 게임에 돌입해보자. 브라우저가 모든 텍스트 구성을 가지고, 이를 변경, 추가, 삭제 가능한 객체로 바꾸는 방법을 보자.

     

     

    텍스트 마크업의 장점

     

    웹 브라우저를 논하기 전에 왜 플레인 텍스트가 HTML을 저장하기에 최상의 선택인지를 생각해 봐야 한다. (마크업에 대해 더 알아야 할 것들 참조) 찬반을 논하기 전에, 페이지가 보여질 때 마다 HTML이 네트워크를 통해 웹 브라우저로 보내진다는 것을 생각해 보라. (캐싱 같은 문제는 차후에 논하기로 한다.) 텍스트와 함께 전달하는 것 보다 효율적인 방법은 없다. 바이너리 객체, 그래픽으로 구현된 페이지, 재구성된 마크업 청크 등, 이 모든 것들은 플레인 텍스트 파일 보다 네트워크를 통해 전송할 때 더 어려운 것들이다.

    브라우저를 이러한 방정식에 대입해 보자. 오늘날의 브라우저에서는 사용자가 텍스트의 크기길 변경하고, 이미지를 스케일링 하고 CSS나 JavaScript를 다운로드 할 수 있다. 이 모든 것은 페이지의 온갖 종류의 그래픽 표현을 브라우저로 보내는 전조가 된다. 대신 브라우저는 미가공 HTML을 필요로 한다. 왜냐하면 이것은 태스크를 핸들하기 위해 서버를 믿기 보다 어떤 프로세싱이든 브라우저에 있는 페이지에 적용할 수 있기 때문이다. 같은 맥락에서, CSS와 JavaScript를 분리하고, 이들을 HTML 마크업에서 분리할 때에는 분리하기 쉬운 포맷이 필요하다.

    HTML 4.01, XHTML 1.0/ 1.1 같은 새로운 표준들이 콘텐트(페이지의 데이터)를 표현과 스타일(보통 CSS에 의해 적용됨)에서 분리하겠다는 약속을 기억하는가? 프로그래머들이 CSS에서 HTML을 분리하려면 브라우저를 실행하여 페이지에서 몇몇 구현들을 가져오고 그러한 표준의 많은 장점들을 없앤다. 브라우저에서 이렇게 다른 부분들을 계속 분리시키면 브라우저는 서버에서 HTML을 가져올 때 최상의 유연성을 보인다.

     

    마크업에 대해 더 알아야 할 것들

    플레인 텍스트 편집: 옳은가, 그른가?
    플레인 텍스트 파일은 마크업을 저장하는 데는 이상적이지만 그 마크 업을 편집하는 데는 그렇지 못하다. Macromedia DreamWeaver 또는 Microsoft ?? FrontPage ?? 같은 IDE를 사용하는 것이 바람직하다. 이러한 환경은 종종 웹 페이지를 구현할 때 도움이 되는 지름길과 도움말을 제공한다. 특히 CSS와 JavaScript를 사용할 때 그렇다. 많은 사람들은 여전히 Notepad나 vi를 선호한다. (고백하건데 나도 그 중 하나이다.) 이것 역시 좋은 선택이다. 두 경우 모두 마지막 결과는 마크업으로 가득 찬 텍스트 파일이다.

    네트워크를 통한 텍스트: 좋은 것
    이미 언급했듯이 텍스트는 HTML이나 CSS 같은 문서에 있어 훌륭한 미디어이다. 이것은 네트워크를 통해 수백, 수천 번 이동한다. 브라우저가 텍스트를 나타내는데 어려움을 겪는다면 텍스트를 시각적 페이지와 그래픽 페이지로 변환한다는 의미이다. 브라우저가 웹 서버에서 페이지를 실제로 가져오는 방법과는 관련이 없다. 이 경우 텍스트는 여전히 최상의 옵션이다.

     

     

    웹 브라우저 분석

     

    지금까지 여러분이 읽은 모든 것은 웹 개발 프로세스에서의 여러분의 역할에 대한 리뷰에 불과하다. 하지만 웹 브라우저가 무엇을 수행하는지를 논해야 하는 시점에서 유능한 많은 웹 디자이너와 개발자들은 보이지 않는 곳에서 실제로 어떤 일이 발생하는지 종종 깨닫지 못한다. 이 섹션에서는 바로 그 부분을 설명하도록 하겠다. 걱정하지 말라. 코드도 함께 등장할 것이다. 잠시 코딩하고 싶은 조바심을 접어두라. 웹 브라우저가 정확히 어떤 일을 수행하는지를 이해하는 것이 정확한 코딩 작업의 필수이기 때문이다.

     

     

    텍스트 마크업의 단점

     

    텍스트 마크업이 디자이너나 페이지 생성자에게 엄청난 이득을 주듯이 브라우저에는 비교적 큰 단점을 갖고 있다. 특히 브라우저는 텍스트 마크업을 사용자에게 시각적으로 직접 나타내기가 매우 힘들다. (마크업에 대해 더 알아야 할 것들 참조) 다음과 같은 브라우저 태스크를 생각해 보라.

  • CSS 스타일?외부 파일에 있는 다중 스타일시트?을 HTML 문서의 엘리먼트 유형, 클래스, 아이디, 위치에 기반하여 마크업에 적용한다.
  • JavaScript 코드에 기반한 스타일과 포맷팅?외부 파일에도 있음?을 HTML 문서의 다른 부분들에 적용한다.
  • JavaScript 코드에 기반하여 폼 필드의 값을 변경한다.
  • JavaScript 코드에 기반하여 이미지 롤오버와 이미지 스와핑 같은 시각 효과를 지원한다. 복잡함은 이러한 태스크들을 코딩 하는데 있는 것이 아니다. 이러한 일들을 하기는 정말 쉽다. 복잡함은 브라우저가 실제로 요청된 액션을 수행하는 데서 온다. 마크업이 텍스트로 저장되면 center-text 클래스에서 텍스트를 센터링 해야 한다. (text-align: center) 이것을 어떻게 할 것인가?

  • 텍스트에 인라인 스타일링을 추가하는가?
  • 브라우저의 HTML 텍스트에 스타일링을 적용하고 어떤 것이 센터링 되는지, 어떤 것이 센터링 되지 않는지를 지켜보는가?
  • 스타일링 되지 않은 HTML을 적용한 다음 팩트 다음에 포맷을 적용하는가?
    이 같은 매우 어려운 질문들 때문에 몇몇 사람들이 오늘날 브라우저를 코딩을 한다.

    확실히, 플레인 텍스트는 브라우저를 위해 HTML을 저장하는 최상의 방법은 아니다. 텍스트가 페이지의 마크업을 가져오는 좋은 솔루션이었지만 말이다. 이 외에도 JavaScript가 페이지의 구조를 변경하는 기능은 트릭이 조금 있다. 브라우저가 수정된 구조를 디스크에 재작성 해야 하는가? 문서의 현재 어떤 단계에 있는지를 어떻게 파악할 수 있는가?

    확실히 텍스트는 답이 못 된다. 수정하기도 어렵고, 스타일과 작동을 추가하기에는 불편하고, 궁극적으로 오늘날 웹 페이지의 동적인 특징과 거리가 멀다.

     

     

    트리 뷰로 이동하기

     

    이 문제에 대한 답, 오늘날의 웹 브라우저에 맞는 답은 트리 구조를 사용하여 HTML을 나타내는 것이다. 텍스트 마크업으로 구현된 단순하고 지루한 HTML 페이지 대신 Listing 1을 보자.

     

    Listing 1. 텍스트 마크업의 간단한 HTML 페이지

    <html>
    <head>
    <title>Trees, trees, everywhere</title>
    </head>
    <body>
    <h1>Trees, trees, everywhere</h1>
    <p>Welcome to a <em>really</em> boring page.</p>
    <div>
    Come again soon.
    <img src="come-again.gif" />
    </div>
    </body>
    </html>

     

    그림 1. 이 브라우저는 이것을 트리 구조로 변환한다.

    사용자 삽입 이미지


    그림 1. Listing 1의 트리 뷰

    이 글을 위해 단순함을 유지했다. DOM과 XML 전문가는 공백이 문서에 있는 텍스트가 구현되고 웹 브라우저의 트리 구조에서 깨지는 방법에 영향을 줄 수 있다는 것을 알 것이다. 공백의 효과에 대해 알고 있다면 정말 대단하다. 그렇지 않다면 공부하면 된다. 걱정 말라. 이것이 문제가 될 때 필요한 것이 무엇인지를 깨닫게 될 것이다.

    실제 트리 백그라운드 외에 여기에서 알아야 할 첫 번째 것은 트리에 있는 모든 것이 가장 바깥쪽에서 시작되고 HTML의 엘리먼트(html)를 포함하고 있다는 것이다. 이는 트리 메타포에서 루트(root) 엘리먼트라고 불린다. 이것이 트리의 바닥에 있지만 트리를 분석할 때면 언제나 이것부터 시작한다. 완전히 거꾸로 뒤집어보면 도움이 될 것이다.

    루트에서부터 마크업의 다양한 조각들 간 관계를 보여주는 라인의 흐름을 따라가 보라. head와 body 엘리먼트는 html 루트 엘리먼트의 자식들이다. title은 head의 자식이고 "Trees, trees, everywhere" 텍스트는 title의 자식이다. 전체 트리는 브라우저가 그림 1과 비슷한 구조가 될 때까지 이와 같이 구성된다.

     

     

    몇 가지 추가 용어

     

    트리 메타포를 이해하기 위해서 head와 body 는 html의 브랜치(branch)라고도 일컬어진다. 이들은 자신들의 자식이 있기 때문에 브랜치이다. 트리의 말단에 다다르면 "Trees, trees, everywhere"와 "really" 같은 텍스트로 가게 된다. 이들은 자식들이 없기 때문에 잎(leave)으로 일컬어진다. 이 용어들을 다 기억할 필요는 없고 특정 용어가 무엇을 의미하는지를 파악하려면 나무의 구조를 머리속에 그려보면 된다.

     

     

    객체의 가치

     

    기본적인 용어들을 익혔으니 엘리먼트 이름과 텍스트가 들어있는 작은 직사각형에 집중해 보자.(그림 1) 각 직사각형들은 객체이다. 여기에서 브라우저는 텍스트와 관련된 문제들을 해결한다. 객체를 사용하여 HTML 문서의 조각들을 나타냄으로서 구성을 변경하고, 스타일을 적용하며, JavaScript를 문서에 액세스 시키기가 매우 쉬워진다.

     

     

    객체 유형과 속성

     

    모든 가능한 유형의 마크업은 고유의 객체 유형을 갖는다. 예를 들어, HTML에 있는 엘리먼트는 Element 객체 유형에 의해 구현된다. 문서에 있는 텍스트는 Text 유형에 의해 구현된다. 애트리뷰트는 Attribute 유형에 의해 표현된다.

    따라서 웹 브라우저는 객체 모델을 사용하여 문서를 표현하고?정적 텍스트를 다룰 필요가 없음?객체 유형에 따라 즉각 구분할 수 있다. HTML 문서는 파싱되고 그림 1의 객체들로 바뀐다. 그런 다음 대괄호 같은 이스케이프 시퀀스로 바뀐다. 이는 브라우저의 작업을 훨씬 쉽게 만든다. 적어도 인풋 HTML을 파싱한 후에도 말이다. 어떤 것이 엘리먼트이고 어떤 것이 애트리뷰트인지 파악하고 객체 유형을 어떻게 다룰지를 결정하는 작동은 간단하다.

    객체들을 사용함으로서 웹 브라우저는 그러한 객체들의 속성들을 변경할 수 있다. 예를 들어, 각 엘리먼트 객체는 하나의 부모와 자식 리스트를 갖고 있다. 새로운 자식 엘리먼트나 텍스트를 추가하는 것은 새로운 자식을 엘리먼트의 자식 리스트에 추가하는 문제에 지나지 않는다. 이러한 객체들은 또한 style 속성을 갖고 있어서 엘리먼트의 스타일이나 텍스트 조각을 쉽게 변경할 수 있다. 예를 들어, 다음과 같이 JavaScript를 사용하여 div의 높이를 수정할 수 있다.

     

    someDiv.style.height = "300px";

     

    다시 말해서, 웹 브라우저는 이와 같이 객체 속성들을 사용하여 트리의 모양과 구조를 쉽게 변경한다. 이것을 복잡한 것과 비교해 보라. 속성과 구조가 변할 때 마다 브라우저는 정적 파일을 재작성 하고, 재 파싱 하고 이를 스크린에 다시 디스플레이 해야 한다. 이 모든 것이 객체로도 가능해진다.

    이 시점에서 HTML 문서에 대해 알아보고 이를 트리로 그려보자. 평범한 요청은 아닌 것 같지만 이들을 다룰 수 있으려면 이러한 트리 구조에 익숙해져야 한다. 보통의 요청은 아닌 것 같지만 이 트리 구조에 익숙해져야 한다. 이들을 조작할 수 있으려면 말이다.

    이 프로세스에서 몇 가지 이상한 점들을 발견하게 된다. 다음과 같은 상황을 생각해 보자.

  • 애트리뷰트에는 어떤 일이 발생하는가?
  • em과 b 같은 엘리먼트로 나뉜 텍스트는 어떻게 되는가?
  • 정확하게 구축되지 않은 HTML은 어떻게 되는가? (닫기 p 태그가 소실 되는 경우) 일단 이러한 유형의 문제에 익숙해지면 다음 섹션을 이해하기가 더 쉬울 것이다.

     

     

    엄격함을 유지한다.

     

    내가 언급했던 것을 직접 해본다면 마크업의 트리 뷰에 잠재적 문제 몇 가지들을 발견할 것이다. (직접 하지 않을 것이라면 내 말을 믿어라.) 사실, Listing 1과 그림 1에서 여러 가지를 발견할 것이다. p 엘리먼트가 나뉘어지는 방법부터 시작해서 말이다. 전형적인 웹 개발자에게 p 엘리먼트의 텍스트 콘텐트가 무엇인지를 묻는다면 일반적으로 "Welcome to a really boring Web page"라고 답할 것이다. 이것을 그림 1과 비교하면 이러한 대답이 논리적이긴 하지만 전혀 맞지 않다는 것을 알게 될 것이다.

    p 엘리먼트는 세 개의 다른 자식 객체들을 갖고 있고, 이 중 어떤 것도 전체 "Welcome to a really boring Web page" 텍스트를 포함하고 있지 않다. "Welcome to a "와 " boring Web page" 같은 텍스트의 일부를 볼 수는 있어도 이것이 전체 문장은 아니다. 이를 이해하려면 마크업의 모든 것이 어떤 유형의 객체로 바뀌어야 한다는 것을 기억하라.

    더욱이 순서도 문제가 된다. 정확한 마크업이지만 여러분의 HTML에서 제공된 순서와 다르다면 사용자가 웹 브라우저에 어떻게 대응할지를 상상할 수 있겠는가? 문서를 구성했던 방식이 아닐 때에도 제목과 헤딩 사이에 끼게 될 것이다. 브라우저는 엘리먼트와 텍스트의 순서를 보존해야 한다.

    이 경우, p 엘리먼트는 세 개의 구별된 부분들을 갖는다.

    • em 엘리먼트 앞에 오는 텍스트
    • em 엘리먼트
    • em 엘리먼트 뒤에 오는 텍스트

    이 순서를 섞는다면 텍스트의 잘못된 부분에 강조를 적용한 것이다. 이 모든 것을 바로잡으려면 p 엘리먼트는 Listing 1의 HTML에 나타났던 순서 대로 세 개의 객체 자식들을 가져야 한다. 더욱이 강조된 텍스트인 "really"는 p의 자식 엘리먼트가 아니다. 이것은 p의 자식인 em의 자식이다.

    이 개념을 이해하는 것은 매우 중요하다. "really" 텍스트가 나머지 p 엘리먼트의 텍스트와 함께 디스플레이 되더라도 이것은 여전히 em 엘리먼트의 직접적인 자식이다. 이것은 나머지 p와는 다른 포맷팅을 가질 수 있고 나머지 텍스트와 개별적으로 움직일 수 있다.

    이를 유념하면서 Listing 2와 3의 HTML을 다이어그램으로 그리면서 텍스트에 정확한 부모를 유지하도록 한다. 정확한 부모로 유지시킨다.

     

    Listing 2. 약간의 트릭이 들어간 엘리먼트 중첩이 있는 마크업

    <html>
    <head>
    <title>This is a little tricky</title>
    </head>
    <body>
    <h1>Pay <u>close</u> attention, OK?</h1>
    <div>
    <p>This p really isn't <em>necessary</em>, but it makes the
    <span id="bold-text">structure <i>and</i> the organization</span>
    of the page easier to keep up with.</p>
    </div>
    </body>
    </html>

     

    Listing 3. 보다 트릭이 심한 엘리먼트의 중첩

    <html>
    <head>
    <title>Trickier nesting, still</title>
    </head>
    <body>
    <div id="main-body">
    <div id="contents">
    <table>
    <tr><th>Steps</th><th>Process</th></tr>
    <tr><td>1</td><td>Figure out the <em>root element</em>.</td></tr>
    <tr><td>2</td><td>Deal with the <span id="code">head</span> first,
    as it's usually easy.</td></tr>
    <tr><td>3</td><td>Work through the <span id="code">body</span>.
    Just <em>take your time</em>.</td></tr>
    </table>
    </div>
    <div id="closing">
    This link is <em>not</em> active, but if it were, the answers
    to this <a href="answers.html"><img src="exercise.gif" /></a> would
    be there. But <em>do the exercise anyway!</em>
    </div>
    </div>
    </body>
    </html>

     

    이러한 관행에 대한 해답은 이 글 끝부분의 GIF 파일인 (그림 2)와 (그림 3)에서 찾을 수 있다. 스스로 알아내기 전에 몰래 보지 않기를 바란다. 엄격한 규칙이 트리를 구성하는데 어떻게 적용되는지를 이해하면 도움이 될 것이다. HTML과 트리 구조를 마스터 한다면 정말로 도움이 될 것이다.

     

     

    애트리뷰트

     

    애트리뷰트를 어떻게 다루어야 하는지를 파악할 때 문제가 생긴 적이 있는가? 앞서 언급했지만 애트리뷰트는 고유의 객체 유형을 갖고 있지만 애트리뷰트는 엘리먼트의 자식이 아니다. 중첩 엘리먼트와 텍스트는 같은 레벨의 애트리뷰트가 아니고 Listing 2와 3에 대한 답에는 애트리뷰트가 나타나지 않는다는 것을 알 수 있다.

    사실 애트리뷰트는 브라우저가 사용하는 객체 모델에 저장되지만 이들은 특별한 경우이다. 각 엘리먼트는 여기에 사용되는 애트리뷰트 리스트를 갖고 있고 자식 객체의 리스트에서 분리된다. 따라서 div 엘리먼트는 "id" 애트리뷰트와 또 다른 이름 " class "를 포함하고 있는 리스트를 갖게 된다.

    엘리먼트용 애트리뷰트가 유일한 이름을 갖고 있어야 한다는 것을 기억하라. 다시 말해서, 하나의 엘리먼트가 두 개의 "id" 또는 두 개의 "class"애트리뷰트를 가질 수 없다. 보존하고 액세스 할 리스트를 매우 쉽게 만든다. 다음 글에서 보겠지만 getAttribute("id") 같은 메소드를 호출하여 애트리뷰트 값을 이름 별로 얻을 수 있다. 애트리뷰트를 추가하고 기존 애트리뷰트의 값을 비슷한 메소드 호출을 설정(재설정)할 수 있다.

    애트리뷰트의 독자성은 리스트를 자식 객체들의 리스트와 구별시킨다. p 엘리먼트는 그 안에 여러 em 엘리먼트를 갖고 있기 때문에 자식 객체의 리스트에는 중복 아이템이 포함될 수 있다. 자식 리스트와 애트리뷰트 리스트는 비슷하게 작동하지만 하나는 중복을 포함할 수 있고(객체의 자식) 하나는 그럴 수 없다는 것이다. (엘리먼트 객체의 애트리뷰트) 마지막으로 엘리먼트만이 애트리뷰트를 가질 수 있기 때문에 텍스트 객체는 여기에 첨부될 리스트가 없다.

     

     

    어지러운 HTML

     

    더 진행하기에 앞서 브라우저가 마크업을 트리 구현으로 변환하는 방법, 브라우저가 엉성한 폼의 마크업을 어떻게 다루는지를 볼 필요가 있다. 구성이 잘되었다(Well-formed)는 용어는 XML에서 광범위하게 사용되고 두 가지 기본적인 의미가 있다.

    모든 오프닝 태그는 여기에 매칭되는 클로징 태그를 갖고 있다. 따라서 모든 <p>는 </p>와 <div>는 </div>와 매칭된다.
    가장 안쪽의 오프닝 태그는 가장 안쪽의 클로징 태그와 매칭된다. 그 다음 안쪽의 오프닝 태그는 그 다음 안쪽의 클로징 태그와 매칭되는 식이다. 따라서 <b><i>bold and italics</b></i>는 옳지 않다. 가장 안쪽의 오프닝 태그인 <i>가 <b>와는 맞지 않기 때문이다. 이를 잘 구성하려면 오프닝 태그 순서를 바꾸거나 클로징 태그 순서를 바꾼다. (둘 다 바꾼다면 똑 같은 문제가 생긴다.)

    이 두 가지 규칙들을 자세히 연구해 보자. 두 규칙 모두 문서의 간단한 구성을 늘릴 뿐만 아니라 모호함을 제거한다. Bolding이 먼저 적용되고 그 다음에 italics를 적용해야 하는가? 아니면 그 반대인가? 순서와 다의성이 큰 문제인 것처럼 보이지만 CSS에서는 이 규칙들이 다른 규칙들을 무시할 수 있도록 한다. 따라서 b 엘리먼트 안에 있는 텍스트의 폰트가 i 엘리먼트 내의 폰트와 다르다면 포맷팅이 적용되는 순서는 매우 중요하다. 따라서 HTML 페이지의 좋은 구성이 중요한 것이다.

    잘 구성되지 않은 문서를 브라우저가 받는 경우 할 수 있는 최선을 다한다. 결과 트리 구조는 가장 좋은 경우는 원래 페이지 작성자가 의도했던 것과 비슷한 것이고 최악의 경우 완전히 다른 것이다. 브라우저에 페이지를 로딩하고 기대했던 것과 완전히 다른 일이 발생한다면 구조에 대해 다시 생각해 봐야 한다. 물론 픽스는 간단하다. 문서가 잘 구성되었는지를 확인하는 것이다. 표준화된 HTML을 작성하는 방법을 모르겠다면 참고자료를 참조하라.

     

     

    DOM

     

    지금 까지, 브라우저가 웹 페이지를 객체 구현으로 변환하는 것에 대해 배웠다. 아마도 여러분은 객체 구현이 DOM 트리라고 생각해왔을 것이다. DOM은 문서 객체 모델(Document Object Model)을 의미하고 World Wide Web Consortium (W3C)에서 사용할 수 있는 스팩이다.(참고자료 참조)

    DOM은 브라우저가 마크업을 나타낼 수 있도록 하는 객체의 유형과 속성들을 정의한다. (다음 글에서는 JavaScript와 Ajax 코드에서 DOM을 사용하는 방법을 설명하겠다.)

     

     

    문서 객체

     

    무엇보다도 객체 모델에 액세스 해야 한다. 이것은 매우 쉽다. 웹 페이지에서 실행되는 JavaScript 코드 조각에 있는 빌트인 document 변수를 사용하려면 다음과 같이 코드를 작성한다.

     

    var domTree = document;

     

    물론 이 코드는 그 자체로는 쓸모가 없지만 모든 웹 브라우저가 document 객체를 JavaScript 코드에 사용할 수 있도록 하고 객체는 완벽한 마크업 트리를 나타낸다.(그림 1)

     

     

    모든 것이 노드이다!

     

    확실히, document 객체는 중요하지만 단지 시작에 불과하다. 더 진행하기 전에 또 다른 용어인 노드(node) 개념을 익혀야 한다. 마크업의 각 부분이 객체에 의해 구현되지만 이는 하나의 객체(특정 유형의 객체)인 DOM 노드에 불과하다는 것을 이미 알 것이다. 보다 특별한 유형인 텍스트, 엘리먼트, 애트리뷰트는 이러한 기본적인 노드 유형에서 확장된다. 따라서 여러분은 텍스트 노드, 엘리먼트 노드, 애트리뷰트 노드를 갖고 있는 것이다.

    JavaScript로 프로그래밍을 했다면 DOM 코드를 사용하는 방법도 알 것이다. 이 Ajax 시리즈를 충실히 이행했다면 여러분도 DOM 코드를 사용한 것이다. 예를 들어, var number = document.getElementById("phone").value; 라인은 DOM을 사용하여 특정 엘리먼트를 찾아 그 엘리먼트의 값(이 경우 폼 필드)을 가져온다. 따라서 여러분이 인식 못했더라도 여러분은 document를 JavaScript 코드에 타이핑 할 때마다 DOM을 사용한 것이었다.

    여러분이 배웠던 용어를 정비하기 위해 DOM 트리는 객체의 트리지만 보다 구체적으로는 노드 객체들의 트리이다. Ajax 애플리케이션 또는 JavaScript에서 그러한 노드들과 작업하여 엘리먼트와 이것의 콘텐트를 지우고 특정 텍스트 조각을 강조하고 새로운 이미지 엘리먼트를 추가하는 등 특별한 효과를 만들 수 있다. 이 모든 것은 클라이언트 측(웹 브라우저에서 실행되는 코드)에서 발생하기 때문에 이러한 효과는 서버와 통신 없이 즉시 발생한다. 결국 보다 반응성 있는 애플리케이션이 될 것이다.

    대부분의 프로그래밍 언어에서 각 노드 유형에 맞는 실제 객체 이름들을 배우고 속성들을 배우고 유형과 캐스팅을 파악해야 한다. 하지만 이중 어떤 것도 JavaScript에서는 필요하지 않다. 변수를 만들어서 여기에 원하는 객체를 할당한다.

     

    var domTree = document;
    var phoneNumberElement = document.getElementById("phone");
    var phoneNumber = phoneNumberElement.value;

     

    변수를 만들고 여기에 정확한 유형을 핸들하는 유형과 JavaScript는 없다. 결과적으로 JavaScript에서 DOM을 사용하기가 매우 쉬워진다. (다음 글에서는 XML과 관련한 DOM에 초점을 맞춰 설명하겠다.)

     

     

    결론

     

    지금 여기에서 설명한 것이 DOM의 전부는 아니다. 사실 이 글은 DOM의 개요서에 지나지 않는다. 오늘 설명한 것 이상의 것이 DOM에는 있다.

    다음 글에서는 JavaScript에서 DOM을 사용하여 웹 페이지를 만들고 HTML을 수정하고 사용자 인터랙션을 높이는 방법을 설명하겠다. DOM을 주제로 다시 한면 설명하겠다. Ajax 애플리케이션의 중요한 부분인 DOM에 익숙해지기 바란다.

    바로 지금 DOM을 더 깊이 연구할 수 있다. DOM 트리로 옮기는 방법, 엘리먼트와 텍스트의 값을 얻는 방법, 노드 리스트를 통해 반복하는 방법 등을 자세히 설명하겠다.

    무엇보다도 트리 구조에 대해 생각해 보고 HTML을 통해서 웹 브라우저가 HTML을 마크업의 트리 뷰로 어떻게 전환하는지에 대해 생각해 보고 다음 글에 임하기 바란다. 또한, DOM 트리의 구성을 생각해 보고 이 글에 설명된 특별한 경우를 생각해 보라. 애트리뷰트, 그 안에 엘리먼트와 혼합된 텍스트, 텍스트 콘텐트를 갖고 있지 않은 엘리먼트(img 엘리먼트) 등을 생각해 보라.

    이러한 개념을 확실히 이해하고 JavaScript와 DOM의 신택스를 배운다면 도움이 될 것이다.

    여기 Listing 2와 2에 대한 답을 제시하겠다. 샘플 코드도 포함되어 있다.

    사용자 삽입 이미지


    그림 2. Listing 2에 대한 답



    사용자 삽입 이미지


    그림 3. Listing 3에 대한 답

     

     

    참고자료

    교육
    - developerWorks Ajax series :
       - "Ajax 마스터, Part 1: Ajax 소개" (December 2005).
       - "Ajax 마스터하기, Part 2: JavaScript와 Ajax를 이용한 비동기식 요청"(January 2006).
       - "Ajax 마스터하기, Part 3: Ajax의 고급 요청 및 응답" (February 2006).

    - DOM Home Page
    - DOM Level 3 Core Specification.
    - ECMAScript language bindings for DOM
    - "자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현"(developerWorks, September 2005).
    - "자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화" (developerWorks, October 2005).
    - "Call SOAP Web services with Ajax, Part 1: Build the Web services client:" (developerWorks, October 2005).
    - "Ajax: A New Approach to Web Applications:"
    - HTTP status codes.
    - Head Rush Ajax by Elisabeth Freeman, Eric Freeman, and Brett McLaughlin (February 2006, O'Reilly Media, Inc.)
    - Java and XML, Second Edition by Brett McLaughlin (August 2001, O'Reilly Media, Inc.)
    - JavaScript: The Definitive Guide by David Flanagan (November 2001, O'Reilly Media, Inc.)
    - Head First HTML with CSS & XHTML by Elizabeth and Eric Freeman (December 2005, O'Reilly Media, Inc.)
    - developerWorks Web architecture zone
    - developerWorks technical events and Webcasts

    제품 및 기술 얻기
    -IBM trial software

    토론
    -developerWorks blogs.

     

     

    사용자 삽입 이미지



    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3056


     

     

    지난 달에는 웹 페이지를 정의하는 문서 객체 모델을 소개했습니다. 이번 달에는 돔을 보다 자세히 연구합니다. 돔 트리의 부분들을 생성, 제거, 변경하는 방법을 설명하고 그 다음 단계인 웹 페이지를 업데이트 하는 방법을 설명합니다.

     

    지난 회에는 웹 브라우저가 웹 페이지들 중 하나를 디스플레이 할 때 어떤 일이 일어나는지에 대해 설명했다. 페이지에 정의했던 HTML과 CSS가 웹 브라우저로 보내지면 이것은 텍스트에서 객체 모델로 변환된다. 코드가 단순하건 복잡하건 간에, 하나의 파일에 저장하든 또는 개별 파일들에 모든 것을 저장하든 간에 이것은 사실이다. 브라우저는 제공된 텍스트 파일 보다는 객체 모델을 사용한다. 브라우저가 사용하는 모델을 문서 객체 모델(Document Object Model)이라고 한다. 이것은 문서에 있는 엘리먼트, 애트리뷰트, 텍스트를 나타내는 객체들을 연결한다. HTML과 CSS에 있는 모든 스타일, 값, 심지어 거의 모든 공간들은 객체 모델로 통합된다. 웹 페이지에 대한 특정 모델은 그 페이지의DOM 트리라고 한다.

    DOM 트리가 무엇인지를 이해하고 이것이 어떻게 HTML과 CSS를 나타내는지를 아는 것이 웹 페이지를 제어하는 첫 번째 단계이다. 그런 다음에는 특정 웹 페이지에 DOM 트리를 사용하여 작동시키는 방법을 배워야 한다. 예를 들어, 한 엘리먼트를 DOM 트리에 추가하면 그 엘리먼트는 페이지 리로딩 없이 사용자의 웹 브라우저에 즉시 나타난다. DOM 트리에서 몇몇 텍스트를 제거하면 그 텍스트는 사용자의 스크린에서 사라진다. 여러분은 DOM을 통해서 사용자 인터페이스를 변경할 수 있고 인터랙팅 할 수 있다. 이것은 실로 엄청난 프로그래밍의 힘과 유연성을 제공해 준다. 일단 DOM 트리로 작업하는 방법을 배우면 풍부하고 동적인 인터랙티브 웹 사이트를 마스터하는 단계로 넘어갈 수 있다.

    지난 회 "웹 응답에 DOM 활용하기"를 참조하라. 아직 읽어 보지 않았다면 이 글을 읽기 전에 일어보기 바란다.

     

     

     

    크로스 브라우저, 크로스 언어

     

    Document Object Model은 W3C 표준이다. (참고자료 참조) 따라서 모든 현대의 웹 브라우저는 DOM을 지원하고 있다. 브라우저 간 차이는 있겠지만 핵심 DOM 기능을 사용한다면-그리고 특별한 케이스와 예외에 주의를 기울이면- 여러분의 DOM 코드는 어떤 브라우저 상에서도 같은 방식으로 작동할 것이다. Opera의 웹 페이지를 수정하기 위해 여러분이 작성한 코드는 Apple의 Safari??, Firefox??, Microsoft?? Internet Explorer??, Mozilla?? 상에서도 실행될 것이다.

    DOM은 크로스 언어(cross-language) 스팩이기도 하다. 다시 말해서 대부분의 프로그래밍 언어에서 이것을 사용할 수 있다. W3C는 DOM을 위한 여러 언어 바인딩을 정의하고 있다. 언어 바인딩은 단순한 API로서 특정 언어에 DOM을 사용할 수 있도록 해준다. 예를 들어, C, Java, JavaScript용으로 정의가 잘 된 DOM 언어 바인딩을 찾아볼 수 있다. 따라서 여러분은 어떤 언어에서도 DOM을 사용할 수 있다. 언어 바인딩 역시 여러 다른 언어에도 사용할 수 있다. 비록 이 언어들이 W3C가 아닌 삼자에 의해 정의되더라도 말이다.

    이 시리즈에서 나는 JavaScript 바인딩에 초점을 맞출 것이다. 대부분의 비동기식 애플리케이션 개발이 JavaScript 코드를 작성하여 웹 브라우저에서 실행하기 때문이다. JavaScript와 DOM을 사용하여 사용자 인터페이스를 수정할 수 있고 사용자 이벤트와 인풋에 대응할 수 있다. 이 모두가 완전히 표준화된 JavaScript를 사용한다.

    다른 언어로 된 DOM 언어 바인딩도 검토해보기 바란다. 예를 들어, 자바 언어 바인딩을 사용하여 HTML 뿐만 아니라 XML로도 작업할 수 있다. 따라서 여기에서 배운 레슨을 HTML 외에도 적용할 수 있고 클라이언트 측 JavaScript 말고도 여러 환경에 적용할 수 있다.

     

    약어 문제
    Document Object Model은 그 동안 Document Node Model로 불려졌다. 물론 대부분의 사람들은 노드(node)라는 단어가 무엇을 의미하는지 모르고, "DNM"은 "DOM"만큼 발음하기 쉬운 것도 아니기 때문에 W3C에서도 DOM이라는 용어를 채택했다.

     

     

    개념상의 노드

     

    노드는 DOM에서 가장 기본적인 객체 유형이다. 사실, 이 글에서 밝혀지겠지만 DOM에 의해 정의된 거의 모든 객체는 노드 객체를 확장한다. 하지만 의미론으로 들어가기 전에 노드의 개념을 이해해야 한다. 그렇게 하면 실제 속성과 노드의 방식을 배우는 것은 식은 죽 먹기다.

    DOM 트리에서 여러분이 만나게 되는 거의 모든 것이 노드이다. 가장 기본적인 레벨에 있고, DOM 트리에 있는 노드이다. 모든 애트리뷰트는 하나의 노드이다. 모든 텍스트 조각도 하나의 노드이다. 심지어 코멘트, (카피라이트 상징을 나타내는 © 같은) 특별 문자도 모두 노드이다. 이러한 개별 유형들의 특성을 설명하기 전에, 여러분은 노드가 무엇인지를 이해해야 한다.

     

     

    노드란..

     

    간단히 말해서, 노드는 DOM 트리에 있는 그저 단순한 하나의 존재이다. "존재(thing)"라고 한 것은 다분히 의도적이다. 예를 들어, HTML에 있는 엘리먼트 img와 HTML의 텍스트 조각인 "Scroll down for more details"는 많은 공통점이 있다. 하지만 그러한 개별 유형의 기능에 대해 생각하기 때문에 이들이 어떻게 다른지에 초점을 맞추겠다.

    DOM 트리에 있는 각 엘리먼트와 텍스트 조각이 부모를 갖고 있다고 생각해 보자. 부모는 또 다른 엘리먼트의 자식일 수도 있고(img가 p 엘리먼트 안에 중첩될 때) 또는 DOM 트리의 가장 위에 있는 엘리먼트일 수 있다. (이것은 각 문서에 대해 단 한번의 특별한 경우이고 이곳에서 html 엘리먼트를 사용한다.) 또한 엘리먼트와 텍스트 모두 type을 갖고 있다고 생각해 보라. 한 엘리먼트의 type은 분명히 하나의 엘리먼트이다. 텍스트의 type은 텍스트이다. 각 노드는 또한 정의가 잘된 구조를 갖고 있다. 이 밑에 자식 엘리먼트 같은 하나의 노드(또는 노드들)을 갖는가? 이것이 자매 노드(sibling node) (엘리먼트나 텍스트 옆에 있는 노드)를 갖는가? 각 노드에는 어떤 문서에 속하는가?

    다분히 추상적으로 들린다. 사실 엘리먼트의 유형은 음… 엘리먼트이다 라고 말하는 것은 어리석어 보인다. 하지만 일반 객체 유형으로서 노드를 갖는다는 것의 가치는 추상적으로 이해해야 한다.

     

     

    공통 노드 유형

     

    여러분의 DOM 코드에서 그 어떤 것 보다 많이 수행하는 일은 도움 트리 안을 검색하는 것이다. 예를 들어, "id" 애트리뷰트 별로 form을 배치하고 그 form 안에 중첩된 엘리먼트와 텍스트로 작업하기 시작한다. 텍스트 명령어, 인풋 필드용 레이블, 실제 input 엘리먼트, img 엘리먼트와 링크(a 엘리먼트) 같은 HTML 엘리먼트가 있을 것이다. 엘리먼트와 텍스트가 완전히 다른 유형유형이라면 여러분은 완전히 다른 코드를 작성하여 한 유형에서 다른 유형으로 옮겨가야 한다.

    공통 노드 유형을 사용한다면 상황은 달라진다. 이 경우 노드에서 노드로 간단히 움직일 수 있고 엘리먼트나 텍스트의 특정의 것을 수행하고 싶을 때에만 노드의 유형을 생각하면 된다. DOM 트리 주위로 이동할 때 같은 연산을 사용하여 엘리먼트의 부모 또는 자식으로 이동한다. 엘리먼트의 애트리뷰트 같은 특정 노드 유형에서 구체적인 작업이 필요하다면 엘리먼트나 텍스트 같은 하나의 노드 유형에 대해서만 작업하면 된다. DOM 트리에 있는 각 객체를 하나의 노드로 생각하면 훨씬 간단하게 작업할 수 있다. 이제부터는 DOM Node 구조가 정확히 무엇을 제공하는지를 설명하겠다. 속성과 메소드부터 시작한다.

     

     

    노드의 속성

    DOM 노드와 작업할 때 여러 속성과 메소드를 사용한다면 다음 사항들을 먼저 생각해야 한다. 다음은 DOM 노드의 핵심 속성이다.

  • nodeName은 노드의 이름을 나타낸다. (아래 참조)
  • nodeValue:는 노드의 "값"을 제공한다. (아래 참조)
  • parentNode는 노드의 부모를 리턴한다. 모든 엘리먼트, 애트리뷰트, 텍스트는 부모 노드를 갖고 있다는 것을 기억하라.
  • childNodes는 노드의 자식들의 리스트이다. HTML로 작업할 때 엘리먼트를 다룰 경우 이 리스트는 유용하다. 텍스트 노드와 애트리뷰트 노드는 어떤 자식도 갖지 않는다.
  • firstChild는 childNodes 리스트에 있는 첫 번째 노드로 가는 지름길이다.
  • lastChild도 또 다른 지름길이다. childNodes 리스트에 있는 마지막 노드로 가는 지름길이다.
  • previousSibling은 현재 노드 앞에 있는 노드를 리턴한다. 다시 말해서, 현재 것 보다 앞에 있는 노드를 리턴한다. 현재 노드의 부모의
  • childNodes 리스트에 있는 것 보다 선행하는 노드를 리턴한다. (헷갈린다면 마지막 문장을 다시 한번 더 읽어라.)
  • nextSibling은 previousSibling 속성과 비슷하다. 부모의 childNodes 리스트에 있는 다음 노드로 돌린다.
  • attributes는 엘리먼트 노드에서 유일하게 유용한 것이다. 엘리먼트의 애트리뷰트 리스트를 리턴한다.

    몇몇 다른 속성들은 보다 근본적인 XML 문서로 적용되고 HTML 기반의 웹 페이지로 작업할 때 많이 사용되지 않는다.

     

     

    특별한 속성

     

    위에서 정의된 대부분의 속성들이 다분히 설명적이다. nodeName과 nodeValue 속성을 빼면 말이다. 이러한 속성들을 설명하지 않고 대신 기이한 질문 두 가지를 생각해 보자. 텍스트 노드용 nodeName은 무엇인가? 혹은 엘리먼트용 nodeValue는 무엇이 될까?

    이러한 질문들이 당황스럽다면 이러한 속성들에 내재해 있는 혼돈을 이미 이해하고 있는 것이다. nodeName과 nodeValue는 실제로 모든 노드 유형에 적용되는 것은 아니다. (한 노드 상의 다른 속성들의 경우도 마찬가지다.) 이 속성들은 null 값을 리턴할 수 있다. (JavaScript에서는 "undefined"로 나타난다.) 예를 들어, 텍스트 노드용 nodeName 속성은 무효이다. (또는 어떤 브라우저에서는 "undefined"이다. 텍스트 노드는 이름이 없기 때문이다. nodeValue는 노드의 텍스트를 리턴한다.)

    비슷하게, 엘리먼트는 nodeName --엘리먼트의 이름--을 갖고 있지만 엘리먼트의 nodeValue 속성의 값은 언제나 무효이다. 애트리뷰트는 nodeName과 nodeValue, 이 두 가지 속성에 대한 값을 갖는다. 이 개별 유형들을 다음 섹션에서는 자세히 설명하도록 하겠다.

    Listing 1은 실행 중인 여러 노드 속성들을 보여주고 있다.

     

    Listing 1. DOM에서 노드 속성 사용하기

    // These first two lines get the DOM tree for the current Web page, // and then the element for that DOM tree
    var myDocument = document;
    var htmlElement = myDocument.documentElement;

    // What's the name of the element? "html"
    alert("The root element of the page is " +htmlElement.nodeName);

    // Look for the element
    var headElement = htmlElement.getElementsByTagName("head")[0];
    if (headElement != null) {
    alert("We found the head element, named " +headElement.nodeName);

    // Print out the title of the page
    var titleElement = headElement.getElementsByTagName("title")[0];
    if (titleElement != null) {

    // The text will be the first child node of the

    var bodyElement = headElement.nextSibling;
    while (bodyElement.nodeName.toLowerCase() != "body") {
    bodyElement = bodyElement.nextSibling;
    }

    // We found the element...

    // Remove all the top-levelelements in the body
    if (bodyElement.hasChildNodes()) {
    for (i=0; ivar currentNode = bodyElement.childNodes[i];
    if (currentNode.nodeName.toLowerCase() == "img") {
    bodyElement.removeChild(currentNode);
    }
    }
    }
    }
    }
    :badtag -->



    JavaScript and DOM are a perfect match.
    You can read more inHead Rush Ajax.


    사용자 삽입 이미지





     

    이 페이지를 브라우저로 로딩하면 그림 1과 같이 된다.

    사용자 삽입 이미지


    그림 1. JavaScript를 실행하는 버튼이 있는 간단한 HTML 페이지

    Click Test me!를 클릭하면 경고 박스가 나타난다. (그림 2)

    사용자 삽입 이미지


    그림 2. nodeValue를 사용하여 엘리먼트의 이름을 보여주는 경고 박스

    코드 실행이 종료되면 이미지가 페이지에서 실시간으로 제거된다. (그림 3)

    사용자 삽입 이미지


    그림 3. JavaScript를 사용하여 실시간으로 제거되는 이미지

     

     

    API 디자인 설명

     

    각 노드에서 사용할 수 있는 속성과 메소드를 다시 한 번 보자. 이것은 객체 지향(OO) 프로그래밍에 익숙한 사람들을 위해 DOM의 핵심 포인트를 나타낸다. DOM은 객체 지향 API가 아니다. 우선, 많은 경우 여러분은 노드 객체에 메소드를 호출하기 보다는 객체의 속성들을 직접적으로 사용할 것이다. 예를 들어, getNodeName() 메소드가 없다. 다만 nodeName 속성을 직접 사용한다. 따라서 노드 객체들은(그리고 다른 DOM 객체들은) 함수가 아닌 속성들을 통해 많은 데이터를 노출한다.

    두 번째로, DOM의 객체와 메소드의 네이밍은 약간 낯설다. 만약 여러분이 객체와 객체 지향 API로 작업했다면 그렇게 느낄 것이다. (특히 자바나 C++). DOM은 C, 자바, JavaScript)에서 작동하기 때문에 일부 잉여물들이 API 디자인에 만들어 진다. 예를 들어, NamedNodeMap 메소드에 있는 두 개의 다른 메소드를 보자.

    • getNamedItem(String name)
    • getNamedItemNS(Node node)

    OO 프로그래머에게는 이것은 매우 이상해 보인다. 같은 목적을 갖고 있는 두 개의 메소드지만 하나는 String을 또 하나는 Node를 취한다. 대부분의 OO API에서 두 버전에 같은 메소드 이름을 사용한다. 코드를 실행하는 가상 머신은 메소드로 전달된 객체 유형에 기반하여 어떤 메소드를 실행할 것인지를 규명한다.

    문제는 JavaScript가 메소드 오버로딩(method overloading)이라는 기술을 지원하지 않는다는 점이다. 다시 말해서, JavaScript에서는 주어진 이름에 대해 하나의 메소드나 함수를 가져야 한다는 의미이다. 따라서 스트링을 취하는 getNamedItem() 메소드를 갖고 있다면 getNamedItem()이라는 이름의 다른 메소드나 함수를 가질 수 없다. 두 번째 버전이 다른 유형의 인자를 취하더라도 말이다. (또는 완전히 다른 인자를 취해도 마찬가지다.) 그럴 경우 JavaScript는 에러를 보고하고 코드는 작동하지 않는다.

    본질적으로 DOM은 메소드 오버로딩과 다른 OO 프로그래밍 기술들을 피한다. OO 프로그래밍 기술을 지원하지 않는 언어를 포함하여 API는 여러 언어들을 통해서 작동한다는 확신 때문이다. 결국 몇 가지 추가적인 메소드 이름을 배워야 한다는 것이다. 예를 들어 자바 같은 언어에서 DOM을 배울 수 있고 같은 메소드 이름과 코딩 구조가 자바스크립트 같은 DOM 구현을 가진 다른 언어들에도 작동할 것이라는 것을 알 수 있다.

     

     

    프로그래머를 조심시켜라!

     

    여러분이 API 디자인에 몰두해 있다면 궁금할 것이다. "왜 속성은 모든 노드에 대해 공통적이지 않는가?" 이것은 기술적인 이유 보다는 정치적이고 의사 결정에 관한 것이다. 간단히 말해서 정답은, "누가 알겠는가! 너무 귀찮다." 라고 밖에 말할 수 없다.

    nodeNamenodeName 속성은 모든 유형이 이름을 가질 수 있도록 하고 있다. 하지만 많은 경우 그 이름은 정의되지 않았거나 프로그래머에게는 어떤 가치도 없는 낯선 이름이다. (예를 들어, 자바에서 텍스트 노드의 nodeName은 많은 경우 "#text"로 리포팅 된다. 근본적으로 에러 핸들링은 여러분에게 남겨지게 된다. 단순히 myNode.nodeName에 액세스 하여 그 값을 사용하는 것은 안전한 방법이 아니다. 많은 경우 그 값은 무효가 될 것이다. 따라서 프로그래밍에 이것이 적용될 때 프로그래머들이 주의해야 한다.

     

     

    일반 노드 유형들

     

    DOM 노드의 기능과 속성에 대해 알아보았으니 이제 여러분이 작업 할 특정 유형의 노드에 대해 배울 차례이다. 대부분의 웹 애플리케이션에서 네 가지 유형의 노드로 작업한다.

  • 문서 노드는 전체 HTML 문서를 나타낸다.
  • 앨리먼트 노드는 a 또는 img 같은 HTML 엘리먼트를 나타낸다.
  • 애트리뷰트 노드는 href (a 엘리먼트에 대해) 또는 src (img 엘리먼트에 대해) 같은 HTML 엘리먼트에 대한 애트리뷰트를 나타낸다.
  • 텍스트 노드는 "Click on the link below for a complete set list" 같은 HTML 문서에 있는 텍스트를 나타낸다. 이는 p, a, h2 같은 엘리먼트 내부에 나타나는 텍스트이다.

    HTML을 다룰 때 거의 모든 시간을 이러한 노드 유형으로 작업한다. 이제부터 이 부분을 상세히 설명하겠다. (향후 기술 자료에서는 XML에 대해 설명하겠다.)

     

    문서 노드

     

    첫 번째 노드 유형은 DOM 기반 코드의 거의 모든 부분에서 여러분이 사용하게 될 유형이다. 바로 문서 노드이다. 문서 노드는 실제로 HTML(또는 XML) 페이지에 있는 엘리먼트가 아니라 페이지 그 자체이다. 따라서 HTML 웹 페이지에서 문서 노드는 전체 DOM 트리이다. 자바스크립트에서 document 키워드를 사용하여 문서 노드에 액세스 할 수 있다.

     

    // These first two lines get the DOM tree for the current Web page,

    // and then the element for that DOM tree

    var myDocument = document;
    var htmlElement = myDocument.documentElement;

     

    자바스크립트의 document 키워드는 현재 웹 페이지에 대한 DOM 트리를 리턴한다. 여기에서부터 여러분은 트리에 있는 모든 노드들과 작업할 수 있다.

    또한 document 객체를 사용하여 다음과 같은 메소드를 사용하는 새로운 노드를 만들 수 있다.

  • createElement(elementName)는 제공된 이름을 가진 엘리먼트를 만든다.
  • createTextNode(text)는 제공된 텍스트를 가진 새로운 텍스트 노드를 만든다.
  • createAttribute(attributeName)는 제공된 이름을 가진 새로운 애트리뷰트를 만든다.

    여기에서 주목해야 할 것은 이러한 메소드들이 노드를 만들지만 이들을 첨부하거나 이들을 특정 문서에 삽입하지 않는다는 점이다. 따라서 이미 봤던 insertBefore() 또는 appendChild() 같은 메소드들 중 하나를 사용해야 한다. 따라서 다음과 같은 코드를 사용하여 새로운 엘리먼트를 만들어 문서에 붙여야 한다.

     

    var pElement = myDocument.createElement("p");
    var text = myDocument.createTextNode("Here's some text in a p element.");
    pElement.appendChild(text);
    bodyElement.appendChild(pElement);

     

    document 엘리먼트를 사용하여 웹 페이지의 DOM 트리에 액세스 하면 엘리먼트, 애트리뷰트, 텍스트와 직접 작업할 준비가 된 것이다.

     

     

    엘리먼트 노드

     

    엘리먼트 노드와 많이 작업했지만 엘리먼트에 대해 수행해야 하는 많은 연산들에는 엘리먼트에만 해당하는 메소드와 속성 보다는 모든 노드들에 공통적인 메소드와 속성들이 포함된다. 단 두 개의 메소드 세트만 엘리먼트에 관한 것이다.

    1. 애트리뷰트와 작동하는 것과 관련된 메소드: : 

  • getAttribute(name)는 name이라는 애트리뷰트의 값을 리턴한다.  
  • removeAttribute(name)는 name이라는 애트리뷰트를 제거한다.  
  • setAttribute(name, value)는 name이라는 애트리뷰트를 만들고 이것의 값을 value로 설정한다.  
  • getAttributeNode(name)는 name라고 하는 애트리뷰트 노드를 리턴한다. (애트리뷰트 노드는 아래에서 설명한다.)  
  • removeAttributeNode(node)는 제공된 노드와 매치되는 애트리뷰트 노드를 제거한다.

    2. 중첩된 엘리먼트를 찾는 메소드: : 
  • getElementsByTagName(elementName)는 제공된 이름을 가진 엘리먼트 노드의 리스트를 리턴한다.

    설명으로도 충분하지만 몇 가지 예제를 보도록 하자.

     

     

    애트리뷰트 작업

     

    애트리뷰트 작동은 매우 단순하다. 예를 들어, 도큐먼트 객체로 새로운 img 엘리먼트를 만들고, 엘리먼트, 위에서 몇 가지 메소드를 만든다.

     

    var imgElement = document.createElement("img");
    imgElement.setAttribute("src", "http://www.headfirstlabs.com/Images/hk240000000085.jpg");
    imgElement.setAttribute("width", "130");
    imgElement.setAttribute("height", "150");
    bodyElement.appendChild(imgElement);

     

    지금까지는 평범해 보인다. 사실 노드의 개념을 이해하고 사용할 수 있는 메소드를 알면 웹 페이지와 자바스크립트 코드에서 DOM으로 작업하는 것은 단순하다. 위 코드에서 자바스크립트는 새로운 img 엘리먼트를 만들고 애트리뷰트를 설정한 다음 이것을 HTML 페이지의 바디에 추가한다.

     

     

    중첩 엘리먼트 찾기

     

    중첩된 엘리먼트를 찾기도 쉽다. 예를 들어, Listing 3의 HTML 페이지에서 모든 img엘리먼트를 찾아 제거하는데 사용했던 코드가 있다.

     

    // Remove all the top-levelelements in the body
    if (bodyElement.hasChildNodes()) {
    for (i=0; ivar currentNode = bodyElement.childNodes[i];
    if (currentNode.nodeName.toLowerCase() == "img") {
    bodyElement.removeChild(currentNode);
    }
    }
    }

     

    getElementsByTagName()을 사용하여 비슷한 효과를 얻을 수 있다.

     

    // Remove all the top-levelelements in the body var imgElements = bodyElement.getElementsByTagName("img"); for (i=0; i

     

    애트리뷰트 노드

     

    DOM은 애트리뷰트를 노드로서 나타내고 여러분은 언제나 엘리먼트의 attributes 속성을 얻을 수 있다.

     

    // Remove all the top-levelelements in the body
    var imgElements = bodyElement.getElementsByTagName("img");

    for (i=0; ivar imgElement = imgElements.item[i];

    // Print out some information about this element
    var msg = "Found an img element!";
    var atts = imgElement.attributes;
    for (j=0; jivar att = atts.item(j);
    msg = msg + "\n " + att.nodeName + ": '" + att.nodeValue + "'";
    }
    alert(msg);

    bodyElement.removeChild(imgElement);
    }

     

    attributes 속성은 실제로 엘리먼트 유형이 아닌 노드 유형에 있다. 이것은 코딩에 영향을 주지 않지만 알아둘 필요가 있다.

    애트리뷰트 노드에서 작업하는 것이 가능하지만 엘리먼트 클래스에서 사용할 수 있는 메소드를 사용하여 애트리뷰트 작업을 하는 것이 더 쉽다. 메소드는 다음과 같다.

  • getAttribute(name)는 name이라는 애트리뷰트의 값을 리턴한다.
  • removeAttribute(name)는 name이라는 애트리뷰트를 제거한다.
  • setAttribute(name, value)는 name이라는 애트리뷰트를 만들고 이것의 값을 value로 설정한다.
    이 세 개의 메소드들로 인해 여러분은 애트리뷰트 노드와 직접 작업할 필요가 없다. 대신 애트리뷰트와 이것의 값과 함께 간단한 스트링 속성을 설정 및 제거할 수 있다.

     

     

    애트리뷰트의 이상한 측면
    애트리뷰트는 DOM에 있어서는 조금 특별하다. 애트리뷰트는 다른 엘리먼트나 텍스트의 경우와는 달리 엘리먼트의 자식이 아니다. 다시 말해서 엘리먼트의 밑에 나타나지 않는다. 동시에 이것은 엘리먼트와 관계를 갖고 있다. 엘리먼트는 자신의 애트리뷰트를 소유한다. DOM은 노드를 사용하여 애트리뷰트를 나타내고 이들을 특별한 리스트를 통해 엘리먼트에 대해 사용할 수 있도록 한다. 따라서 엘리먼트는 DOM 트리의 일부지만 이들은 트리에는 나타나지 않는다. DOM 트리 구조의 나머지에 대한 애트리뷰트의 관계는 다소 어지럽다.

     

     

    텍스트 노드

     

    여러분이 걱정하고 있는 마지막 노드 유형이자 HTML DOM 트리로 작업하는 유형은 텍스트 노드이다. 텍스트 노드와 작업하기 위해 공통적으로 사용하게 될 거의 모든 속성들은 실제로 노드 객체에서도 사용할 수 있다. 사실 nodeValue 속성을 사용하여 텍스트 노드에서 텍스트를 얻을 수 있다.

     

    var pElements = bodyElement.getElementsByTagName("p");
    for (i=0; ivar pElement = pElements.item(i);
    var text = pElement.firstChild.nodeValue;
    alert(text);
    }

     

    몇 가지 다른 메소드들은 텍스트 노드만의 것이다. 이들은 노드에 있는 데이터를 추가하거나 쪼갠다.

  • appendData(text)는 여러분이 제공한 텍스트를 텍스트 노드의 기존 텍스트의 끝에 추가한다.
  • insertData(position, text)는 텍스트 노드의 중간에 데이터를 삽입할 수 있다. 이것은 지정된 위치에 여러분이 제공한 텍스트를 삽입한다.
  • replaceData(position, length, text)는 지정된 위치부터 시작하여 지정된 길이의 문자를 제거하고 여러분이 제공한 텍스트를 제거된 텍스트를 대신하여 메소드에 둔다.

     

     

    노드의 유형

     

    여러분이 작업할 노드 유형이 무엇인지에 대해 이미 알고 있다는 전제 하에 설명을 해왔다. 만일 DOM 트리를 통해 검색하고 일반 노드 유형들로 작업한다면 엘리먼트나 텍스트로 이동했는지의 여부를 모를 것이다. 아마도 p 엘리먼트의 모든 자식들을 갖게 되고, 텍스트, b 엘리먼트, 아니면 img 엘리먼트로 작업하는지 확신할 수 없다. 이 경우 더 많은 일을 하기 전에 어떤 유형의 노드를 가졌는지를 규명해야 한다.

    다행히도 이것을 파악하기는 매우 쉽다. DOM 노드 유형은 여려 상수들을 정의한다.

  • Node.ELEMENT_NODE는 엘리먼트 노드 유형에 대한 상수이다.
  • Node.ATTRIBUTE_NODE는 애트리뷰트 노드 유형에 대한 상수이다.
  • Node.TEXT_NODE는 텍스트 노드 유형에 대한 상수이다.
  • Node.DOCUMENT_NODE는 문서 노드 유형에 대한 상수이다.

    다른 노드 유형들도 많이 있지만 HTML을 처리할 때에는 이 네 가지 외에는 별로 다루지 않는다. 이들 상수의 값이 DOM 스팩으로 정의되었지만 의도적으로 남겨두었다. 여러분은 이 값으로 절대 직접 처리해서는 안된다. 바로 이것 때문에 상수가 있는 것이니까.

     

     

    nodeType 속성

     

    DOM 노드 유형에 대해 정의되었기 때문에 모든 노드에서 사용할 수 있는 nodeType 속성을 사용하여 노드를 위 상수와 비교할 수 있다.

     

    var someNode = document.documentElement.firstChild;
    if (someNode.nodeType == Node.ELEMENT_NODE) {
    alert("We've found an element node named " + someNode.nodeName);
    } else if (someNode.nodeType == Node.TEXT_NODE) {
    alert("It's a text node; the text is " + someNode.nodeValue);
    } else if (someNode.nodeType == Node.ATTRIBUTE_NODE) {
    alert("It's an attribute named " + someNode.nodeName
    + " with a value of '" + someNode.nodeValue + "'");
    }

     

    이것은 매우 단순한 예제이지만 포인트가 있다. 노드의 유형을 얻는 것은 단순하다. 일단 어떤 유형인지를 알면 노드로 무엇을 할 것인지를 규명해야 한다. 하지만 노드, 텍스트, 애트리뷰트, 엘리먼트 유형이 무엇을 제공하는지 확실히 안다면 DOM 프로그래밍을 직접 할 준비가 된 것이다.

     

     

    작업의 고통

     

    nodeType 속성이 노드로 작업할 수 있는 티켓인 것처럼 들린다. 이것으로 여러분은 어떤 유형의 노드로 작업하고 있는지를 규명하고 그 노드를 다룰 코드를 작성할 수 있다. 문제는 위에 정의된 Node 상수들이 Internet Explorer 상에서는 올바르게 작동하지 않는다는 점이다. 따라서 Node.ELEMENT_NODE, Node.TEXT_NODE 또는 코드의 다른 상수를 사용한다면 Internet Explorer는 그림 4와 같은 에러를 리턴할 것이다.

    사용자 삽입 이미지


    그림 4. Internet Explorer의 에러 리포팅

    Internet Explorer는 여러분이 자바스크립트에서 Node 상수를 사용할 때 마다 이러한 에러를 보고 할 것이다. 거의 모든 사람들이 Internet Explorer를 사용하기 때문에 Node.ELEMENT_NODE 또는 Node.TEXT_NODE 같은 구조를 피해야 한다. Internet Explorer 7.0이 이러한 문제를 정정했다 하지만 Internet Explorer 6.x의 대중성에 미치려면 오랜 시간이 남았다. 따라서 Node 사용을 피해라. 여러분의 DOM 코드(그리고 Ajax 애플리케이션)가 모든 주요 브라우저에서 작동해야 하기 때문이다.

     

     

    결론

     

    본 시리즈를 통해 많은 것을 배웠다. 오늘 배운 것을 그냥 머리로 익히지만 말고 DOM 트리를 직접 사용해 볼 것을 권한다. DOM을 사용하여 멋진 효과나 그럴듯한 인터페이스를 만드는 방법을 연구해 보라. 여러분에게 내주는 숙제이다. 지난 두 개의 기술자료에서 배운 것을 실험해 보기 바란다. 사용자 액션에 대한 응답으로 스크린 상을 돌아다니는 것 같은 웹 사이트를 만든다는 것을 상상해 보라.

    스크린 상의 모든 객체 주위의 보더를 없애기 때문에 여러분은 DOM 트리에서 객체들이 어디에 있는지 볼 수 있고 움직일 수 잇다. 노드를 만들고 이것을 기존 자식 리스트에 붙인다. 많은 중첩 노드들을 가진 노드들을 제거한다. CSS 스타일을 노드를 변경하고 그러한 변화가 자식 노드에 상속되었는지를 확인한다. 가능성은 무한하다. 새로운 것을 시도할 때 마다 새로운 것을 배운다. 웹 페이지를 즐겨라.

    다음 글에서는 DOM의 멋진 애플리케이션들을 여러분의 프로그래밍과 결합하는 방법을 설명할 것이다. API에 대한 개념적인 설명은 그만두고 코드를 보여주겠다. 그때까지 자신 스스로 어떻게 할 것인지를 생각해 보라.

     

     

    정상에 설 준비가 되었나요?

    여러분이 진정 DOM을 완벽히 이해했다면 웹 프로그래밍 기술 레벨의 꼭대기에 오르게 될 것이다. 대부분의 웹 프로그래머들은 자바스크립트를 사용하여 이미지 롤오버를 작성하는 방법, 폼에서 값을 얻는 방법을 알고 있다. 심지어 서버에서 요청을 만들고 응답을 받는 사람들도 있다. 하지만 웹 페이지의 구조를 바꾸는 일은 소심한 사람이나 경험 없는 사람들은 피해주기 바란다.

     

     

    참고자료

    교육
    - Ajax 마스터
      - Part 1: Ajax 소개(developerWorks, December 2005) Ajax 마스터하기
      - Part 2: JavaScript와 Ajax를 이용한 비동기식 요청 (developerWorks, January 2006) Ajax 마스터하기
      - Part 3: Ajax의 고급 요청 및 응답(developerWorks, February 2006) Ajax 마스터하기
      - Part 4: 웹 응답에 DOM 활용하기

    - 자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현
    - 자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화
    - Call SOAP Web services with Ajax, Part 1: Build the Web services client
    - Ajax: A New Approach to Web Applications
    - The DOM Home Page
    - The DOM Level 3 Core Specification
    - The ECMAScript language bindings for DOM
    - developerWorks Web architecture zone
    - developerWorks technical events and Webcasts

    제품 및 기술 얻기
    -
    Head Rush Ajax
    -Java and XML
    -JavaScript: The Definitive Guide
    -Head First HTML with CSS & XHTML
    -IBM trial software

    토론
    -developerWorks blogs.

     

     

    사용자 삽입 이미지



    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3057

      Comments,     Trackbacks
    [Ajax] Ajax 마스터하기 - 웹 응답에 DOM 활용하기 [PART 04]

    [Ajax] Ajax 마스터하기 - 웹 응답에 DOM 활용하기 [PART 04]

     

    개요
    PART 01/ Ajax 소개
    PART 02/ JavaScript와 Ajax를 이용한 비동기식 요청
    PART 03/ Ajax의 고급 요청 및 응답
    PART 04/ 웹 응답에 DOM 활용하기
    PART 05/ DOM 다루기


     

    HTML, JavaScript™, DHTML, DOM으로 구성된 Ajax는 볼품없는 웹 인터페이스를 인터랙티브 Ajax 애플리케이션으로 변형하는 획기적인 방식이다. Ajax 전문가인 필자는 이러한 기술들이 어떻게 작용하는지 전체적인 개요를 비롯하여 세부사항 까지 설명한다. 또한 XMLHttpRequest 객체 같은 Ajax의 중심적인 개념들을 소개한다.

     

    5년 전, XML에 대해 무지했다면 아무도 얘기할 상대가 없는 미운 오리 새끼 신세가 되었을지도 모르겠다. Ruby 프로그램이 주목을 받았던 8개월 전, Ruby 프로그램 언어 기능에 대해 알지 못했던 프로그래머들은 냉수기 관련 산업세계에서 환영 받지 못했다. 그런 것처럼, 최신 기술단계로 입문하고자 한다면 Ajax에 대해 알아야 한다.

    하지만 Ajax는 일시적으로 유행하는 툴이 아니다. 웹 사이트를 구축하는 강력한 방식이며 완전히 새로운 언어를 배우는 것보다는 그다지 어렵지 않다.

    Ajax에 관해 자세히 들어가기 전에 잠시 Ajax의 기능에 대해 알아보자. 오늘날 애플리케이션을 작성할 시 두 가지 애플리케이션이 있다.

    • 데스크톱 애플리케이션
    • 웹 애플리케이션

    두 애플리케이션은 다 친숙한 것들이다. 일반적으로 데스크톱 애플리케이션은 CD상에 배치된 다음 (또는 웹 사이트에서 다운로드) 컴퓨터에 완전 설치된다. 이 애플리케이션은 인터넷을 이용해 업데이트를 다운로드하기도 하지만 애플리케이션 실행 코드는 데스크톱 상에 상주해 있다. 전혀 새로운 것이 아닌 웹 애플리케이션은 웹 서버 상에서 실행되며 웹 브라우저 상에서 접속된다.

    하지만 두 애플리케이션에 대한 코드 실행 위치보다 애플리케이션 작동방식 및 애플리케이션과 사용자와의 상호작용방식이 중요하다. 일반적으로 데스크톱 애플리케이션은 상당히 빠르고 (컴퓨터 상에서 실행되고 인터넷 상에서 대기 중인 상태가 안 나온다.), 대형 사용자 인터페이스(일반적으로 운영체제와 상호작용)를 갖추며 상당히 동적이다. 거의 대기시간 없이 메뉴 및 하위 메뉴를 클릭, 지시, 입력하고 풀업한다.

    반면 웹 애플리케이션은 가장 최신 것이며 데스크톱에서는 전혀 얻을 수 없는 서비스를 제공한다.(Amazon.com 및 eBay를 생각해 볼 것.) 하지만 웹 애플리케이션 기능으로 인해 서버 응답 대기, 스크린 재생 대기, Request 컴백 및 새 페이지 생성에 관한 대기 기능 등이 부수된다.

    분명 지나친 단순화 과정임에는 틀림없지만 기본 개념은 얻게 된다. 이미 눈치를 챘겠지만 Ajax는 데스크톱 애플리케이션 및 항상 업데이트 되는 웹 애플리케이션의 기능 및 상호작용 간의 차이를 줄여주는 역할을 한다. 여러분은 마치 데스크톱 애플리케이션에서 찾은 것처럼 동적 사용자 인터페이스 및 가상 제어기능을 사용한다. 하지만 웹 애플리케이션 상에서 데스크톱 애플리케이션을 이용할 수 있다. 그러면 대기 중인 것이 무엇인가? Ajax 및 볼품없는 웹 인터페이스가 응답 Ajax 애플리케이션으로 변환되는 과정에 대해 살펴보기로 하자.

    그러면 대기 중인 것이 무엇인가? Ajax 및 볼품없는 웹 인터페이스가 응답 Ajax 애플리케이션으로 변환되는 과정에 대해 살펴보기로 하자.

     

     

    오래된 기술, 새로운 기법

     

    Ajax에 관해 살펴보면 Ajax는 실지로 많은 기술들이 응집되어 있다. Ajax의 기본을 마치고 넘어가려면 몇 가지 다른 기술들(필자는 첫 번째 이 시리즈에서 각각의 기술에 관해 설명할 것이다.)을 면밀히 살펴보아야 한다. 하지만 이들 기술 가운데 어느 정도 알고 있는 것이 많은 건 다행이다. 더군다나 각각의 기술 대부분은 Java/Ruby같은 프로그래밍 언어만큼 어려운 게 아니라서 배우기 쉽다.

    Ajax 애플리케이션에 포함된 기본기술은 다음과 같다.

  • 웹 양식을 구축하고 애플리케이션 완료 때까지 사용되는 필드를 식별하는 데 HTML을 사용한다.
  • 자바 스크립트 코드는 Ajax 애플리케이션을 실행하는 중심 코드며 서버 애플리케이션과의 커뮤니케이션을 용이하게 한다.
  • DHTML(동적 HTML)은 웹 양식을 동적으로 업데이트 한다. div, span및 기타 동적 HTML 요소를 사용해 HTML을 마크업 한다.
  • 서버에서 복귀된 HTML 및 (때로) XML 구조를 다루는 데 있어 DOM, 즉 문서 객체 모델(Document Object Model)을 사용한다.

    이 기술들에 대해 간략히 요약하고 각 기술의 기능에 대해 좀 더 알아보기로 하는데 각 기술에 관한 자세한 사항은 차후 글에서 다룰 것이다. 우선은 Ajax의 구성요소 및 기술에 대해 친숙해 지는 데 초점을 맞추기로 한다. 자바 스크립트에 익숙할수록 Ajax에 담긴 기술에 관한 일반적인 지식 단계에서 각 기술에 관한 자세한 지식으로 넘어가는 게 더 쉬워진다.(또한 이로 인해 웹 애플리케이션 개발에 관한 문이 열리게 된다.)

     

    Ajax 정의
    Ajax는 비동기 JavaScript 및 XML의 약어이다.(DHTML도 마찬가지다.) Adaptive Path사의 Jesse James Garrett이 이 약어를 만들어냈으며(참고자료 참조), Jesse에 따르면 이 약어는 두문자어는 아니라고 한다.

     

     

     

    XMLHttpRequest 객체

     

    알고자 하는 객체 중 첫 번째는 아마도 가장 생소한 것이 아닌가 싶다. 그 객체는 일명 XMLHttpRequest인데 자바 스크립트 객체의 일종이며 Listing 1에 나와 있는 것처럼 단순하게 생성된다

     

    Listing 1. 새로운 XMLHttpRequest 객체 생성


    <script language="javascript" type="text/javascript">
    var xmlHttp = new XMLHttpRequest();
    </script>

     

    필자는 다음 글에서 이 객체에 대해 더 논의할 것이다. 하지만 지금 상태에서는 모든 서버 커뮤니케이션을 다루는 객체라는 사실만 알아둔다. 다음 사항으로 가기 전에 잠깐 생각해 보면 자바 스크립트 객체는 XMLHttpRequest를 통해 서버에 전달하는 자바 스크립트 기술의 일종이다. 이 객체는 애플리케이션 흐름이 정상적이지 않으며 Ajax 기술의 많은 부분을 차지하고 있다.

    정상적인 웹 애플리케이션에서 사용자는 양식 필드를 기입하며 제출 버튼을 클릭한다. 그러면 전 양식을 서버에 보내며 서버는 처리과정을 통해 양식을 스크립트(일반적으로 PHP, 자바 또는 CGI 과정/이와 유사한 과정)에 전송한다. 스크립트를 실행할 때 스트립트를 통해 완전히 새로운 페이지가 전송된다. 그 페이지는 데이터가 작성된 새로운 양식의 HTML/확인 페이지 또는 원 양식에 기입된 데이터에 근거해 선택된 옵션이 포함된 페이지일 수 있다. 물론, 서버 상의 스크립트/프로그램이 처리되면서 새로운 양식을 다시 보내는 동안 사용자는 대기해야 한다. 서버로부터 데이터를 다시 받을 때까지는 스크린 상에 아무 것도 없게 되며 결국 대화성은 낮게 된다. 사용자는 즉각적으로 응답을 받지 못하며 데스크톱 애플리케이션 상에서 작업하는 기분이 들지 않게 된다.

    Ajax는 근본적으로 자바 스크립트 기술 및 웹 양식 및 서버 간의 XMLHttpRequest 객체를 결합한다. 사용자가 웹 양식을 기입할 때 데이터는 직접 서버 스크립트에 전송되지 않고 자바 스크립트 코드에 전달된다. 대신 자바 스크립트 코드는 양식 데이터를 포착해 Request를 서버에 전송한다. 이 과정이 일어나는 동안, 사용자 스크린 상의 양식은 순식간에 나타나거나 깜빡이거나 사라지거나 정지하지 않는다. 즉 자바 스크립트 코드는 몰래 Request를 전송하며 사용자는 Request가 만들어졌는지도 알지 못한다. 게다가 Request를 비동기적으로 전송하기 때문에 더 좋은 상황이 된다. 이는 자바 스크립트에서 서버 응답을 그냥 대기하지 않는다는 것을 의미한다. 따라서, 사용자는 데이터를 계속 기입하고 화면이동하고 애플리케이션을 사용한다.

    그런 다음 서버는 자바 스크립트 코드(웹 양식에 대해 아직도 대기 중임)에 데이터를 다시 전송한다. 자바 스크립트 코드에서는 데이터와의 상호기능을 결정하며 연속적으로 양식 필드를 업데이트 하면서 애플리케이션에 즉각적인 응답을 준다. 결국 사용자는 양식을 제출/재생하는 작업 없이 새로운 데이터를 얻게 된다. 자바 스크립트 코드는 데이터를 얻고 계산도 수행하며 또 다른 Request를 전송하며 이런 모든 과정은 사용자 개입 없이도 된다! 이것이 바로 XMLHttpRequest 객체의 장점이다. XMLHttpRequest 객체는 서버와 같이 커뮤니케이션을 주고받고 사용자는 그 과정에서 벌어지는 과정을 알지 못한다. 이로 인해 데스크톱 애플리케이션과 마찬가지로 동적, 상호 반응적인 고도의 양방향 경험을 얻게 되지만 그 속에 인터넷의 모든 장점이 담겨 있다.

     

     

    자바 스크립트에 대한 부가사항

     

    일단 XMLHttpRequest에 대해 다루게 되면 나머지 자바 스크립트 코드는 상당히 평범한 것들이다. 사실 다음과 같은 기본적인 작업에 자바 스크립트 코드를 이용한다.

  • 양식 데이터 얻기: 자바 스크립트 코드로 HTML 양식에서 데이터를 꺼내 이를 서버에 전송하는 작업이 간단해진다.
  • 양식 상의 값 변환: 필드 값 설정에서 연속적인 이미지 교체작업에 이르는 양식 업데이트 작업 또한 간단하다.
  • HTML 및 XML 구문분석: 자바 스크립트 코드를 이용해 DOM(다음 섹션 참조)을 처리하고 서버에서 다시 전송하는 HTML 양식 및 임의의 XML 데이터에 관한 구조를 다루게 된다.

    첫 번째 두 항목에 대해서 여러분은 Listing 2에 나온 대로 getElementById()에 익숙해지려 할 것이다.

     

    Listing 2. 자바 스크립트 코드에서의 필드 값 포착 및 설정

    // Get the value of the "phone" field and stuff it in a variable called phone
    var phone = document.getElementById("phone").value;

    // Set some values on a form using an array called response
    document.getElementById("order").value = response[0];
    document.getElementById("address").value = response[1];

     

    Ajax 애플리케이션에서 특별히 획기적인 사항은 없고 상기 사항 정도면 충분하다. 이에 대해 상당히 복잡한 건 없다는 사실을 깨달아야 한다. 일단 XMLHttpRequest만 정복하면 Ajax 애플리케이션에서 나머지는 대부분 Listing 2에 나온 바와 같이 상당히 독창적인 HTML과 결합된 단순 자바 스크립트 코드다. 그런 다음 가끔 약간의 DOM 작업이 발생하게 된다. 이에 관해 살펴 보자.

     

     

    DOM으로 종료하기

     

    DOM, 즉 문서 객체 모델이라는 것이 있는데 이는 아주 중요하다. DOM에 대해 듣는 것은 그다지 어렵지 않다고 하는 사람들이 있다. HTML 디자이너에 의해서는 종종 사용되지 않으며 하이-엔드 프로그래밍 작업으로 들어가지 않는 한은 JavaScript 코더에서 흔치 않은 것이 바로 DOM이다. 종종 과중-업무 Java 및 C/C++ 프로그램 상에서 DOM을 종종 많이 활용하게 된다. 사실은 DOM이 배우기 어려운 특성 때문에 명성이 자자해 그 프로그램 상에서 종종 사용하는 것이 아닌가 싶다.

    다행히도 JavaScript 기술에 있어 DOM을 활용하는 일은 쉽고 대부분 직관적이다. 이 시점에서 필자는 DOM 사용법에 관해 보여 주고 적어도 이에 대한 몇 가지 코드 예를 제시하려 하지만 이 글의 의도와는 벗어나는 것 같다. DOM에 관해 대략적으로 다루는 것 없이도 Ajax에 대해 깊이 다룰 수 있다. 필자는 차후의 글에서 다시 DOM에 관해 다루려 한다. 하지만 지금 상황에서는 언급하지 않으려 한다. JavaScript 코드와 서버 사이에 XML을 이리저리 전송하고 HTML 양식을 변화시킬 때 DOM에 대해 자세히 다루게 될 것이다. 지금은 DOM없이 효과적인 Ajax 애플리케이션을 작동하는 게 쉬우므로DOM은 논외로 한다.

     

     

    Request 객체 얻기

     

    Ajax 애플리케이션에 관한 기본적 개념에 대해 배웠으면 몇 가지 특수사항에 대해 살펴 보자. XMLHttpRequest 객체는 Ajax 애플리케이션에서 중요하므로, 아마도 많은 이들에게는 생소한 것일 수도 있다. 거기서 필자는 논의를 시작한다. Listing 1에서 보다시피, XMLHttpRequest 객체를 생성, 사용하는 것은 상당히 쉬워야 한다. 잠깐만 기다려 보시라.

    수년 동안 브라우저에 관한 논란은 끊이지 않았고 동일한 브라우저로는 아무 것도 얻을 수 없다는 사실을 기억하는가? 믿건 말건, 소규모 브라우저에서도 이와 같은 논쟁은 끊이지 않고 있다. 더군다나 놀라운 사실은 XMLHttpRequest가 이 논란의 희생양 중 하나라는 것이다. 따라서 XMLHttpRequest 객체를 작동시키기 위해선 몇 가지 다른 작업을 해야 한다. 단계별로 설명하겠다.

     

     

    Microsoft 브라우저 다루기

     

    Microsoft 브라우저, Internet Explorer는 XML을 다룰 시 MSXML 구문분석계를 사용한다.(참고자료 참조) Internet Explorer 상에서 다뤄야 할 Ajax 애플리케이션을 작성할 시 독특한 방식으로 XMLHttpRequest 객체를 작성해야 한다.

    하지만 그렇게 간단한 작업은 아니다. Internet Explorer에 설치된 JavaScript 기술 버전에 따라 MSXML 버전도 변하게 되며 실지로 2개의 버전이 있다. 따라서 두 경우를 다루는 코드를 작성해야 한다. Microsoft 브라우저 상에서 XMLHttpRequest 객체를 생성하는 데 필요한 코드에 관해선 Listing 3을 보라.

     

    Listing 3. Microsoft 브라우저 상에서 XMLHttpRequest 객체 생성

    var xmlHttp = false;
    try {
    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e2) {
    xmlHttp = false;
    }
    }

     

    모든 작업이 정확히 맞아떨어지는 것은 아니다. 하지만 그래도 상관없다. 이 시리즈가 끝나기 전에 JavaScript 프로그래밍, 에러 취급 및 조건부 번역 및 기타 사항에 관해 자세히 다루게 될 것이다. 지금 현 상태에서는 두 가지 중심 라인만 다루고자 한다.

     

    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    and
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");.

     

    간단히 말해서, 이 코드로 MSXML의 한 버전을 이용해 XMLHttpRequest 객체 생성을 기한다. 하지만 객체가 생성되지 않는 경우 다른 버전을 사용해 XMLHttpRequest 객체를 생성한다. 두 코드 다 작동되지 않는 경우 xmlHttp 변수는 거짓으로 설정되고 작동되지 않는 것이 있다는 것을 코드에 알려 준다. 그럴 경우, 비-Microsoft 브라우저가 있을 가능성이 있다. 따라서 객체 생성을 위해선 다른 코드를 사용해야 한다.

     

     

    Mozilla 및 Microsoft 브라우저 다루기

     

    인터넷 브라우저를 선택하지 않거나 비-Microsoft 브라우저를 작성할 경우 다른 코드가 필요하다. 사실, 이 라인은 Listing 1에서 봤던 단순 코드라인이다.

     

    var xmlHttp = new XMLHttpRequest object;.

     

    이 단순한 라인으로 Mozilla, Firefox, Safari, Opera 및 임의의 양식/형태에서 Ajax애플리케이션을 지원하는 기타 비-Microsoft 브라우저에서 XMLHttpRequest 객체를 생성한다.

     

     

    지원기능 통합

     

    여기서 모든 브라우저를 지원하는 것이 중요하다. Internet Explorer/비-Microsoft 브라우저에서만 작동되는 애플리케이션을 작성하는 사람이 어디 있겠는가? 또한 더 심한 경우, 애플리케이션을 두 번 작성하고자 하는가? 물론 아니라고 믿는다. 따라서 코드에선 Internet Explorer 및 비-Microsoft 브라우저를 지원하는 기능이 포함되어야 한다. Listing 4에서는 다중-브라우저 방식으로 작동하는 코드에 대해 나와 있다.

     

    Listing 4. 다중 브라우저 방식으로 XMLHttpRequest 객체 생성하기

    /* Create a new XMLHttpRequest object to talk to the Web server */
    var xmlHttp = false;
    /*@cc_on @*/
    /*@if (@_jscript_version >= 5)
    try {
    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e2) {
    xmlHttp = false;
    }
    }
    @end @*/

    if (!xmlHttp && typeof XMLHttpRequest != 'undefined') {
    xmlHttp = new XMLHttpRequest();
    }

     

    지금 현재로선, 주석 및 @cc_on와 같은 어려운 태그를 무시한다. 이들은 다음 글에서 깊이 다룰 JavaScript 컴파일러 명령으로 오로지 XMLHttpRequest 객체 상에만 초점이 맞추어져 있다. 이 코드에 관한 핵심은 세 가지 과정으로 요약된다.

    1. 변수 xmlHttp를 생성해 앞으로 생성할 XMLHttpRequest 객체를 참조한다.
    2. Microsoft 브라우저에서의 객체를 시도, 생성한다.

    • Msxml2.XMLHTTP 객체를 사용해 XMLHttpRequest 객체를 시도, 생성한다.
    • 과정이 실패할 경우, Microsoft.XMLHTTP 객체를 사용해 XMLHttpRequest 객체를 시도, 생성한다.

    3. xmlHttp가 아직도 설정되지 않은 경우 비-Microsoft 방식으로 XMLHttpRequest 객체를 생성한다.

    위 과정 끝 단계 시 사용자가 실행하는 브라우저 종류에 관계없이 xmlHttp의 경우 유효한 XMLHttpRequest 객체를 인용한다.

     

     

    보안

     

    보안이란 무엇인가? 오늘날 브라우저는 사용자들에게 보안 레벨을 올리고 JavaScript 기술을 생성하며 브라우저 옵션을 해제하는 기능을 제공한다. 이 경우 코드가 작동되지 않는 경우도 있을 수 있다. 그 때 발생하는 문제를 적절하게 다뤄야 한다. 이에 관한 내용은 적어도 기사 한 분량을 차지할 정도라 나중에 다루기로 하겠다.(긴 시리즈가 될 것 같다, 그렇지 않은가? 하지만 걱정 마시라. 과정을 다 배우고 나면 이와 관련된 모든 사항을 숙달할 테니까.) 현재로선 강력하지만 완전하지 않은 코드를 작성하는 중이다. 이 코드는 Ajax 애플리케이션을 관리하는 데 좋다.

     

     

    Ajax 세계에서의 Request/Response

     

    인제 Ajax 애플리케이션에 대해 이해하고 XMLHttpRequest 객체 및 객체 생성에 관한 기본적인 개념을 얻는다. 자세히 읽다 보면 Ajax 애플리케이션은 웹 애플리케이션에 제출되는 HTML 양식보단 서버 상의 임의의 웹 애플리케이션에 대화하는 JavaScript 기술이라는 사실을 알게 된다.

    그러면 빠진 부분은 어떤 것인가? 실질적인 XMLHttpRequest 객체 사용법이다. 이 객체는 작성하는 각각의 Ajax 애플리케이션에서 일정 형태로 사용하는 중요 코드라 Ajax 애플리케이션이 포함된 기본 Request/응답 모델 모양을 통해 객체 사용법을 빨리 익힌다.

     

     

    Request 만들기

     

    새로운 XMLHttpRequest 객체가 있는 경우 이를 시험해 보자. 먼저 웹 페이지에서 호출하는 JavaScript 방법이 필요하다.(사용자가 텍스트에서 입력하거나 메뉴에서 옵션을 선택할 시와 같음.) 그 다음, 거의 모든 Ajax 애플리케이션에서의 동일한 기본 아웃라인을 따른다.

    1. 웹 양식으로부터 필요한 모든 데이터 얻기
    2. 연결할 URL 구축
    3. 서버 연결
    4. 서버 실행 종료 시 서버 실행 기능 설정
    5. Request 전송

    Listing 5는 위의 순서대로 5단계를 진행하는 Ajax 방법의 예에 관해 나와 있다.

     

    Listing 5. Ajax가 포함된 Request 만들기

    function callServer() {
    // Get the city and state from the web form
    var city = document.getElementById("city").value;
    var state = document.getElementById("state").value;
    // Only go on if there are values for both fields
    if ((city == null) || (city == "")) return;
    if ((state == null) || (state == "")) return;

    // Build the URL to connect to
    var url = "/scripts/getZipCode.php?city=" + escape(city) + "&state=" + escape(state);

    // Open a connection to the server
    xmlHttp.open("GET", url, true);

    // Setup a function for the server to run when it's done
    xmlHttp.onreadystatechange = updatePage;

    // Send the request
    xmlHttp.send(null);
    }

     

    Ajax 코드에 관한 많은 것이 명백하다. Ajax 코드의 첫번째 비트는 몇 가지 양식 필드 값을 포착하는 기본 JavaScript 코드를 사용한다. 그런 다음 이 코드에서는 연결 최종 목적지로 PHP 스크립트를 설정한다.

    PHP 스크립트의 URL을 지정한 다음(양식에서 나온) 단순한 GET 매개변수를 이용해 이 URL에 도시 및 국가를 추가한다. 그 다음 연결하면 먼저 XMLHttpRequest 객체가 작동되는 것을 보게 된다. 연결방법은 연결 URL 뿐만 아니라, GET 매개변수에도 나와 있다. 최종 매개변수를 true로 설정한 경우, 이 매개변수에선 비동기식 연결(Ajax를 만든다.)을 요구한다. false로 설정한 경우엔 Request를 만들 시 서버 상에서 Ajax에서의 JavaScript 코드가 대기하고 응답을 받을 때 코드가 지속된다. 사용자는 최종 매개변수를 true로 설정하면서 서버에서 배경에 있는 Request를 처리하는 동안 사용자는 웹 양식(심지어는 기타 JavaScript 방식)을 여전히 사용한다.

    한편 xmlHttp(이것은 XMLHttpRequest 객체의 인스턴스라는 사실을 기억하라.)의 onreadystatechange 속성으로 서버 실행이 종료될 시(5분/5시간 내에 종료될 수 있음) 서버 기능을 명령한다. 이 코드는 서버 상에서 대기하지 않기 때문에 서버가 기능을 인식해 서버에 응답할 수 있도록 하는 게 필요하다. 이 경우 서버에서 Request를 처리하면서 종료 시 이른바 updatePage()라 불리는 특수 방법을 트리거한다.

    최종적으로 send() 코드를 0(null) 값으로 호출한다. 데이터를 추가해 이를 서버에 전송하므로 Request에는 추가해서 보낼 게 없다. 이렇게 되면 Request를 발송하고 서버는 서버에 요구된 기능을 실행한다.

    이 코드에서 나오는 것이 없는 경우, 코드가 상당히 간단하다는 것을 명심하라. 이 코드는 Ajax 애플리케이션의 비동기적 특성을 제외하고는 상당히 단순하다. 이 코드를 통해 복잡한 HTTP Request/응답 코드보다는 근사한 애플리케이션 및 인터페이스에 완전 초점을 맞추도록 한다는 사실을 여러분은 높게 평가할 것이다.

    Listing 5의 코드는 코드를 얻는 방법만큼이나 쉽다. 데이터는 단순 텍스트이고 Request URL의 일부로 포함된다. GET 매개변수는 더 복잡한 POST대신 Request를 전송한다. 여기에 덧붙일 XML/컨텐츠 헤더가 없고 Request 본체에 전송할 데이터도 없다. 이게 바로 Ajax 유토피아다.

    그렇다고 미리 겁먹지 마라. 시리즈가 계속될수록 문제는 더 복잡해진다. 그 때는 POST Request를 전송하는 방법, Request 헤더 및 컨텐츠 형식을 설정하는 방법, 메시지에 XML을 설정하는 방법 및 Request에 보안기능을 추가하는 방법을 배우게 되는데 배우는 목록만 해도 상당히 길다! 지금은 이런 어려운 주제에 대해 신경 쓰지 말자! 그냥 기본만 충실하게 익히면 Ajax 전체 툴을 구축하게 된다

     

     

    응답 취급과정

     

    이제 서버 응답을 실지로 취급해야 한다. 이 시점에서는 정말로 두 가지 사항만 알면 된다.

  • xmlHttp.readyState 속성이 4와 같을 때까지는 어떤 작업도 해선 안 된다.
  • 서버는 xmlHttp.responseText 속성에 응답한다.

    2가지 항목 중 첫번째 항목인 준비 상태에 관해선 다음 글에서 대부분 다룰 것이다. 그 때는 HTTP Request 단계에 대해 알고 싶은 것 이상으로 배우게 된다. 지금 현재로선, xmlHttp.responseText 속성 값 4를 단순 점검하는 경우, 작업이 계속 진행된다.(다음 글에서 기대할 만한 사항이 나오게 된다.) 서버 응답을 얻기 위해 xmlHttp.readyState 속성을 사용하는 과정인 두 번째 항목은 쉽다. Listing 6은 Listing 5에서 전송된 값에 근거해 서버에서 호출하는 방법에 관한 예를 보여준다.

     

    Listing 6. 서버 응답 취급하기

    function updatePage() {
    if (xmlHttp.readyState == 4) {
    var response = xmlHttp.responseText;
    document.getElementById("zipCode").value = response;
    }
    }

     

    다시 보면, xmlHttp.readyState 코드는 그리 어렵거나 복잡하지 않다. 이 코드는 서버에서 해당 준비 상태로의 호출을 대기하고 서버에서 다시 복귀되는 값(이 경우, 사용자 기입 도시 및 국가에 대한 ZIP 코드)을 사용해 또 다른 형태의 양식 필드를 설정한다. 그 결과, zipCode 필드는 ZIP 코드와 함께 갑자기 나타난다. 하지만 사용자는 버튼을 클릭해서는 안 된다! 그게 바로 이전에 말했던 데스크톱 애플리케이션이다. Ajax 코드에는 응답성, 동적 상태 외의 더 많은 것이 있다. 독자들은 zipCode가 정상 텍스트 필드라는 것을 눈치챘을지도 모른다.

    일단 서버에서 zipCode를 복귀시키고 updatePage() 방식으로 도시/국가 ZIP 코드와 함께 zipCode 필드 값을 설정하는 경우 사용자는 값을 무효로 한다. 값을 무효로 하는 데는 두 가지 이유가 있다. 예에서 나오는 상황을 단순화시키고, 때로는 사용자가 서버에서 명령하는 것을 무효로 하기 위해서다. 이 두 가지를 명심하라. 좋은 사용자-인터페이스 설계를 위해 중요하다.

     

     

    웹 양식 다루기

     

    그러면 이 글에서 다룰 게 남아 있는가? 그다지 많지 않다. 양식에 기입할 정보를 포착해 이를 서버에 전송하고 응답에 관해 취급할 또 다른 JavaScript 방법을 제공하면서 심지어는 다시 응답될 때 필드 값을 설정하기까지 하는 JavaScript 방법을 다룬다. 여기서는 첫번째 JavaScript 방법을 호출해 전 과정을 시작하기만 하면 된다. 분명 HTTL 양식에 버튼을 추가하지만 2001년 버전과 거의 동일하다고 생각되지 않는가? Listing 7과 같이 JavaScript 기술을 활용한다.

     

    Listing 7. Ajax 프로세스 시작

    <form>
    <p>City: <input type="text" name="city" id="city" size="25"
    onChange="callServer();" /></p>
    <p>State: <input type="text" name="state" id="state" size="25"
    onChange="callServer();" /></p>
    <p>Zip Code: <input type="text" name="zipCode" id="zipCode" size="5" /></p>
    </form>

     

    이런 단면이 루틴 코드의 한 단면 이상을 보여준다고 생각된다면 맞는 말이다. ? 그렇다! 사용자가 도시/국가 필드에 관한 새로운 값을 입력할 경우 callServer() 방식을 전송한 다음 Ajax 애플리케이션이 시작된다. 이제 여러 상황을 다룰 만하다고 느껴지기 시작하는가? 좋다! 바로 그거다!

     

     

    맺음말

     

    이 시점에서 적어도 리소스 란에서 Ajax 애플리케이션에 관해 깊숙이 알려고 하는 경우, 첫번째 Ajax 애플리케이션을 작성할 준비가 되어 있지 않을 게다. 하지만 이런 애플리케이션이 작동하는 기본 개념 및 XMLHttpRequest 객체의 기본 개념을 이해하기 시작한 경우 이 객체, JavaScript-서버 간 대화 취급방식, HTML 양식 취급 및 심지어 DOM 관리 방식까지 모든 것을 배워야 한다.

    지금 현재로선, Ajax 애플리케이션이 얼마나 강력한 툴인지 생각하는 데 시간을 보낸다. 버튼만 클릭할 뿐만 아니라 필드에 입력하고 콤보 상자에서 옵션을 선택하고 심지어는 마우스를 스크린 주위에 끄는 경우 응답하는 웹 형식을 상상해 본다. 비동기식의 정확한 의미 및 Request 상에서 응답하기 위해 서버 상에서 실행하지만 대기하지 않는 JavaScript 코드에 관해 생각해 본다. 여러분이 부딪치는 문제의 종류는 어떤 것인가? 어떤 영역의 문제에 주의를 기울일 것인가? 프로그래밍에 이 새로운 접근방식을 설명하기 위해 양식 설계를 변환하는 방법은 어떤 것인가?

    이런 문제에 관해 실지로 생각할 시간을 보낸다면 잘라 붙이는 코드를 가지고 이를 잘 이해하지 못하는 애플리케이션에 포함시키는 것보다는 훨씬 더 낫다. 다음 글에서는 이와 같은 개념을 실제 작업에 응용해 본 작업에서처럼 애플리케이션을 만들어야 하는 코드에 관한 자세한 정보를 제공하기로 한다. 그 때까지 Ajax 애플리케이션의 가능성을 마음껏 즐겨라.

     

     

    참고자료

    교육
    - Adaptive Path
    - Jesse James Garrett, Ajax.
    - XMLHttpRequest object.
    - Microsoft Developer Network's XML Developer Center.
    - 자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현 (developerWorks, September 2005)
    - 자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화 (developerWorks, October 2005)
    - Using Ajax with PHP and Sajax (developerWorks, October 2005)
    - Call SOAP Web services with AJAX, Part 1: Build the Web services client (developerWorks, October 2005)
    - XML Matters: Beyond the DOM (developerWorks, May 2005)
    - Build apps with Asynchronous JavaScript with XML, or AJAX (developerWorks, November 2005)
    - Ajax for Java developers: Ajax with Direct Web Remoting (developerWorks, November 2005)
    - surveys AJAX/JavaScript libraries.
    - XUL Planet's object reference section details XMLHttpRequest
    - strategy white paper
    - Flickr.com.
    - GMail
    - Head Rush Ajax (O'Reilly Media, Inc., February 2006)
    - JavaScript: The Definitive Guide, 4th Edition (O'Reilly Media, Inc., November 2001)
    - developerWorks Web Architecture zone

    토론
    -포럼에 참여하기.
    -Ajax.NET Professional
    -developerWorks blogs.

     

    사용자 삽입 이미지



    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3052


     

    대부분의 웹 애플리케이션들은 서버에서 전체 HTML 페이지를 얻는 요청/응답 모델을 사용합니다. 다시 말해서, 이 모델은 버튼을 클릭하고, 서버를 기다리고, 또 다른 버튼을 클릭하고, 다시 기다리는 일이 다반사입니다. Ajax와 XMLHttpRequest 객체를 사용하면 서버 응답을 기다리지 않아도 되는 요청/응답 모델을 사용할 수 있습니다.

     

    지난 글(참고자료)에서는 Ajax 애플리케이션에 관한 서론 및 이 애플리케이션에 필요한 몇 가지 기본개념에 대해 알아봤다. 본 글에서는 JavaScript, HTML 및 XHTML, 동적 HTML, 심지어는 몇 가지 DOM(동적 객체 모델) 등 이미 알고 있는 수많은 기술에 대해 중점적으로 다뤘다.

    본 글에서는 모든 Ajax관련 객체 및 프로그래밍 방식의 기초인 XMLHttpRequest 객체에 대해 먼저 다룰 것이다. 이 객체는 모든 Ajax 애플리케이션 전반에 걸쳐 유일한 공통 줄기가 된다. 예상하다시피, XMLHttpRequest 객체를 완전히 이해해서 프로그래밍의 한계에 다다르고자 할 것이다. 사실, XMLHttpRequest 객체를 적절히 이용해도 분명 그 객체를 사용하지 못하는 경우가 있다. 도대체 XMLHttpRequest 객체는 무엇일까?

     

     

    Web 2.0

     

    먼저 코드에 관해 자세히 알아보기 전에 Web 2.0에 관한 개요를 살펴 보면서 확실한 개념을 얻도록 하자. Web 2.0이라는 용어를 들을 때 다음과 같이 " Web 1.0은 무엇입니까?" 라고 물어봐야 한다. Web 1.0에 대해선 거의 들어보지 못했지만 명료한 요청 및 응답 모델이 포함된 전통 웹을 가리켜 Web 1.0이라 한다. 예를 들어 Amazon.com으로 들어가서 버튼을 클릭하거나 탐색 용어를 입력하면 서버에 요청을 생성하고 이에 대한 응답이 브라우저로 다시 보낸다. 그 요청은 책, 타이틀 목록 이상으로 중요하며 실지로 또 다른 완전 HTML 페이지를 만들어낸다. 그 결과 새로운 HTML 페이지가 웹 브라우저 스크린에 다시 나타날 때 플래시/플리커링 현상이 나타나기도 한다. 사실, 각각의 새로운 페이지에서 나오는 요청, 응답을 분명히 알게 된다.

    Web 2.0은 이와 같은 왕복이동 움직임이 상당부분 필요 없다. 예를 들어, Google Maps 또는 Flickr(참고자료)를 방문하면 Google Maps 상에서는 맵을 끌어다가 재 드로잉을 약간만 해도 맵이 축소, 확대된다. 물론, 요청 및 응답은 상상을 초월할 정도로 계속 이루어진다. 이로 인해 사용자로서의 경험은 훨씬 짜릿하며 데스크톱 애플리케이션 상에 있는 것과 같이 느껴진다. 이런 새로운 느낌, 패러다임은 누군가가 Web 2.0에 대해 언급할 때 나오는 현상들이다.

    이와 같이 새로운 상호작용이 가능하도록 하는 방법에 대해 주의를 기울여야 한다. 분명 요청 및 필드 응답을 생성하지만 이로 인해 매 순간 요청/응답 상호작용에 관한 HTML 재 드로잉이 발생돼 느리고 볼품없는 웹 인터페이스를 생성하게 된다. 따라서 사용자가 요청을 생성하고 전반적인 HTML 페이지보다는 필요한 데이터만 포함하는 응답을 수신하는 방식이 필요하다. 사용자가 새로운 페이지를 보고자 할 때가 완전히 새로운 HTML을 얻는 유일한 경우다.

    하지만 대부분의 상호작용으로 인해 상세사항 추가/본문 텍스트 변환/기존 페이지에 데이터 겹쳐쓰기 등이 발생한다. 모든 경우, Ajax 및 Web 2.0방식으로 전체 HTML 페이지를 업데이트하지 않고 데이터를 전송, 수신한다. 이런 기능으로 임의의 수많은 웹 서퍼들은 애플리케이션의 속도가 빨라지고 응답성이 증가하는 것으로 느끼게 되며 상호작용이 반복적으로 이루어지게 된다.

     

     

    XMLHttpRequest

     

    이렇게 새롭고 놀라운 현상이 실지로 발생하기 위해선 XMLHttpRequest라 하는 JavaScript 객체에 관해 완전 익숙해져야 한다. 오랜 시간 동안 몇몇 브라우저에서 사용된 이 객체는 Web 2.0, Ajax 및 앞으로 이 글에서 배우게 될 기타 사항을 이해하는 데 있어 중요한 역할을 하게 된다. 실지로 빠른 이해를 위해 이 객체에서 사용되는 방법 및 속성에 대해 알아보자.

  • open(): 새로운 요청을 서버에 설정함.
  • send(): 요청을 서버에 전송함.
  • abort(): 현 요청에서 벗어남.
  • readyState: 현 HTML 준비상태를 제공함.
  • responseText: 요청에 응답하기 위해 서버에서 재전송하는 텍스트.

    위의 모든 명령을 다 이해하지 못하더라도(중요한 것을 이해하지 못한다 하더라도) 걱정하지 마라. 다음 글에서 각 명령에 대한 방법 및 속성에 관해 배우게 된다. 여기서는 XMLHttpRequest와 관련된 좋은 아이디어를 얻는 게 필요하다.여기서, 각 방법 및 속성은 요청 전송 및 응답 처리와 연관된다는 것을 명심하라. 사실, XMLHttpRequest 객체에 관한 방법, 속성을 다는 알지 못하기 때문에 이들이 매우 간단한 요청/응답 모델과 연관 있다는 것도 모르게 된다. 그래서 놀랍고도 새로운 GUI 객체, 또는 사용자 상호작용을 생성하는 흥미로운 몇 가지 방식 등에 관해서도 배우지 않는다. 별로 재미가 없는 것 같지만 XMLHttpRequest 객체 하나만 잘 사용해도 완전 애플리케이션을 변경할 수 있다.

     

     

    단순함

     

    우선, 새로운 변수를 생성한 다음 이를 XMLHttpRequest객체 인스턴스에 할당한다. JavaScript 상에서는 상당히 간단한 작업이다. 여기서 Listing 1에 보다시피, 객체 이름과 같이 new 키워드를 사용하면 된다.

     

    Listing 1. 새로운 XMLHttpRequest 객체 형성

    <script language="javascript" type="text/javascript">
    var request = new XMLHttpRequest();
    </script>

     

    새로운 객체 형성과정이 그다지 어려운 일은 아니지 않는가? JavaScript에서는 변수 상에 입력하는 과정이 필요 없어 Listing 2(자바에서 XMLHttpRequest 객체를 생성하는 과정)와 같이 값을 전혀 입력할 필요가 없다.

     

    Listing 2. XMLHttpRequest 객체를 생성하기 위한 자바 유사-코드

    XMLHttpRequest request = new XMLHttpRequest();

     

    따라서 JavaScript에서 var로 변수를 생성해 변수에 명칭("request" 등)을 부여한 다음 이를 XMLHttpRequest 객체의 새로운 인스턴스에 할당한다. 이 시점에서 XMLHttpRequest 객체를 사용할 준비가 된 것이다.

     

     

    에러 처리과정

     

    실제 세계에서, 에러가 발생할 수 있어 에러 발생코드는 에러 처리기능을 제공하지 않는다. 따라서 XMLHttpRequest를 생성한 다음 에러가 발생한 경우 이 객체의 기능을 점차 저하시킨다. 일례로, XMLHttpRequest객체를 지원하지 않는 구 브라우저들(믿건 말건, 사람들은 Netscape Navigator의 구 버전을 여전히 이용한다.)이 많아 사용자는 어디서 에러가 났는지 알 필요가 있다. Listing 3은 에러가 난 경우 XMLHttpRequest 객체를 생성하는 방식에 대해 나와 있다. 여기서 XMLHttpRequest 객체로 JavaScript 경고가 발생한다.

     

    Listing 3. 에러 처리기능으로 XMLHttpRequest 객체 생성

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (failed) {
    request = false;
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    </script>

     

    여기서 다음의 각 단계를 반드시 이해한다.

    1.request라는 새 변수를 생성한 다음 이를 거짓으로 설정한다. XMLHttpRequest 객체가 아직 생성되지 않은 상태에서 거짓 값으로 설정한다.
    2. try/catch 블록에서 추가로 다음과 같은 작업을 한다.

    1. XMLHttpRequest 객체를 시험한 다음 생성한다.
    2. 1번 과정이 실패한 경우(catch (failed)), request가 여전히 거짓으로 설정되어 있는지 확인한다.

    3. request가 여전히 거짓으로 설정되어 있는지 확인한다. (에러가 없는 경우, 거짓으로 설정되지 않는다.)
    4. 에러가 발생한 경우(request가 거짓인 경우), JavaScript 경고를 사용해 문제가 발생했다는 사실을 사용자에게 알린다.

    이런 작업은 상당히 간단하다. 실제로 대부분의 JavaScript 및 웹 개발자들은 객체를 읽고 작성하는 것보다는 이해하는 게 더 빠르다. 이제, XMLHttpRequest 객체를 생성하는 일부 에러-증명 코드가 생성되어 에러 여부를 알게 된다.

     

     

    Microsoft로 처리하기

     

    적어도 인터넷 상에서 이 코드를 적용하기 전까지는 이와 같은 작업이 무난하다. 이 코드를 적용하면 그림 1과 같이 에러가 나오게 된다.

    사용자 삽입 이미지


    그림1. 에러화면

    분명, 에러가 발생하고 있다. Internet Explorer는 구식 브라우저가 아니며, 전 세계의 70% 정도가 사용하는 툴이다. 즉, Microsoft 및 Internet Explorer를 지원하지 않는 한 웹 상에서 잘 운영하지 못하게 된다. 따라서 Microsoft 브라우저를 다룰 다른 방식이 필요하다.

    Microsoft는 Ajax를 지원하지만 이전과 다른 XMLHttpRequest 버전을 호출하며 사실은 여러 다른 버전을 호출한다. Internet Explorer의 새로운 버전을 사용하는 경우, Msxml2.XMLHTTP 라 하는 객체를 사용해야 한다. Internet Explorer의 구 버전에서는 Microsoft.XMLHTTP 객체를 사용한다. 그러므로 이와 같은 두 가지 객체 형태를 지원해야 한다. (비-Microsoft 브라우저에 대한 지원기능을 손실하지 않은 상태에서.) 이미 언급한 코드에 Microsoft 지원기능을 추가한 Listing 4를 참조하라.

     

    Microsoft가 잘 작동되는가?
    Ajax에 관해 쓴 글이 많고 Microsoft는 이 영역에 있어 점점 더 관심을 기울이고 있다. 사실 2006년 말에 출시될 것으로 예정된 Microsoft사의 Internet Explorer 최신버전인 버전 7.0은 XMLHttpRequest 객체를 직접 지원해 모든 Msxml2.XMLHTTP 생성코드 대신 new 키워드를 사용한다. 하지만 너무 빠져 들지 마라. 아직도 구 브라우저를 지원해야 하므로 크로스-브라우저 코드는 곧장 사라지지는 않을 전망이다.

     

    Listing 4. Microsoft 브라우저에 지원기능 추가

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    </script>

     

    사실 브라우저에 대한 지원기능이 손실되기 쉽다. 따라서 다음과 같이 단계별로 하길 권한다.

    1. request 명의 새 변수를 생성한 다음 이를 거짓으로 설정한다. XMLHttpRequest 객체가 아직 생성되지 않았다는 전제 하에 거짓으로 설정한다.
    2. try/catch 블록에서 추가로 다음과 같은 작업을 한다.

    1. XMLHttpRequest 객체를 시험한 다음 생성한다.
    2. 1번 과정이 실패한 경우 (catch (trymicrosoft)):
      1. 새로운 Microsoft 버전 (Msxml2.XMLHTTP)을 이용해 Microsoft 호환성 객체를 시험한 다음 생성한다.
      2. 전 과정이 실패한 경우(catch (othermicrosoft)), 이전 Microsoft 버전(Microsoft.XMLHTTP)을 이용해 Microsoft 호환성 객체를 시험한 다음 생성한다.
    3. 그래도 실패한 경우(catch (failed))에는, request가 여전히 거짓으로 설정되어 있는지 확인한다.

    3. request가 여전히 거짓으로 설정되어 있는지 다시 확인한다. (에러가 나지 않는 경우 거짓으로 설정되지 않는다.)
    4. 그래도 문제가 발생한 경우(request가 거짓인 경우), JavaScript 경고를 사용해 사용자에게 문제가 발생했다는 것을 알린다.

    코드를 변화시키고 Internet Explorer 상에서 다시 한 번 시도해 보면 에러 메시지 없이 생성한 형태를 보게 된다. 본인의 경우엔 그와 같은 시도가 그림 2와 같은 것으로 나타난다

    사용자 삽입 이미지


    그림 2. 정상적으로 작동하는 Internet Explorer

     

     

    동적/정적

     

    Listing 1, 3, 4를 다시 보면 모든 코드는 script 태그 내에 직접 포함되어 있다는 것을 알게 된다. JavaScript가 그와 같이 코드화되고 메소드/기능 본체 내에 들어가지 않은 경우, 이를 정적 JavaScript라 한다. 이는 페이지가 스크린 상에 나타나기 전 코드를 실행했다는 것을 의미한다.(코드 및 브라우저가 따로 실행될 경우, 사양과는 100% 일치하지 않지만 사용자와 페이지가 상호작용하기 전, 코드를 실행했다는 건 확실하다.) 일반적으로 그렇게 해서 대부분의 Ajax 프로그래머가 XMLHttpRequest 객체를 생성한다.

    즉, Listing 5처럼, 메소드에 이와 같은 코드를 첨가한다.

     

    Listing 5. XMLHttpRequest 생성코드를 메소드로 이동하기

    <script language="javascript" type="text/javascript">

    var request;

    function createRequest() {
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    }
    </script>

     

    이와 같이 코드를 설정하면, Ajax 작업을 하기 전 이와 같은 메소드를 호출해야 한다. 그럴 경우 Listing 6과 같은 것을 얻을 수도 있다.

     

    Listing 6. XMLHttpRequest 생성 메소드 사용

    <script language="javascript" type="text/javascript">

    var request;

    function createRequest() {
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    }

    function getCustomerInfo() {
    createRequest();
    // Do something with the request variable
    }
    </script>

     

    Listing 6을 활용하면 에러 통지기능을 지연시키므로 대부분의 Ajax 프로그래머들은 위의 방법을 활용하지 않는다. 10/15 필드가 있는 복잡한 형태에 선택상자 등등이 있다고 상상해 보면 사용자가 필드 14에 있는 텍스트를 형식에 나온 대로 기입할 때 몇 가지 Ajax 코드를 전송한다. 이 시점에서 getCustomerInfo()를 실행해 XMLHttpRequest 객체를 생성하려 했지만 실패한다. (이 예에서) 그러면 사용자에게 이 애플리케이션을 사용할 수 없다는 것을 경고로 알리게 된다 (많은 경우). 하지만 사용자는 이미 형식 상에서 데이터를 기입하느라 시간을 보냈다. 상당히 짜증을 내게 되면서 사용자는 결국엔 사이트로 관심을 기울이지 않게 된다.

    정적 JavaScript를 사용하는 경우, 사용자는 페이지에 에러가 나자마자 에러를 포착하게 된다. 또 짜증나는가? 아마도 사용자로선 웹 애플리케이션이 브라우저 상에서 작동되지 않을 때 상당히 죽을 맛일 게다. 하지만, 10분 동안 정보를 기입한 뒤 동일한 에러가 나오는 것보다는 확실히 낫다. 따라서 정적으로 코드를 설정하고 난 다음 발생할 수 있는 문제에 대해 사용자가 조기에 알도록 하는 게 중요하다고 본다.

     

     

    XMLHttpRequest로 요청 전송하기

     

    요청 객체가 있으면 요청/응답 사이클을 시작한다. 여기서 요청을 생성한 다음 응답을 수신하는 게 XMLHttpRequest 객체에서 이루고자 하는 유일한 것임을 명심하라. 사용자 인터페이스 변환, 이미지 교환 및 서버에서 재전송하는 데이터 해석 등의 작업은 페이지에 있는 JavaScript, CSS 또는 기타 코드에서 일어나는 현상이다. XMLHttpRequest 객체가 사용 대기 중일 때 서버에 요청을 생성하게 된다.

     

     

    샌드박스

     

    Ajax는 샌드박스 보안 모델이 포함되어 있다. 그 결과 Ajax 코드(특히 XMLHttpRequest 객체)는 실행 중인 동일한 도메인에만 요청을 생성한다. 다음 글에서 보안 및 Ajax에 관해 더 많은 것을 배우게 되겠지만 지금으로선 로컬 머신 상에서 작동하는 코드만으로도 로컬 머신 상의 서버측 스크립트에 요청을 생성한다는 것을 알게 된다. www.breakneckpizza.com상에서 Ajax 코드를 실행하는 경우, www.breakneckpizza.com상에서 실행하는 스크립트에 관한 요청을 생성한다.

     

     

    서버 URL 설정

     

    여기서 우선 결정할 것은 연결할 서버의 URL이다. URL은 Ajax에서만 있는 것은 아니다. 분명URL을 구성하는 방법에 대해 알아야 한다. 하지만 URL은 연결 설정 시 여전히 필수적인 것이다. 대부분의 애플리케이션에서 사용자가 다루는 형식에서 나온 데이터와 정적 데이터 세트를 결합해 URL을 구성한다. 예를 들어 Listing 7에서는 전화번호 필드의 값을 알아내고 그 데이터를 이용해 URL을 구성하는 JavaScript에 관해 나와 있다.

     

    Listing 7. 요청 URL 구축

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    }
    </script>

     

    여기서 딴지를 걸만한 게 없다. 먼저 여기 나온 코드는 phone 이라는 이름의 새로운 변수를 생성, 이를 "phone"의 ID로 형식 필드 값을 지정한다. Listing 8에는 phone 필드 및 id 속성에서 알 수 있는 특수 형태에 관한 XHTML에 관해 나와 있다.

     

    Listing 8. Break Neck Pizza 형식

    <body>
    <p><img src="breakneck-logo_4c.gif" alt="Break Neck Pizza" /></p>
    <form action="POST">
    <p>Enter your phone number:
    <input type="text" size="14" name="phone" id="phone"
    onChange="getCustomerInfo();" />
    </p>
    <p>Your order will be delivered to:</p>
    <div id="address"></div>
    <p>Type your order in here:</p>
    <p><textarea name="order" rows="6" cols="50" id="order"></textarea></p>
    <p><input type="submit" value="Order Pizza" id="submit" /></p>
    </form>
    </body>

     

    사용자가 전화번호를 입력/변경하는 경우, Listing 8에서 보는 대로 getCustomerInfo() 메소드가 나온다는 사실을 알아둔다. 이 방법으로 전화번호를 알아낸 다음 url 변수에 저장된 URL 문자열을 구성하는 데 활용한다. Ajax 코드는 묶여져 있고 동일한 도메인에만 연결되기 때문에 URL에서 도메인 명칭이 필요 없다는 사실을 명심해야 한다. 이 예에서 스크립트 명칭은 /cgi-local/lookupCustomer.php다. 결국 전화 번호는 상기 스트립트에 Get 매개변수로서 추가된다. ("phone=" + escape(phone))

    이전에 escape() 메소드를 알지 못한 경우, 이 메소드는 정확히 명백한 텍스트로 전송될 수 없는 문자로부터 벗어나는 데 사용된다. 예를 들어, 전화번호에서의 임의의 공간은 %20 문자로 바뀌며 이로 인해 URL과 같이 문자를 전송할 수 있게 된다.

    그런 다음 필요한 많은 매개변수를 추가한다. 예를 들어 또 다른 매개변수를 추가하고자 한다면 URL 상에 추가해 여러 매개변수를 ampersand(&) 문자로 분리시킨다. (첫 번째 매개변수는 의문부호(?)로 스크립트 명칭으로부터 분리되어 있다.)

     

     

    요청 열기

     

    URL이 연결된 상태에서 XMLHttpRequest 객체 상의 open() 메소드를 사용해 요청을 구성한다. 이 메소드는 5가지 매개변수가 있다.

  • request-type: 전송 요청 형태. GET/POST가 일반적인 값이고 HEAD 요청도 전송함.
  • url: 연결된 URL.
  • asynch: 비동기 요청을 설정할 경우 참값, 동기식 요청인 경우에는 거짓임. 이 매개변수는 옵션이고 기본값이 참값임.
  • username: 사용인증을 요구할 경우 사용자이름을 지정한다. 옵션 매개변수고 기본값이 없다.
    password: 사용인증을 요구할 경우 암호를 지정한다, 옵션 매개변수고 기본값이 없다.

    일반적으로 5개의 매개변수 중 3개의 첫 매개변수만 사용한다. 사실, 비동기식 요청을 원할 경우, 제3의 매개변수로 "true"을 설정한다. 그게 기본값 설정이다. 하지만 훌륭한 자체 문서화 작업으로 이 작업을 통해 항상 요청이 비동기식인지 아닌지 여부를 알 수 있다.

    기본값 설정을 완료한 다음 일반적으로 Listing 9와 비슷한 라인으로 작업을 완료한다.

     

    open() 메소드가 열릴까?
    인터넷 개발자들은 open() 메소드의 정확한 기능에 대해 서로 의견이 다르다. 실제로 이 메소드에 없는 기능은 요청 열기 기능이다. 네트워크 및 XHYML/Ajax 페이지와 연결 스크립트 간 데이터 이동을 감시했더라면 open() 메소드 호출 시 트래픽 현상이 발생하지도 않았을 것이다. Open() 명칭이 선택된 이유는 여전히 불분명하지만 분명 훌륭한 명칭선택이라 볼 수는 없다.

     

    Listing 9. 요청 열기

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    }

     

    일단 URL을 이해했으면 그 다음에는 상당히 단순하다. 대부분의 요청의 경우, GET을 사용하는 것만으로도 충분하다. (다음 글에서 POST를 사용하고자 하는 경우를 보게 된다.) URL과 같이 open() 메소드를 사용하기만 하면 된다.

     

     

    비동시성에 대한 문제

     

    이 시리즈의 후반부에서는 비동기식 코드 작성 및 사용에 관한 설명에 할애할 것이다. 하지만 open() 메소드에서 마지막 매개변수가 중요한 이유에 대해 알아야 한다. 정상 요청/응답 모델에서 Web 1.0,을 생각해 보면 클라이언트(로컬 머신 상에서 실행하는 브라우저/코드)는 서버에 요청을 생성한다. 그 요청은 동기식이다. 다시 말하면 클라이언트는 서버로부터의 응답이 올 때까지 대기한다. 클라이언트가 대기 중일 때 일반적으로 적어도 대기 중인 여러 통지 형태 중 하나만 얻으면 된다.

  • Hourglass (Windows 경우에만).
  • 회전 비치볼(일반적으로 Mac 머신에서의 경우임).
  • 애플리케이션은 기본적으로 정지되고 때로 커서가 변환되기도 한다.

    이런 특성으로 웹 애플리케이션은 볼품없거나 느린 것으로 보여진다. 즉 실제 대화성이 부족한 것이다. 버튼을 누르면 트리거된 요청이 응답되기 전까지는 애플리케이션을 사용할 수 없다. 광범위한 서버 처리작업을 요구하는 요청을 생성할 경우 대기시간은 어마어마할 것이다. (적어도 오늘날 멀티 프로세서, DSL, 비대기 세계의 경우처럼.)

    하지만 비동기식 요청은 서버가 응답할 때까지 대기하지 않는다. 요청을 전송한 다음에는 애플리케이션을 계속 실행한다. 사용자는 웹 형식에서 데이터를 기입한 다음 기타 버튼을 클릭하고 형식 기입을 종료한다. 회전하는 비치볼, 소용돌이치는 hourglass 및 대형 애플리케이션 정지 등의 현상이 생기지 않는다. 서버는 재빨리 요청에 응답하고 서버가 종료된 경우, 요청으로 인해 원 요청자는 서버가 종료되었음을 알게 된다. 결국 볼품없고 느린 대신 민감하고 대화성 있고 빠른 애플리케이션을 얻게 된다. 정확한 GUI 구성요소 및 웹 디자인 패러다임만 가지고는 느리고 동기적인 요청/응답 모델의 한계를 극복할 수 없다.

     

     

    요청 전송

     

    일단 open() 메소드로 요청을 구성하고 나면 요청 전송 준비를 한다. 다행히도, 요청을 전송하는 메소드를 open()의 경우에 비해 더 적절하게 명명한다. 명칭은 단순히 send()이다.

    send() 메소드는 단 하나의 매개변수인 전송 컨텐트만 있으면 된다. 그 메소드에 대해 너무 깊게 생각하기 이전에 이미 URL 자체를 통해 데이터를 전송했음을 기억하라.

     

    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);

     

    send() 메소드를 사용해 데이터를 전송하지만 URL자체를 통해서도 된다. 사실, GET 요청(일반 Ajax 이용률의 80%를 이루고 있음.)에서는 URL에서 데이터를 전송하는 게 더 용이하다. 안전한 정보/XML을 전송하기 시작한 경우, send() 메소드를 통한 전송 컨텐트에 대해 알아보려고 할 것이다. (이 시리즈 후반부에 안전한 데이터 및 XML 메시징에 대해 논의한다.) send()를 통해 데이터를 전송하지 않아도 되는 경우, 이 메소드에 대한 인수로 null을 전송하면 된다. 따라서 이 글을 통해 알게 된 예에서 보듯 요청 전송작업을 하는 게 필요하다.(Listing 10)

     

    Listing 10. 요청 전송

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.send(null);
    }

     

     

    콜백 메소드 지정

     

    이 시점에서, 새롭고 혁신적이거나 비동기적이라고 생각될 만한 작업을 거의 하지 못했다. open() 메소드의 키워드 "true"는 비동기식 요청을 설정한다고 하는 게 정확하다. 하지만 그거 말고도 open() 메소드 코드는 Java servlets및 JSP, PHP/Perl이 함께 어우러진 프로그래밍과 유사하다. 그렇다면 Ajax 및 Web 2.0에 담긴 커다란 비밀은 무엇일까? 그 비밀은 onreadystatechange라는 명칭의 XMLHttpRequest의 단순한 속성에서 나오게 된다.

    먼저, open() 코드에서 생성된 과정에 대해 확실히 이해한다.(Listing 10) 요청을 설정하고 생성한다. 게다가 이 XMLHttpRequest는 동기식 요청이라 자바 메소드(예에 나온 getCustomerInfo())는 서버 상에서 대기하지 않는다. open() 코드는 계속 진행되고 이 경우 자바 메소드는 정지되며 제어기능은 형태로 나오게 된다. 사용자들은 계속 정보를 입력하고 애플리케이션은 서버 상에서 대기하지 않는다.

    이렇게 되면 재미있는 질문이 나오게 된다. 서버가 요청 처리 과정을 완료할 시 발생하는 현상은 어떤 것인가? 적어도 코드가 지금 당장 유지되는 한은 아무 현상도 없다 라는 말이 정답이다. 분명 좋은 현상은 아니다. 따라서 서버에 XXMLHttpRequest객체에 의해 전송된 요청에 관한 처리과정을 완료할 경우 서버는 몇 가지 형태의 명령어를 포함해야 한다

    이런 상황에서 바로 onreadystatechange 속성이 작용한다. 이 속성으로 콜백 메소드를 지정한다. 콜백 메소드로 서버는 웹 페이지 코드로 다시 호출한다. 그러면서 서버에 어느 정도의 제어 기능이 전달된다. 또한 서버에서 요청을 종료할 때 콜백 메소드는 XMLHttpRequest 객체, 특히 onreadystatechange 속성에서 나타난다. 그 속성에서 지정된 방법이 어떤 메소드든 모두 호출된다. 웹 페이지 자체에서 벌어지는 현상에 관계없이 웹 페이지로 다시 호출할 때 서버에서 개시하기 때문에 콜백이라 부르는 것이다. 예를 들어, 사용자가 의자에 앉아 키보드를 사용하지 않는 동안 콜백 메소드를 호출하기도 한다. 하지만 사용자가 입력하고 마우스를 움직이고, 화면 이동시키고 버튼을 클릭하는 동안에도 콜백 메소드를 호출하기도 한다. 사용자가 하는 업무는 그다지 중요하지 않다.

    이런 상황에서 비동시성이 작용한다. 사용자는 다른 레벨에 있는 동안 한 레벨에 있는 형식을 작동하고 서버는 요청에 응답한 다음 onreadystatechange 속성에서 명시된 콜백 메소드를 전송한다. 따라서 Listing 11에 나온 대로 코드에 콜백 메소드를 지정해야 한다.

     

    JavaScript에서의 기능 참조
    JavaScript는 약결합 언어며 이 언어에서 모두 다 변수로 참조 가능하다. updatePage()라는 이름의 함수를 선언한 경우, JavaScript는 그 함수 이름을 변수로 취급한다. 즉 updatePage()라는 이름의 변수로 코드에 있는 함수를 참조한다.

     

    Listing 11. 콜백 메소드 설정

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

     

    특히 onreadystatechange 속성이 결정된 코드 위치에 주의를 기울인다. 그 위치는 바로 send()가 호출되기 전의 위치다. 요청을 전송하기 전 onreadystatechange 속성을 설정해야 한다. 그래야만, 서버에서 요청 응답을 종료할 때 onreadystatechange 속성을 탐지하게 된다. 인제는 이 글의 마지막 부분에서 중점적으로 다룰 updatePage() 코드에 대해 알아보겠다.

     

     

    서버 응답 처리

     

    요청을 만들면 사용자는 웹 형식에서 여유롭게 작업하며 (서버에서 요청을 처리하는 동안에는) 서버는 요청 처리과정을 완료한다. 서버는 onreadystatechange 속성에서 나타나며 호출방법을 결정한다. 그런 일이 일어나면 비동기식/동기식 애플리케이션 등의 기타 다른 애플리케이션으로 애플리케이션을 생각할 수도 있다. 즉, 서버에 응답하는 특수 액션 작성 메소드를 취할 필요가 없다. 형식을 변환하고, 사용자를 또 다른 URL에 안내하거나 서버에 응답하는 데 필요한 것들을 하면 된다. 이 단락에서 우리는 서버 응답 및 이에 대한 일반조치 및 사용자가 아는 형식의 일부를 자유롭게 변경하는 것에 대해 중점적으로 다루겠다.

     

     

    콜백 및 Ajax

     

    이미 서버가 종료될 때의 현상을 서버가 인식하는 방법에 대해 이미 알았다. 일단 XMLHttpRequest 객체의 onreadystatechange 속성을 실행함수 이름에 설정한다. 그 다음 서버에서 요청을 처리하면 서버는 자동적으로 그 함수를 호출한다. 또한 콜백 메소드에 있는 임의의 매개변수에 대해 그리 걱정하지 않아도 된다. Listing 12와 같이 단순한 메소드에서 시작하기 때문이다.

     

    Listing 12. 콜백 메소드 코드화

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

    function updatePage() {
    alert("Server is done!");
    }
    </script>

     

    이렇게 하면 간단한 경고가 울리면서 서버가 종료될 때를 알려준다. 자체 페이지에 updatePage() 코드를 시험하고 페이지를 저장한 다음 브라우저에 페이지를 끌어올린다.(이 예에서 XHTML을 원할 경우, Listing 8을 참조한다.) 전화번호를 입력하고 필드를 설정하지 않을 경우 경고는 팝업되어야 한다. 하지만 확인을 클릭한 경우에도 경고는 팝업을 연속한다.

    사용자 삽입 이미지


    그림 3. 경고를 팝업하는 Ajax 코드

    브라우저에 ‘따라 웹 형식에서 경고 팝업을 중지할 때까지 경고가 두 번, 세 번, 심지어는 네 번까지 울린다. 그러면 무슨 일이 벌어지고 있는 것인가? 요청/응답 사이클의 중요 구성요소인 HTTP 준비상태에 대해 고려하지 않았다.

     

     

    HTTP 준비 상태

     

    초기에 필자는 서버에서 요청이 종료되면 XMLHttpRequest의 onreadystatechange 속성에서 호출되는 메소드를 탐지한다고 가르쳤다. 사실, HTTP 준비 상태가 변할 때마다 서버에서는 방금 전에 언급한 메소드를 호출한다. 그러면 그 말이 의미하는 것은 무엇인가? 일단 먼저 HTTP 준비상태에 관해 이해해야 한다.

    HTTP 준비상태는 요청의 상태를 나타내며 주로 요청을 시작했는지, 요청에 응답했는지, 요청/응답 모델을 완성했는지 여부를 결정하는 데 활용된다. HTTP 준비상태는 서버에서 공급되는 모든 응답 텍스트/데이터를 읽어 들이는 데 안전한지 여부를 결정하는 데 도움이 되기도 한다. 여기서 Ajax 애플리케이션에서의 5가지 준비상태에 관해 알아야 한다.

  • 0: 요청이 개시되지 않음.(open()을 호출하기 전)
  • 1: 요청을 설정했지만 전송되지는 않았음.(send()를 호출하기 전)
  • 2: 요청을 설정한 다음 처리 중(이 시점에서 일반적으로 응답에서 나온 컨텐트 헤더를 얻는다.)
  • 3: 요청 처리 중; 종종 응답에서 부분적인 데이터를 사용할 수 있다. 하지만 서버는 자체 응답이 완료되지 않았다.
  • 4: 응답 완료. 서버 응답을 얻은 다음 이를 활용한다.

    거의 모든 크로스-브라우저 이슈에서도 그렇듯 예상치 못한 방식으로 이와 같은 준비 상태를 이용한다. 준비상태는 항상 0~1, 2, 3, 4로 단계적으로 이동한다고 예상할지도 모른다. 하지만 실지로는 그렇지 않다. 0/1상태를 보고하지 않고 곧바로 2로 건너뛰어 3,4까지 가는 브라우저도 있고 모든 상태를 보고하는 브라우저도 있다. 지난 단락에서 보듯, 서버에서는 몇 번이고 updatePage()코드를 호출하고 호출 때마다 경고 상자가 팝업된다. 그건 여러분이 의도하는 바가 아닐 것이다!

    Ajax 프로그래밍의 경우, 직접 다뤄야 할 상태는 오로지 상태 4다. 이는 서버 응답이 완료되었고 응답 데이터를 점검, 사용하는 데 안전하다는 것을 의미한다. 이를 설명하기 위해 콜백 메소드에 나온 첫 번째 라인은 Listing 13에서 나온 바여야 한다.

     

    Listing 13. 준비상태 점검

    function updatePage() {
    if (request.readyState == 4)
    alert("Server is done!");
    }

     

    이런 변환으로 서버가 정말로 그 과정을 종료했는지 확인한다. Ajax 코드의 이 버전을 실행한다. 그러면 한 번에 경고 메시지만을 얻어야 한다.

     

     

    HTTP 상태 코드

     

    Listing 13에서의 코드의 성공에도 불구하고 여전히 문제는 상존한다. 그러면 서버가 요청에 응답하고 요청 처리과정을 완료했지만 에러를 보고한 경우는 어찌 되는가? Ajax, JSP, 정규 HTML 형식 또는 기타 형태의 코드로 서버측 코드를 호출 중인 경우에 서버측 코드를 관찰해야 한다는 점을 주목한다. 웹 세계에서는 HTTP 코드로 요청에서 발생할지도 모르는 여러 가지 상황을 다룬다.

    예를 들어, URL에 관한 요청을 입력했지만, URL을 부정확하게 입력해 404 에러코드가 나와 페이지가 없어졌다고 해보자. 이 코드는 HTTP 요청을 상태로 수신하는 여러 상태 코드 가운데 하나에 지나지 않는다.(참고자료) 403, 401 코드는 둘 다 안전하거나 금지된 데이터 처리를 의미하는 것으로 역시 공통적이다. 각 경우에 있어 이런 코드들은 완전 응답에서 나오는 코드들이다. 즉, 서버는 요청을 수행하지만(HTTP 준비상태는 4임), 클라이언트가 예상한 데이터가 나오지 않을 수도 있다.

    여기서 준비 상태에 덧붙여, HTTP 상태를 점검할 필요가 있다. 단순히 확인을 의미하는 상태코드 200을 탐색하는 중에 있다. 준비상태 4와 상태코드 200인 상태에서 서버 데이터를 처리할 준비가 되어 있고 그 데이터는 반드시 요청된 형태여야 한다. (에러 또는 문제가 있는 정보 단편이 아님.) Listing 14에서 보듯이 콜백 메소드에 또 다른 상태 점검기능을 추가한다.

     

    Listing 14. HTTP 상태 코드 점검

    function updatePage() {
    if (request.readyState == 4)
    if (request.status == 200)
    alert("Server is done!");
    }

     

    복잡성을 줄이고 더 강력한 에러 처리기능을 추가하려면 기타 상태코드에 관한 점검기능/두 가지 기능을 추가할지도 모른다. Listing 15에 있는 updatePage()의 수정 버전을 점검한다.

     

    Listing 15. 간단한 에러 점검기능 추가

    function updatePage() {
    if (request.readyState == 4)
    if (request.status == 200)
    alert("Server is done!");
    else if (request.status == 404)
    alert("Request URL does not exist");
    else
    alert("Error: status code is " + request.status);
    }

     

    이제 getCustomerInfo()에 있는 URL을 비실제 URL로 변환시킨 다음 일어나는 현상을 보면 요청한 URL은 존재하지 않는다는 의미의 경고가 울린다. 이런 경고 가지고도 모든 에러상태를 거의 처리하지 않는다. 하지만 웹 애플리케이션에서 발생할 수 있는 문제의 80%는 해결하는 단순한 진전이 아닐 수 없다.

     

     

    응답 텍스트 읽기

     

    인제 요청을 준비상태를 통해 완전히 처리하고, 서버로 정상적인 확인 응답을 상태 코드를 통해 받았으므로 서버에서 재전송되는 데이터를 최종적으로 처리한다. 이 데이터는 XMLHttpRequest객체의 responseText 속성에 저장된다.

    포맷/길이에 의한 responseText 속성의 텍스트 모양에 관한 상세사항은 이 장에서는 논하지 않기로 한다. 이렇게 되면 서버는 이 텍스트를 실지로 임의로 설정한다. 예를 들어, 한 스크립트로 콤마-분리 값 및 파이프-분리 값이 나오고 또 다른 파이프-분리 값은 텍스트의 긴 문자열로 나올 수도 있다. 이런 현상은 서버에 따라 다르게 된다.

    이 글에서 사용된 예의 경우, 서버는 파이프 기호로 분리된 고객의 마지막 순서 및 주소가 나오게 된다. 형식의 구성요소 값을 설정하는 데 순서 및 고객의 마지막 순서 및 주소를 활용한다. Listing 16은 디스플레이를 업데이트하는 코드에 대해 나와 있다.

     

    Listing 16. 서버 응답 처리

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "");
    } else
    alert("status is " + request.status);
    }
    }

     

    우선 JavaScript split() 메소드를 이용해 파이프 기호 상에서 responseText를 얻고 분할한다. 값은 response의 형태로 배열된다. 고객의 마지막 순서에 관한 첫 번째 값은 response[0] 형태의 배열로 처리되고 "순서" ID와 함께 필드 값으로 설정된다. response[1]에서 두 번째 값은 고객 주소로 처리하는 데 좀 더 오랜 시간이 걸린다. 주소 라인은 정상 라인 분리자("\n" 문자) 로 분리되기 때문에 코드는 정상라인 분리자를 XHTML-형 라인 분리자(< br />)로 바꾸어야 한다. 정규 식 및 replace() 함수의 활용을 통해 분리자를 바꾸는 과정이 이루어진다. 결국 변경 텍스트는 HTML 형태에서 div 의 내부 HTML로 설정된다. 결국 그림 4에도 나오듯이 텍스트 형식은 순식간에 고객정보로 업데이트된다.

    사용자 삽입 이미지


    그림 4. 고객 데이터 검색 후의 Break Neck 형식

     

    이 글을 마치기 전에 XMLHttpRequest 객체의 중요한 속성 중 하나인 responseXML 속성에 대해 언급한다. 이 속성은 서버가 XML과의 응답을 선택한 경우, XML 응답을 포함한다. (상상이 되는가?) XML 응답 처리는 평범한 텍스트 처리과정과 상당히 다르며, 문장분석 및 문서 객체 모델(DOM)을 포함한다. 다음 글에서는 XML에 대해 다루게 된다. responseXML 은 공통적으로 responseText과 관련된 논의에서 나오기 때문에 언급할 가치가 있는 것이다. 많은 단순 Ajax 애플리케이션의 경우, responseText만 있으면 된다. 하지만 Ajax 애플리케이션을 통해 XML을 처리하는 방법에 대해서도 곧 배우게 된다.

     

     

    맺음말

     

    XMLHttpRequest 객체에 대해서는 인제 좀 지루하게 들릴지도 모른다. 필자는 단일 객체, 특히 간단한 객체에 대한 전반적인 글을 거의 읽지 못했다. 하지만 Ajax를 사용하고 작성하는 각 페이지 및 애플리케이션에서 계속 XMLHttpRequest 객체를 사용하게 된다. 아직도 XMLHttpRequest 객체에 대해 언급되지 않은 것들이 많은 건 사실이다. 다음 글에서는 요청에서 GET 및 POST를 사용하고 서버로부터의 응답 및 요청의 컨텐트 헤더를 설정하고 읽어들이는 방법을 배운다. 그러면 요청을 코드화하고 심지어는 요청/응답 모델에서 XML을 다루는 방법을 배우게 될 것이다.

    좀 더 상세하게 나가면 일반적으로 사용하는 Ajax 툴킷에 관해서도 알게 된다. 이 툴킷은 본 글에서 논의된 상세사항의 대부분을 실지로 요약한 것이다. 한편 툴킷을 손쉽게 이용하는 경우, 낮은 레벨의 상세사항을 코드화하는 이유에 대해 궁금해할 수도 있다. 사실은 애플리케이션 상에서 발생하는 현상을 이해하지 못하는 경우, 애플리케이션에서 일어나는 에러를 이해하는 게 어려워진다.

    따라서, 이와 같은 사항을 간과하거나 지나치면 안 된다. 가변성 툴킷에서 에러가 발생할 경우, 머리를 끄적이면서 e-메일을 보내지 않아도 된다. 직접 XMLHttpRequest 사용법을 이해하면 가장 이상한 문제를 디버그하고 수정하는 것도 쉬워진다. 툴킷에 집중하면서 모든 문제를 해결하지 않는 한 툴킷은 그런대로 괜찮다.

    따라서, XMLHttpRequest 객체에 대해 친숙해져라. 사실, 툴킷을 사용하는 Ajax 코드를 실행할 경우 XMLHttpRequest 객체 및 속성, 메소드를 사용해Ajax 코드를 재작성한다. 상당히 좋은 연습이 될 것이며 현재 이 객체에서 벌어지는 현상에 대해 더 잘 이해하게 될 것이다.

    다음 글에서는 XMLHttpRequest에 대해 좀 더 자세하게 들어간다. 이 객체에서 어려운 속성(responseXML등의), POST 요청 사용법 및 몇 가지 다른 포맷에서의 데이터를 전송하는 방법을 조사할 것이다. 한 달 동안 코드화 작업을 시작해 코드를 다시 점검한다.

     

    참고자료

    교육
    - Ajax 마스터, Part 1: Ajax 소개 (developerWorks, December 2005)
    - 자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현 (developerWorks, September 2005)
    - 자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화 (developerWorks, October 2005)
    - Call SOAP Web services with Ajax (developerWorks, October 2005)
    - Google GMail
    - Flickr
    - Ajax: A New Approach to Web Applications
    - Why Ajax Matters Now
    - Microsoft Developer Network's XML Developer Center.
    - online documentation.
    - HTTP status codes
    - developerWorks Web Architecture zone

    제품 및 기술 얻기
    - Head Rush Ajax by Elisabeth Freeman, Eric Freeman, and Brett McLaughlin (February 2006, O'Reilly Media, Inc.)
    - Java and XML, Second Edition by Brett McLaughlin (August 2001, O'Reilly Media, Inc.)
    - JavaScript: The Definitive Guide by David Flanagan (November 2001, O'Reilly Media, Inc.)
    - Head First HTML with CSS & XHTML by Elizabeth and Eric Freeman (December 2005, O'Reilly Media, Inc.)

    토론
    -포럼에 참여하기.
    -developerWorks blogs.

     

     

    사용자 삽입 이미지



    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3054


     

    많은 웹 개발자들에게 간단한 요청을 만들고 간단한 응답을 받는 것은 사실 그들이 필요로 하는 전부이다. 하지만 Ajax를 마스터하고자 하는 개발자들에게는 HTTP 상태 코드, 준비 상태, XMLHttpRequest 객체에 대한 완벽한 이해가 필요하다. Brett McLaughlin은 다양한 상태 코드들을 보여주고 브라우저가 이들 각각을 핸들하는 방법을 설명한다. 비교적 덜 사용되는 HTTP 요청에 대해서도 설명한다.

     

    지난 글에서는 , XMLHttpRequest 객체에 대해 구체적으로 소개했다. 이것은 서버측 애플리케이션이나 스크립트에 대한 요청을 핸들하고, 서버측 컴포넌트에서 리턴 데이터를 처리하는 Ajax 애플리케이션의 주요 특징이다. 모든 Ajax 애플리케이션은 XMLHttpRequest 객체를 사용하기 때문에 Ajax 애플리케이션의 작동은 여기에 얼마나 익숙해지냐에 달려있다.

    이번에는 지난 글에서 다루었던 기초를 넘어서 요청 객체의 세 가지 핵심 부분들에 대해 자세히 설명하겠다.

  • HTTP 준비 상태
  • HTTP 상태 코드
  • 요청 유형들

    이들 각각은 요청이라는 배관의 일부로 간주된다. 결국, 작은 상세가 이러한 주제들에 대해 기록된다. 하지만 Ajax 프로그래밍을 염두하고 있다면 준비 상태, 상태 코드, 요청에 익숙해 져야 한다. 애플리케이션에서 무엇인가 잘못되고 있다면 준비 상태, HEAD 요청을 하는 방법, 또는 400 상태 코드가 의미하는 것이 무엇인지를 이해하면 5분의 디버깅으로 끝낼 수 있거나 5시간 동안 좌절과 혼돈 속에서 방황할 수 있다.

    HTTP 준비 상태 먼저 보도록 하자.

     

     

    HTTP 준비 상태

     

    지난 글에서 XMLHttpRequest 객체는 readyState 라는 속성을 갖고 있다고 설명했다. 이 속성은 서버가 요청을 완료하고 콜백 함수가 그 서버에서 온 데이터를 사용하여 웹 폼이나 페이지를 업데이트 하도록 한다. Listing 1은 이것에 대한 예제이다.(참고자료 참조)

     

    Listing 1. 콜백 함수에서 서버의 응답 처리하기

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "< br />");
    } else
    alert("status is " + request.status);
    }
    }

     

    XMLHttpRequest 또는 XMLHttp: 또 다른 이름의 장미
    Microsoft™와 Internet Explorer는 Mozilla, Opera, Safari, 비 Microsoft 계열 브라우저에서 사용되는 XMLHttpRequest 객체 대신 XMLHttp 라는 객체를 사용한다. 단순하게 하기 위해서 이 두 가지 객체 모두 XMLHttpRequest로 칭하기로 한다. 웹을 검색하다 보면 이런 경우가 비일비재 하고 마이크로소프트도 Internet Explorer 7.0의 요청 객체의 이름으로 XMLHttpRequest를 사용하고 있다. ("JavaScript와 Ajax를 이용한 비동기식 요청" 참조)

     

    이것은 전형적인 준비 상태의 사용법이다. "4"라는 숫자에서 짐작하듯 여러 가지 다른 준비 상태들이 있다.(참고자료 참조)

  • 0: (open()을 호출하기 전에는) 요청이 초기화 되지 않는다.
  • 1: (send()를 호출하기 전에는) 요청은 설정은 되지만 보내지지 않는다.
  • 2: 요청이 보내지고 처리 중에 있다. (이 시점에서 응답에서 콘텐트 헤더를 얻을 수 있다.)
  • 3: 요청이 처리 중에 있다. 부분적인 데이터를 응답에서 사용할 수 있지만 서버는 이 응답으로는 종료되지 않는다.
  • 4: 응답이 완료된다. 서버의 응답을 받고 이를 사용한다.

    Ajax 프로그래밍의 기초 이상으로 넘어가고 싶다면 이러한 상태 뿐만 아니라 이들이 언제 발생하고 어떻게 사용하는지에 대해 알아야 한다. 우선, 가장 중요한 것은 어떤 요청 상태가 될 것인지를 배워야 한다. 이는 별로 기분 좋은 일이 아니고 몇 가지 특별한 경우가 포함되어 있다.

     

     

    숨어있는 준비 상태

     

    readyState 0 (readyState == 0)으로 표시되는 첫 번째 준비 상태는 초기화 되지 않은 요청을 나타낸다. 요청 객체에 대해 open()을 호출하면 속성은 1로 설정된다. 대부분 요청을 초기화 하면서 open()을 호출하기 때문에 readyState == 0을 보는 일은 드물다. 더욱이 초기화 되지 않은 준비 상태는 실제 애플리케이션에서는 쓸모 없다.

    Listing 2를 보면 0으로 설정된 준비 상태가 되는 방법을 알 수 있다.

     

    Listing 2. 준비 상태 0

    function getSalesData() {
    // Create a request object
    createRequest();
    alert("Ready state is: " + request.readyState);

    // Setup (initialize) the request
    var url = "/boards/servlet/UpdateBoardSales";
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

     

    이 간단한 예제에서 getSalesData()는 웹 페이지가 요청을 시작하기 위해 호출하는 함수이다. (예를 들어, 버튼이 클릭 될 때.) open()이 호출되기 전에 준비 상태를 체크 해야 한다. 그림 1은 이 애플리케이션을 실행한 결과이다.

    사용자 삽입 이미지


    그림 1. 준비 상태 0

    분명히 이것은 좋지 않다. open()이 호출되지 않았다는 것을 확인해야 한다. 실제 Ajax 프로그래밍에서 이러한 준비 상태의 유일한 사용은 다중 함수들에 같은 XMLHttpRequest 객체를 사용하여 다중 요청을 만드는 경우이다. 그러한 상황에서, 여러분은 요청 객체가 새로운 요청을 만들기 전에 초기화 되지 않은 상태(readyState == 0)에 있다는 것을 확인해야 한다. 이로서 또 다른 함수가 동시에 객체를 사용하는 것을 방지할 수 있다.

     

     

    진행중인 요청의 준비 상태 보기

     

    0 준비 상태 외에 요청 객체는 전형적인 요청 응답에서 또 다른 준비 상태를 경험하게 된다. 그리고 마지막으로는 준비 상태 4로 끝난다. 이 때는 대부분의 콜백 함수에서 if (request.readyState == 4)가 된다. 서버가 완료되고 웹 페이지를 업데이트 하거나 서버에서 받은 데이터를 기반으로 액션을 취하는 시기이다.

    프로세스를 실제로 보는 것은 간단하다. 준비 상태가 4 라면 콜백에서 단순히 코드를 실행시키는 것 대신 콜백이 호출될 때 마다 준비 상태를 출력한다.(Listing 3)

     

    Listing 3. 준비 상태 점검

    function updatePage() {
    // Output the current ready state
    alert("updatePage() called with ready state of " + request.readyState);
    }

     

    0이 4와 같을 때
    다중 JavaScript 함수들이 같은 요청 객체를 사용하는 경우, 그 요청 객체가 사용되고 있지 않다는 것을 확인하기 위해 준비 상태 0을 확인하면 문제가 많아질 수 있다. readyState == 4는 완료된 요청을 나타내기 때문에, 4로 설정된 준비 상태인 채로 사용되지 않은 요청 객체를 종종 보게 된다. abort()이라고 하는 요청 객체를 리셋하는 함수가 있지만 이는 여기에 사용하는 것이 아니다. 다중 함수들을 사용해야 한다면 다중 함수에 객체를 공유하는 것 보다 각 함수용 요청 객체를 생성 및 사용하는 것이 낫다.

     

    이것이 어떻게 실행되는지 확실히 모르겠다면 웹 페이지에서 호출할 함수를 만들고 서버측 컴포넌트로 요청을 보내도록 한다.(Listing 2) 요청을 설정할 때 콜백 함수를 updatePage()로 설정한다. 요청 객체의 onreadystatechange 속성을 updatePage()로 설정한다.

    이 코드는 onreadystatechange가 정확히 무엇을 의미하는지 잘 보여주고 있다. 요청의 준비 상태가 변할 때 마다 updatePage()가 호출되고 경고를 받는다. 그림 2는 호출되는 함수의 샘플이다. 이 경우 준비 상태는 1이다.

    사용자 삽입 이미지


    그림 2. 준비 상태 1

    코드를 직접 실행해 보라. 웹 페이지에 넣고 이벤트 핸들러를 활성화 한다. (버튼을 누르거나, 요청을 실행하기 위해 설정하는 모든 메소드를 사용하라.) 콜백 함수는 여러 번 실행될 것이다. 요청의 준비 상태가 변할 때 마다 각 준비 상태에 대한 경고를 보게 된다. 이는 각 단계를 통해 요청을 따라가는 최상의 방법이다.

     

     

    브라우저 차이

     

    이 프로세스에 대해 기본적인 개념이 쌓였다면 여러 가지 다양한 브라우저에서 웹 페이지로 액세스 해보라. 준비 상태가 처리되는 방식에 차이가 있을 것이다. 예를 들어, Firefox 1.5에서, 준비 상태는 다음과 같다.

    • 1
    • 2
    • 3
    • 4

    요청의 각 단계들이 다 나타나기 때문에 놀랍지도 않다. 하지만 Safari를 사용하여 같은 애플리케이션에 액세스 하면 재미있는 것을 발견하게 된다. 다음은 Safari 2.0.1에서 보게 되는 상태이다.

    • 2
    • 3
    • 4

    Safari는 첫 번째 준비 상태를 배제하고 그 이유에 대해서는 자세히 나와있지 않다. 바로 이것이 Safari 방식이다. 또한 중요한 포인트이기도 하다. 서버에서 데이터를 사용하기 전에 요청의 준비 상태가 4라는 것을 확인하는 것은 좋은 생각인 반면 일시적인 준비 상태에 의존하는 코드를 작성하는 것은 다른 브라우저 마다 다른 결과를 얻을 수 있는 확실한 방법이다.

    예를 들어, Opera 8.5를 사용할 때 상황은 더 악화된다.

    • 3
    • 4

    Internet Explorer는 다음과 같은 상태로 반응한다.

    • 1
    • 2
    • 3
    • 4

    요청과 관련하여 문제가 있다면 문제의 원인을 찾을 수 있는 첫 번째 장소이다. 요청의 준비 상태를 보여주는 경고를 추가하여 상황이 정상적으로 돌아가는지를 확인할 수 있다. Internet Explorer와 Firefox 모두 테스트 하면 네 개의 모든 준비 상태를 얻을 수 있고 각 요청 단계를 검사할 수 있다.

    이제는 응답 쪽을 살펴보도록 하자.

     

     

    응답 데이터

     

    요청 동안에 다양한 준비 상태가 발생할 수 있다는 것을 이해했다면 XMLHttpRequest객체의 또 다른 중요한 부분에 대해 살펴보도록 하자. 바로 responseText 속성이다. 이것은 서버에서 데이터를 얻을 때 사용되는 속성이다. 서버가 요청 처리를 완료하면 그 요청에 응답하는데 필요한 데이터를 요청의 responseText에 둔다. 그런 다음 콜백 함수가 그 데이터를 사용한다.(Listing 1과 Listing 4 참조)

     

    Listing 4. 서버에서 응답 사용하기

    function updatePage() {
    if (request.readyState == 4) {
    var newTotal = request.responseText;
    var totalSoldEl = document.getElementById("total-sold");
    var netProfitEl = document.getElementById("net-profit");
    replaceText(totalSoldEl, newTotal);

    /* Figure out the new net profit */
    var boardCostEl = document.getElementById("board-cost");
    var boardCost = getText(boardCostEl);
    var manCostEl = document.getElementById("man-cost");
    var manCost = getText(manCostEl);
    var profitPerBoard = boardCost - manCost;
    var netProfit = profitPerBoard * newTotal;

    /* Update the net profit on the sales form */
    netProfit = Math.round(netProfit * 100) / 100;
    replaceText(netProfitEl, netProfit);
    }

     

    Listing 1은 매우 간단하다. Listing 4는 좀 더 복잡하다. 시작하려면 준비 상태를 검사하고 responseText 속성에서 값을 얻어야 한다

     

     

    요청하는 동안 응답 텍스트 보기

     

    준비 상태와 마찬가지로 responseText 속성의 값은 요청의 수명 주기에 걸쳐 변화한다. Listing 5의 코드를 사용하여 요청의 응답 텍스트를 테스트한다. 준비 상태도 마찬가지로 테스트 한다.

     

    Listing 5. responseText 속성 테스트 하기

    function updatePage() {
    // Output the current ready state
    alert("updatePage() called with ready state of " + request.readyState +
    " and a response text of '" + request.responseText + "'");
    }

     

    브라우저에서 웹 애플리케이션을 열고 요청을 활성화 한다. 이 코드를 최대한 활용하려면 Firefox나 Internet Explorer를 사용한다. 이 두 개의 브라우저는 요청 동안 모든 준비 상태들을 보고하기 때문이다. 준비 상태 2에서 responseText 속성은 정의되지 않는다.(그림 3) JavaScript 콘솔이 열려있었다면 에러가 생겼을 것이다.

    사용자 삽입 이미지


    그림 3. 준비 상태 2의 응답 텍스트

    준비 상태 3에서, 서버는 responseText 속성에 값을 배치한다.(그림 4)

    사용자 삽입 이미지


    그림 4. 준비 상태 3의 응답 텍스트

    준비 상태 3의 응답은 스크립트 마다, 서버 마다, 브라우저 마다 다르다. 애플리케이션을 디버깅 하는데 매우 유용하다.

     

     

    안전한 데이터 얻기

     

    모든 문서와 스팩들에서는 준비 상태가 4가 되어야지만 데이터를 안전하게 사용할 수 있다고 나와있다. 나를 믿으라. 준비 상태가 3일 때에도 responseText 속성에서 데이터를 얻을 수 있다. 하지만 여러분의 애플리케이션에서 이것에 의존하는 것은 좋지 않은 생각이다. 준비 상태 3에서 완전한 데이터에 의존하는 코드를 작성하는 것은 데이터가 불완전하다는 증거이다.

    준비 상태가 3일 때 사용자에게 피드백을 제공하는 것이 좋은 생각이다. alert() 같은 함수를 사용하는 것은 좋지 않다. Ajax를 사용하고 사용자와 경고 다이얼로그 박스를 차단시키는 것은 좋지 않지만 준비 상태가 변할 때 마다 폼이나 페이지에 대한 필드를 업데이트 할 수 있다. 예를 들어, 프로그레스 인디케이터의 넓이를 준비 상태 1에 25 퍼센트, 준비 상태 2에 50 퍼센트, 준비 상태 3에 75 퍼센트, 준비 상태 4에 100 퍼센트를 설정한다.

    물론 알다시피, 이 방식은 좋기는 하지만, 브라우저에 의존적이다. Opera에서는 첫 번째 두 개의 준비 상태를 결코 얻지 못하고 Safari는 처음 1 상태를 누락시킨다.

    이제 상태 코드에 대해 알아보자.

     

     

    HTTP 상태 코드

     

    Ajax 프로그래밍 기술에서 준비 상태와 서버의 응답 외에도, Ajax 애플리케이션에 또 다른 고급 레벨을 추가할 수 있다. 바로 HTTP 상태 코드이다. 이 코드들은 Ajax에서는 새우울 것이 없다. 웹에 있는 한 언제나 존재하는 것들이다. 웹 브라우저를 통해 이들을 보았을 것이다.

    • 401: Unauthorized
    • 403: Forbidden
    • 404: Not Found

    이 외에도 더 있다.(참고자료) Ajax 애플리케이션에 또 다른 제어 및 응답 레이어를 추가하려면 요청과 반응에 상태 코드를 검사해야 한다.

     

    200: Everything is OK

    많은 Ajax 애플리케이션에서 준비 상태를 점검하고 서버 응답으로 온 데이터로 작업하는 콜백 함수를 볼 수 있다.(Listing 6)

     

    Listing 6. 상태 코드를 무시하는 콜백 함수

    function updatePage() {
    if (request.readyState == 4) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "
    ");
    }
    }

     

    이것은 근시안적이고 에러를 많이 만드는 Ajax 프로그래밍 방식이다. 스크립트가 인증을 필요로 하는데 요청이 유효 증명을 제공하지 않으면 서버는 403 또는 401 같은 에러를 리턴한다. 하지만 서버가 요청에 응답하기 때문에 준비 상태는 4로 설정될 것이다. 결과적으로 사용자는 유효 데이터를 얻지 못하고 JavaScript가 존재하지 않는 서버 데이터를 사용하려고 할 때 에러를 얻게 된다.

    서버가 요청을 완료하고 "Everything is OK" 상태 코드를 리턴했다는 것을 확인하는 것은 간단한 일이다. 이 코드는 "200"이고 XMLHttpRequest 객체의 status 속성을 통해서 보고된다. 서버가 요청으로 끝나고 OK 상태를 리포트 했다는 것을 확인하려면 추가 체크를 콜백 함수에 추가한다.(Listing 7)

     

    Listing 7. 유효 상태 코드 추가

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "
    ");
    } else
    alert("status is " + request.status);
    }
    }

     

    코드에 몇 줄을 추가하는 것으로 무엇이 잘못되었는지를 알 수 있고 사용자는 아무런 설명이 없는 데이터 데신 유용한 에러 메시지들을 받을 수 있다.

     

     

    리다이렉션과 재 라우팅

     

    에러에 대해 이야기 하기 전에 Ajax를 사용할 때 걱정하지 않아도 될 부분에 대해 말해두겠다. 바로 리다이렉션이다. HTTP 상태 코드에서, 이것은 300 대의 상태 코드이다.

  • 301: Moved permanently
  • 302: Found (요청이 또 다른 URL/URI로 리다이렉션 된다.)
  • 305: Use Proxy (요청은 프록시를 사용하여 요청 받은 리소스에 액세스 해야 한다.)

    Ajax 프로그래머가 리다이렉션에 대해 염려 할 필요가 없는 이유가 두 가지 있다.

  • Ajax 애플리케이션들은 특정 서버측 스크립트, 서블릿, 애플리케이션을 위해 작성된다. 그 컴포넌트를 없애거나 다른 곳으로 이동하기 위함이다. 리소스는 변경되었다는 것을 (이미 이동했기 때문에)알고, 요청에서 URL을 변경하고 이러한 종류의 결과를 절대 만나지 않게 된다.

  • 보다 관련성 있는 이유가 있다. Ajax 애플리케이션과 요청들은 샌드박스화 되어있다. Ajax 요청을 만드는 웹 페이지를 공급하는 도메인은 그러한 요청에 응답해야 하는 도메인이다. 따라서 ebay.com에서 공급 받은 웹 페이지는 Ajax 스타일의 요청을 amazon.com에서 실행되는 스크립트에 할 수 없다. ibm.com 상의 Ajax 애플리케이션은 netbeans.org에서 실행되는 서블릿으로 요청할 수 없다.

    결국, 요청은 보안 에러를 만들지 않고서는 또 따른 서버로 리다이렉션 될 수 없다. 그러한 경우에, 상태 코드를 전혀 얻을 수 없다. 디버그 콘솔에 JavaScript 에러를 갖게 된다. 따라서 많은 상태 코드에 대해 생각하는 동안 리다이렉션 코드 정도는 무시할 수 있는 것이다.

     

    엣지 케이스와 하드 케이스
    이 부분에서, 신참 프로그래머들은 이러한 혼란에 대해 궁금할 것이다. Ajax 요청의 5 퍼센트 정도는 2와 3 정도의 준비 상태와 403 같은 상태 코드로 작동해야 한다. (사실, 1 퍼센트 미만이다.) 이러한 케이스는 중요하고, 엣지 케이스(edge cases)라고 일컬어진다. 이상한 조건들이 부합되는 특수한 상황인 것이다. 일상적인 것은 아니지만 사용자를 곤란에 처하게 한다.

    일반적인 사용자들은 애플리케이션이 정확히 작동하는지 매번 잊지만 그렇지 않을 때는 분명히 기억한다. 엣지 케이스와 하드 케이스를 핸들 할 수 있다면 사이트 사용자들을 만족시킬 수 있을 것이다.

     

     

    에러

     

    일단, 상태 코드 200을 관리했고 300 계열의 상태 코드는 대충 무시하면 다양한 유형의 에러들을 나타내는 400 계열의 코드만 남게 된다. Listing 7을 보면 에러가 처리되는 동안 사용자에게 출력되는 매우 일반적인 에러 메시지라는 것을 알게 된다. 이것은 올바른 방향으로 가는 단계지만 사용자와 프로그래머에게는 매우 쓸모없는 메시지이다.

    우선 소실된 페이지에 대한 지원을 추가한다. 이는 제품 시스템에서는 실제로 발생하지는 않지만 스크립트를 이동시키는 테스트나 정확하지 않은 URL을 입력할 때 자주 일어나는 일이다. 404 에러를 보고하면 혼란스러워 하는 사용자와 프로그래머에게 더 많은 도움말을 제공할 것이다. 예를 들어, 서버 상의 스크립트가 제거되거나 Listing 7에서 그 코드를 사용하면 다음과 같은 에러가 생긴다.(그림 5)

    사용자 삽입 이미지


    그림 5. 일반적인 에러 핸들링

    사용자는 문제가 무엇인지 잘 모른다. 인증에 관련된 것인지, 소실된 스크립트 인지, 사용자 에러인지 알 수 없다. 몇 가지 간단한 코드 추가로 이 에러는 더욱 구체화 된다. Listing 8을 보면 소실된 스크립트와 인증 에러까지 구체적인 메시지와 함께 처리된다.

  •  

    Listing 8. 유효 상태 코드 점검

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "
    ");
    } else if (request.status == 404) {
    alert ("Requested URL is not found.");
    } else if (request.status == 403) {
    alert("Access denied.");

    } else
    alert("status is " + request.status);
    }
    }

     

    이는 오히려 더 간단하지만 추가 정보 까지 제공한다. 그림 6은 그림 5와 같은 에러를 보여주지만 이번에는 에러 핸들링 코드가 더 나은 그림을 제공하고 있다.

    사용자 삽입 이미지


    그림 6. 구체적인 에러 핸들링

    여러분의 애플리케이션에서 인증 때문에 오류가 발생했을 때 사용자 이름과 패스워드를 지우고 에러 메시지를 스크린에 추가하는 것을 고려할 수도 있다. 이와 비슷한 방식이 소실된 스크립트나 다른 400 유형의 에러들을 핸들하는데 사용될 수 있다. 여러분이 어떤 선택을 하든 서버에서 리턴 된 상태 코드를 핸들하는 것으로 시작한다.

     

     

    추가 요청 유형

     

    XMLHttpRequest 객체를 제어하고 싶다면 HEAD 요청을 레파토리에 추가하라. 이전 두 개의 기사에서 GET 요청을 하는 방법을 설명했다. 앞으로는 POST 요청을 사용하여 서버로 데이터를 보내는 것을 설명하도록 하겠다. 향상된 에러 핸들링과 정보 수집을 위해 HEAD 요청에 대해 배워야 한다.

     

     

    요청하기

     

    HEAD 요청은 실제로 매우 간단하다. 첫 번째 매개변수로서 "GET" 또는 "POST" 대신 "HEAD"로 open() 메소드를 호출한다.(Listing 9)

     

    Listing 9. HEAD 요청

    function getSalesData() {
    createRequest();
    var url = "/boards/servlet/UpdateBoardSales";
    request.open("HEAD", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

     

    이와 같이 HEAD 요청을 하면 서버는 GET이나 POST 요청 때 처럼 실제 응답을 리턴하지 않는다. 대신, 서버는 응답에 있는 콘텐트가 마지막으로 수정된 시간이 포함된 리소스의 헤더를 리턴한다. 게다가 몇 가지 재미있는 정보도 추가한다. 이들을 사용하여 서버가 리소스를 처리 및 리턴하기 전에 리소스에 대해 알 수 있다.

    이와 같은 요청으로 할 수 있는 가장 쉬운 일은 모든 응답 헤더들을 나누는 것이다. 이로서 HEAD 요청을 통해 무엇이 가능한지를 알 수 있다. Listing 10은 HEAD 요청에서 모든 응답 헤더를 출력하는 콜백 함수이다.

     

    Listing 10. HEAD 요청에서 모든 응답 헤더 프린트 하기

    function updatePage() {
    if (request.readyState == 4) {
    alert(request.getAllResponseHeaders());
    }
    }

     

    그림 7에서 서버에 HEAD 요청을 한 간단한 Ajax 애플리케이션에서 온 응답 헤더를 볼 수 있다.

    사용자 삽입 이미지


    그림 7. HEAD 요청에서 온 응답 헤더

    이러한 헤더들을 개별적으로 사용하여 Ajax 애플리케이션에서 추가 정보나 기능을 제공할 수 있다.

     

     

    URL 검사

     

    URL이 존재하지 않을 때 404 에러를 검사하는 방법을 이미 보았다. 이것이 일반적인 문제라면, 특정 스크립트나 서블릿이 잠시 동안 오프라인에 있었다면, GET 또는 POST 요청을 하기 전에 URL을 검사해 보는 것이 좋다. HEAD 요청을 하고 콜백 함수에서 404 에러를 검사한다. Listing 11은 샘플 콜백을 보여준다.

     

    Listing 11. URL이 존재하는지 여부 검사

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    alert("URL exists");
    } else if (request.status == 404) {
    alert("URL does not exist.");
    } else {
    alert("Status is: " + request.status);
    }
    }
    }

     

    솔직히 말하면 이것의 가치는 별로 없다. 서버는 요청에 응답해야 하고 응답을 분석하여 응답 헤더에 파퓰레이트 하기 때문에 여러분은 프로세싱 시간을 저축할 수 없다. 게다가 요청을 하고 HEAD 요청을 사용하여 URL이 존재하는지 보는 것에도 많은 시간이 걸린다. Listing 7에서 처럼 에러를 핸들링 하기 보다 GET이나 POST를 사용하여 요청하기 때문이다. 무엇을 사용할 수 있는지를 정확히 아는 데는 가끔 유용하다.

     

     

    유용한 HEAD 요청

     

    HEAD 요청이 유용한 한 가지 부분은 콘텐트 길이나 콘텐트 유형을 검사할 때이다. 요청을 처리하기 위해 많은 양의 데이터를 보낼 것인지, 서버가 HTML, 텍스트, XML 대신 바이너리 데이터를 리턴해야 할지를 결정할 수 있다. (이 세 가지 모두 바이너리 데이터 보다 JavaScript에서 처리하는 것이 더 쉽다.)

    이 경우, 적절한 헤더 이름을 사용하고 이를 XMLHttpRequest 객체의 getResponseHeader() 메소드로 보낸다. 따라서 응답의 길이를 알려면 request.getResponseHeader("Content-Length");를 호출한다. 콘텐트 유형을 알려면 request.getResponseHeader("Content-Type");를 사용한다.

    많은 애플리케이션에서 HEAD 요청을 하면 어떤 기능도 추가하지 않고 요청의 속도를 늦출 수 있다. (HEAD 요청을 실행하여 응답에 대한 데이터를 얻고 후속 GET 또는 POST 요청을 통해 응답을 실제로 받는다.) 하지만 스크립트나 서버측 컴포넌트에 대해 확실하지 않은 경우 HEAD 요청으로 기본적인 데이터를 받을 수 있다.

     

     

    결론

     

    Ajax와 웹 프로그래머에게 이 글은 다소 어려울 것이다. HEAD 요청을 하는 것의 가치는 무엇인가? JavaScript에서 리다이렉션 상태 코드를 핸들해야 하는 때는 언제인가? 이 모두 좋은 질문이다. 간단한 애플리케이션의 경우, 이 모든 것은 가치가 별로 없다.

    하지만 웹이 단순한 애플리케이션만 수용하는 것은 아니다. 사용자는 점점 고급화 되고 고객들도 강력한 에러 리포팅을 원한다. 관리자 역시 애플리케이션이 조금만 느려져도 해고를 당하게 된다.

    간단한 애플리케이션을 넘어 XMLHttpRequest에 대한 이해를 높여야 할 때이다.

  • 다양한 준비 상태를 이해하고 이들이 브라우저 마다 어떻게 다른지를 이해하면 애플리케이션을 빠르게 디버깅 할 수 있다. 준비 상태에 기반하여 창조적인 기능을 만들고 요청자의 상태에 대해 사용자와 고객에게 보고할 수 있다.

  • 상태 코드를 핸들했다면 스크립트 에러, 예기치 못한 응답들, 엣지 케이스들을 다룰 수 있다. 결국, 애플리케이션은 언제나 잘 작동될 것이다.

  • 여기에 더하여 HEAD 요청을 만들고, URL의 존재를 검사하고 파일이 언제 수정되었는지를 파악하고 사용자가 유효 페이지를 얻었는지를 확인할 수 있다면 언제나 최신의 정보와 강력한 기능으로 사용자들을 만족시킬 수 있을 것이다.

    이들은 모두 Ajax의 강점이지만 극히 일부분이다. Ajax를 사용하여 애플리케이션이 에러와 문제들을 부드럽게 해결할 수 있는 강력한 토대를 구현한다면 사용자는 여러분의 사이트를 방문할 것이다. 다음 글에서는 보다 더 재미있고 흥미 있는 주제들을 나누도록 하겠다.

     

    다운로드 하십시오

    설명 이름 크기 다운로드 방식
    Example code for this article wa-ajaxintro3_ajax-xhr_adv.zip 183 KB HTTP

     

     

    참고자료

    교육
    - "Ajax 마스터, Part 1: Ajax 소개" (developerWorks, December 2005)
    - "Ajax 마스터하기, Part 2: JavaScript와 Ajax를 이용한 비동기식 요청" (developerWorks, January 2006)
    - "자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현" (developerWorks, September 2005)
    - "자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화" (developerWorks, October 2005)
    - "Call SOAP Web services with Ajax, Part 1: Build the Web services client" (developerWorks, October 2005)
    - Google GMail, Google Maps
    - Flickr
    - "Ajax: A New Approach to Web Applications
    - HTTP status codes
    - Head Rush Ajax by Elisabeth Freeman, Eric Freeman, and Brett McLaughlin (February 2006, O'Reilly Media, Inc.)
    - Java and XML , Second Edition by Brett McLaughlin (August 2001, O'Reilly Media, Inc.)
    - JavaScript: The Definitive Guide by David Flanagan (November 2001, O'Reilly Media, Inc.)
    - Head First HTML with CSS & XHTML by Elizabeth and Eric Freeman (December 2005, O'Reilly Media, Inc.)
    - developerWorks Web architecture zone
    - developerWorks technical events and Webcasts

    제품 및 기술 얻기
    -IBM trial software

    토론
    -포럼에 참여하기.
    -developerWorks blogs.

     

     

    사용자 삽입 이미지



    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3055


     

     

    프로그래머(백엔드 애플리케이션)와 웹 프로그래머(주로 HTML, CSS, JavaScript를 작성)사이에는 오래 전부터 엄격한 구분이 있었습니다. 하지만 Document Object Model (DOM)이 그 틈을 메우면서 백 엔드에서는 XML과, 프론트 엔드에서는 HTML과의 작업이 가능해 졌습니다.

     

    많은 웹 프로그래머들과 마찬가지로 여러분도 HTML로 작업을 해봤을 것이다. HTML은 프로그래머들이 웹 페이지 상에서 작업할 때 사용한다. HTML은 애플리케이션이나 사이트를 마감하면서 수행하는 마지막 작업이고, 배치, 색상, 스타일 등을 끝까지 작업한다. 웹 페이지의 디자인과 공급과 관련한 프로세스를 명확히 파악할 필요가 있다.

    1. 누군가가(대개는 여러분이) 텍스트 에디터나 IDE에서 HTML을 만든다.
    2. 그런 다음, HTML을 Apache HTTPD 같은 웹 서버에 업로딩하고 이것을 인터넷이나 인트라넷에 퍼블리시 한다.
    3. 사용자는 Firefox 또는 Safari 같은 브라우저를 사용하여 웹 페이지에 요청한다.
    4. 사용자의 브라우저는 여러분의 웹 브라우저에 HTML용 요청을 만든다.
    5. 브라우저는 서버에서 받는 페이지를 그래픽 또는 테스트로 렌더링 한다. 사용자는 웹 페이지를 보고 활성화 한다.

    매우 기본적인 것처럼 보이지만 실상은 매우 흥미롭다. 사실, 엄청난 양의 “성분(stuff)”들이 있다. 이것은 주로 4 단계와 5 단계 사이에 발생하고 바로, 이 부분을 이 글에서 중점적으로 다룰 것이다. 대부분의 프로그래머들은 사용자의 브라우저가 이것을 디스플레이 하도록 요청 받으면 대부분의 프로그래머들은 자신들의 마크업에 어떤 일이 발생하는지 정확히 고려하지 않기 때문이다.

  • 브라우저가 단순히 HTML에 있는 텍스트를 읽고 디스플레이 하는가?
  • CSS가 외부 파일에 있을 경우, CSS는 어떤가?
  • 외부 파일에 있는 JavaScript는 어떤가?
  • 브라우저는 이러한 아이템들을 어떻게 핸들하며 이벤트 핸들러, 기능, 스타일들을 텍스트 마크업으로 어떻게 매핑하는가?

    이 모든 질문들에 대한 답은 Document Object Model이다. 이제 본격적으로 DOM을 논해보자.

     

     

    웹 프로그래머와 마크업

     

    프로그래머의 작업이 끝날 때 웹 브라우저가 시작된다. 다시 말해서, HTML 파일을 웹 서버 상의 디렉토리에 얹어 놓으면 보통 이것을 "완료된 것 "으로 정리해 놓고 절대로 다시는 생각하지 않는다! 깨끗하고, 구성이 잘된 페이지를 작성할 때도 이것은 너무 멋진 목표이다. 여러분의 마크업이 브라우저를 통해 다양한 버전의 CSS와 JavaScript로 디스플레이 하기를 원하는데 이것도 잘못은 아니다.

    문제는 이러한 접근 방식이 브라우저에서 실제로 무슨 일이 일어나는지에 대해 프로그래머가 알 수 있는 범위를 제한한다는 점이다. 더욱이 클라이언트 측 JavaScript를 사용하여 웹 페이지를 동적으로 업데이트, 변경, 재구현 할 수 있는 기능 까지 제한한다. 이러한 한계를 제거하고 더 나아가 웹 사이트에서 더 나은 인터랙션과 생산성을 도모할 수 있다.

     

     

    프로그래머가 하는 일

     

    웹 프로그래머로서 여러분은 텍스트 에디터와 IDE를 시작하고 HTML, CSS, 심지어 JavaScript를 입력하기 시작한다. 태그, 셀렉터, 애트리뷰트를 사이트가 올바르게 보일 수 있도록 하는 작은 태스크라고 생각하기 쉽다. 하지만 그러한 관점을 좀더 확장 할 필요가 있다. 여러분이 콘텐트를 구성하고 있다는 것을 깨달아야 한다. 걱정하지 말라. 마크업의 가치에 대해 일장 연설을 늘어놓으려는 것은 아니다. 웹 페이지의 진정한 가치를 깨닫는 방법 내지는 형이상학적인 무엇인가를 설명하려는 것도 아니다. 여러분이 이해해야 할 것은 웹 개발 시 여러분의 역할이 정확히 무엇인가를 이해해야 한다.

    페이지를 보이게 해야 하는 시점에 와서 여러분은 제안만 할 수 있을 뿐이다. 여러분이 CSS 스타일시트를 제공하면 사용자는 여러분의 스타일을 무시할 수 있다. 폰트 사이즈를 제공하면 사용자의 브라우저는 그러한 사이즈를 변경할 수 있고 모니터에 맞게 스케일링 할 수 있다. 폰트와 컬러도 사용자의 모니터에 맞게 선택할 수 있다. 페이지를 스타일링 할 때 최선을 다하는 것도 중요하지만 이는 웹 페이지에 큰 영향을 주지 못한다.

    여러분이 완벽히 제어하는 것은 웹 페이지의 구조이다. 여러분의 마크업은 변경할 수 없고 사용자는 이것을 망칠 수 없다. 브라우저는 웹 서버에서 이것을 가져와서 디스플레이 한다. (여러분의 구미 보다 사용자의 구미에 따라 스타일로) 하지만 이 페이지의 구성은-이 단어가 그 문단 내에 있든 다른 div에 있든-전적으로 여러분에 달려있다. 페이지를 실제로 변경할 때(이것은 대부분의 Ajax 애플리케이션들이 집중하는 것이다.) 이것은 여러분이 운영하는 페이지의 구조이다. 텍스트의 조각의 색상을 변경하는 것이 좋지만 텍스트나 전체 섹션을 기존 페이지에 추가하는 것이 훨씬 더 좋다. 사용자가 그 섹션을 어떻게 스타일링 하던지 간에 페이지 그 자체의 구성을 가지고 작업한다.

     

     

    마크업이 수행하는 일

     

    마크업이 구성에 관한 것이라는 것을 깨달으면 이것을 달리 볼 수 있다. h1이 텍스트를 크고, 검고, 두껍게 만든다고 생각하는 대신 h1을 헤딩으로서 생각하라. 사용자가 어떻게 보는가, 그리고 사용자가 여러분의 CSS를 사용하는 자신들의 것을 사용하든 두 개를 결합하여 사용하든 이것은 두 번째 문제이다. 대신 마크업은 이 정도의 구성을 제공하는 것이라는 것을 깨달아라. P는 텍스트가 단락(paragraph)이라는 것을 나타내고, img는 이미지를, div는 페이지를 섹션으로 나눈다.

    스타일과 작동(이벤트 핸들러와 JavaScript)가 fact 뒤에 이 구성에 적용된다는 것도 명확해 진다. 마크업은 적소에서 작동되거나 스타일링 되어야 한다. 따라서 HTML에 대한 외부 파일에 CSS를 갖는 것처럼 마크업의 구성도 스타일, 포맷팅, 작동과 분리된다. 엘리먼트의 스타일 또는 텍스트 조각을 JavaScript로부터 확실히 변화시킬 수 있고 마크업이 레이아웃 한 구성을 실제로 바꿀 수 있다는 것은 더 흥미 있는 사실이다.

    마크업이 페이지에 구성 또는 프레임웍만 제공한다는 것을 마음에 새긴다면 본격적인 게임에 돌입해보자. 브라우저가 모든 텍스트 구성을 가지고, 이를 변경, 추가, 삭제 가능한 객체로 바꾸는 방법을 보자.

     

     

    텍스트 마크업의 장점

     

    웹 브라우저를 논하기 전에 왜 플레인 텍스트가 HTML을 저장하기에 최상의 선택인지를 생각해 봐야 한다. (마크업에 대해 더 알아야 할 것들 참조) 찬반을 논하기 전에, 페이지가 보여질 때 마다 HTML이 네트워크를 통해 웹 브라우저로 보내진다는 것을 생각해 보라. (캐싱 같은 문제는 차후에 논하기로 한다.) 텍스트와 함께 전달하는 것 보다 효율적인 방법은 없다. 바이너리 객체, 그래픽으로 구현된 페이지, 재구성된 마크업 청크 등, 이 모든 것들은 플레인 텍스트 파일 보다 네트워크를 통해 전송할 때 더 어려운 것들이다.

    브라우저를 이러한 방정식에 대입해 보자. 오늘날의 브라우저에서는 사용자가 텍스트의 크기길 변경하고, 이미지를 스케일링 하고 CSS나 JavaScript를 다운로드 할 수 있다. 이 모든 것은 페이지의 온갖 종류의 그래픽 표현을 브라우저로 보내는 전조가 된다. 대신 브라우저는 미가공 HTML을 필요로 한다. 왜냐하면 이것은 태스크를 핸들하기 위해 서버를 믿기 보다 어떤 프로세싱이든 브라우저에 있는 페이지에 적용할 수 있기 때문이다. 같은 맥락에서, CSS와 JavaScript를 분리하고, 이들을 HTML 마크업에서 분리할 때에는 분리하기 쉬운 포맷이 필요하다.

    HTML 4.01, XHTML 1.0/ 1.1 같은 새로운 표준들이 콘텐트(페이지의 데이터)를 표현과 스타일(보통 CSS에 의해 적용됨)에서 분리하겠다는 약속을 기억하는가? 프로그래머들이 CSS에서 HTML을 분리하려면 브라우저를 실행하여 페이지에서 몇몇 구현들을 가져오고 그러한 표준의 많은 장점들을 없앤다. 브라우저에서 이렇게 다른 부분들을 계속 분리시키면 브라우저는 서버에서 HTML을 가져올 때 최상의 유연성을 보인다.

     

    마크업에 대해 더 알아야 할 것들

    플레인 텍스트 편집: 옳은가, 그른가?
    플레인 텍스트 파일은 마크업을 저장하는 데는 이상적이지만 그 마크 업을 편집하는 데는 그렇지 못하다. Macromedia DreamWeaver 또는 Microsoft ?? FrontPage ?? 같은 IDE를 사용하는 것이 바람직하다. 이러한 환경은 종종 웹 페이지를 구현할 때 도움이 되는 지름길과 도움말을 제공한다. 특히 CSS와 JavaScript를 사용할 때 그렇다. 많은 사람들은 여전히 Notepad나 vi를 선호한다. (고백하건데 나도 그 중 하나이다.) 이것 역시 좋은 선택이다. 두 경우 모두 마지막 결과는 마크업으로 가득 찬 텍스트 파일이다.

    네트워크를 통한 텍스트: 좋은 것
    이미 언급했듯이 텍스트는 HTML이나 CSS 같은 문서에 있어 훌륭한 미디어이다. 이것은 네트워크를 통해 수백, 수천 번 이동한다. 브라우저가 텍스트를 나타내는데 어려움을 겪는다면 텍스트를 시각적 페이지와 그래픽 페이지로 변환한다는 의미이다. 브라우저가 웹 서버에서 페이지를 실제로 가져오는 방법과는 관련이 없다. 이 경우 텍스트는 여전히 최상의 옵션이다.

     

     

    웹 브라우저 분석

     

    지금까지 여러분이 읽은 모든 것은 웹 개발 프로세스에서의 여러분의 역할에 대한 리뷰에 불과하다. 하지만 웹 브라우저가 무엇을 수행하는지를 논해야 하는 시점에서 유능한 많은 웹 디자이너와 개발자들은 보이지 않는 곳에서 실제로 어떤 일이 발생하는지 종종 깨닫지 못한다. 이 섹션에서는 바로 그 부분을 설명하도록 하겠다. 걱정하지 말라. 코드도 함께 등장할 것이다. 잠시 코딩하고 싶은 조바심을 접어두라. 웹 브라우저가 정확히 어떤 일을 수행하는지를 이해하는 것이 정확한 코딩 작업의 필수이기 때문이다.

     

     

    텍스트 마크업의 단점

     

    텍스트 마크업이 디자이너나 페이지 생성자에게 엄청난 이득을 주듯이 브라우저에는 비교적 큰 단점을 갖고 있다. 특히 브라우저는 텍스트 마크업을 사용자에게 시각적으로 직접 나타내기가 매우 힘들다. (마크업에 대해 더 알아야 할 것들 참조) 다음과 같은 브라우저 태스크를 생각해 보라.

  • CSS 스타일?외부 파일에 있는 다중 스타일시트?을 HTML 문서의 엘리먼트 유형, 클래스, 아이디, 위치에 기반하여 마크업에 적용한다.
  • JavaScript 코드에 기반한 스타일과 포맷팅?외부 파일에도 있음?을 HTML 문서의 다른 부분들에 적용한다.
  • JavaScript 코드에 기반하여 폼 필드의 값을 변경한다.
  • JavaScript 코드에 기반하여 이미지 롤오버와 이미지 스와핑 같은 시각 효과를 지원한다. 복잡함은 이러한 태스크들을 코딩 하는데 있는 것이 아니다. 이러한 일들을 하기는 정말 쉽다. 복잡함은 브라우저가 실제로 요청된 액션을 수행하는 데서 온다. 마크업이 텍스트로 저장되면 center-text 클래스에서 텍스트를 센터링 해야 한다. (text-align: center) 이것을 어떻게 할 것인가?

  • 텍스트에 인라인 스타일링을 추가하는가?
  • 브라우저의 HTML 텍스트에 스타일링을 적용하고 어떤 것이 센터링 되는지, 어떤 것이 센터링 되지 않는지를 지켜보는가?
  • 스타일링 되지 않은 HTML을 적용한 다음 팩트 다음에 포맷을 적용하는가?
    이 같은 매우 어려운 질문들 때문에 몇몇 사람들이 오늘날 브라우저를 코딩을 한다.

    확실히, 플레인 텍스트는 브라우저를 위해 HTML을 저장하는 최상의 방법은 아니다. 텍스트가 페이지의 마크업을 가져오는 좋은 솔루션이었지만 말이다. 이 외에도 JavaScript가 페이지의 구조를 변경하는 기능은 트릭이 조금 있다. 브라우저가 수정된 구조를 디스크에 재작성 해야 하는가? 문서의 현재 어떤 단계에 있는지를 어떻게 파악할 수 있는가?

    확실히 텍스트는 답이 못 된다. 수정하기도 어렵고, 스타일과 작동을 추가하기에는 불편하고, 궁극적으로 오늘날 웹 페이지의 동적인 특징과 거리가 멀다.

     

     

    트리 뷰로 이동하기

     

    이 문제에 대한 답, 오늘날의 웹 브라우저에 맞는 답은 트리 구조를 사용하여 HTML을 나타내는 것이다. 텍스트 마크업으로 구현된 단순하고 지루한 HTML 페이지 대신 Listing 1을 보자.

     

    Listing 1. 텍스트 마크업의 간단한 HTML 페이지

    <html>
    <head>
    <title>Trees, trees, everywhere</title>
    </head>
    <body>
    <h1>Trees, trees, everywhere</h1>
    <p>Welcome to a <em>really</em> boring page.</p>
    <div>
    Come again soon.
    <img src="come-again.gif" />
    </div>
    </body>
    </html>

     

    그림 1. 이 브라우저는 이것을 트리 구조로 변환한다.

    사용자 삽입 이미지


    그림 1. Listing 1의 트리 뷰

    이 글을 위해 단순함을 유지했다. DOM과 XML 전문가는 공백이 문서에 있는 텍스트가 구현되고 웹 브라우저의 트리 구조에서 깨지는 방법에 영향을 줄 수 있다는 것을 알 것이다. 공백의 효과에 대해 알고 있다면 정말 대단하다. 그렇지 않다면 공부하면 된다. 걱정 말라. 이것이 문제가 될 때 필요한 것이 무엇인지를 깨닫게 될 것이다.

    실제 트리 백그라운드 외에 여기에서 알아야 할 첫 번째 것은 트리에 있는 모든 것이 가장 바깥쪽에서 시작되고 HTML의 엘리먼트(html)를 포함하고 있다는 것이다. 이는 트리 메타포에서 루트(root) 엘리먼트라고 불린다. 이것이 트리의 바닥에 있지만 트리를 분석할 때면 언제나 이것부터 시작한다. 완전히 거꾸로 뒤집어보면 도움이 될 것이다.

    루트에서부터 마크업의 다양한 조각들 간 관계를 보여주는 라인의 흐름을 따라가 보라. head와 body 엘리먼트는 html 루트 엘리먼트의 자식들이다. title은 head의 자식이고 "Trees, trees, everywhere" 텍스트는 title의 자식이다. 전체 트리는 브라우저가 그림 1과 비슷한 구조가 될 때까지 이와 같이 구성된다.

     

     

    몇 가지 추가 용어

     

    트리 메타포를 이해하기 위해서 head와 body 는 html의 브랜치(branch)라고도 일컬어진다. 이들은 자신들의 자식이 있기 때문에 브랜치이다. 트리의 말단에 다다르면 "Trees, trees, everywhere"와 "really" 같은 텍스트로 가게 된다. 이들은 자식들이 없기 때문에 잎(leave)으로 일컬어진다. 이 용어들을 다 기억할 필요는 없고 특정 용어가 무엇을 의미하는지를 파악하려면 나무의 구조를 머리속에 그려보면 된다.

     

     

    객체의 가치

     

    기본적인 용어들을 익혔으니 엘리먼트 이름과 텍스트가 들어있는 작은 직사각형에 집중해 보자.(그림 1) 각 직사각형들은 객체이다. 여기에서 브라우저는 텍스트와 관련된 문제들을 해결한다. 객체를 사용하여 HTML 문서의 조각들을 나타냄으로서 구성을 변경하고, 스타일을 적용하며, JavaScript를 문서에 액세스 시키기가 매우 쉬워진다.

     

     

    객체 유형과 속성

     

    모든 가능한 유형의 마크업은 고유의 객체 유형을 갖는다. 예를 들어, HTML에 있는 엘리먼트는 Element 객체 유형에 의해 구현된다. 문서에 있는 텍스트는 Text 유형에 의해 구현된다. 애트리뷰트는 Attribute 유형에 의해 표현된다.

    따라서 웹 브라우저는 객체 모델을 사용하여 문서를 표현하고?정적 텍스트를 다룰 필요가 없음?객체 유형에 따라 즉각 구분할 수 있다. HTML 문서는 파싱되고 그림 1의 객체들로 바뀐다. 그런 다음 대괄호 같은 이스케이프 시퀀스로 바뀐다. 이는 브라우저의 작업을 훨씬 쉽게 만든다. 적어도 인풋 HTML을 파싱한 후에도 말이다. 어떤 것이 엘리먼트이고 어떤 것이 애트리뷰트인지 파악하고 객체 유형을 어떻게 다룰지를 결정하는 작동은 간단하다.

    객체들을 사용함으로서 웹 브라우저는 그러한 객체들의 속성들을 변경할 수 있다. 예를 들어, 각 엘리먼트 객체는 하나의 부모와 자식 리스트를 갖고 있다. 새로운 자식 엘리먼트나 텍스트를 추가하는 것은 새로운 자식을 엘리먼트의 자식 리스트에 추가하는 문제에 지나지 않는다. 이러한 객체들은 또한 style 속성을 갖고 있어서 엘리먼트의 스타일이나 텍스트 조각을 쉽게 변경할 수 있다. 예를 들어, 다음과 같이 JavaScript를 사용하여 div의 높이를 수정할 수 있다.

     

    someDiv.style.height = "300px";

     

    다시 말해서, 웹 브라우저는 이와 같이 객체 속성들을 사용하여 트리의 모양과 구조를 쉽게 변경한다. 이것을 복잡한 것과 비교해 보라. 속성과 구조가 변할 때 마다 브라우저는 정적 파일을 재작성 하고, 재 파싱 하고 이를 스크린에 다시 디스플레이 해야 한다. 이 모든 것이 객체로도 가능해진다.

    이 시점에서 HTML 문서에 대해 알아보고 이를 트리로 그려보자. 평범한 요청은 아닌 것 같지만 이들을 다룰 수 있으려면 이러한 트리 구조에 익숙해져야 한다. 보통의 요청은 아닌 것 같지만 이 트리 구조에 익숙해져야 한다. 이들을 조작할 수 있으려면 말이다.

    이 프로세스에서 몇 가지 이상한 점들을 발견하게 된다. 다음과 같은 상황을 생각해 보자.

  • 애트리뷰트에는 어떤 일이 발생하는가?
  • em과 b 같은 엘리먼트로 나뉜 텍스트는 어떻게 되는가?
  • 정확하게 구축되지 않은 HTML은 어떻게 되는가? (닫기 p 태그가 소실 되는 경우) 일단 이러한 유형의 문제에 익숙해지면 다음 섹션을 이해하기가 더 쉬울 것이다.

     

     

    엄격함을 유지한다.

     

    내가 언급했던 것을 직접 해본다면 마크업의 트리 뷰에 잠재적 문제 몇 가지들을 발견할 것이다. (직접 하지 않을 것이라면 내 말을 믿어라.) 사실, Listing 1과 그림 1에서 여러 가지를 발견할 것이다. p 엘리먼트가 나뉘어지는 방법부터 시작해서 말이다. 전형적인 웹 개발자에게 p 엘리먼트의 텍스트 콘텐트가 무엇인지를 묻는다면 일반적으로 "Welcome to a really boring Web page"라고 답할 것이다. 이것을 그림 1과 비교하면 이러한 대답이 논리적이긴 하지만 전혀 맞지 않다는 것을 알게 될 것이다.

    p 엘리먼트는 세 개의 다른 자식 객체들을 갖고 있고, 이 중 어떤 것도 전체 "Welcome to a really boring Web page" 텍스트를 포함하고 있지 않다. "Welcome to a "와 " boring Web page" 같은 텍스트의 일부를 볼 수는 있어도 이것이 전체 문장은 아니다. 이를 이해하려면 마크업의 모든 것이 어떤 유형의 객체로 바뀌어야 한다는 것을 기억하라.

    더욱이 순서도 문제가 된다. 정확한 마크업이지만 여러분의 HTML에서 제공된 순서와 다르다면 사용자가 웹 브라우저에 어떻게 대응할지를 상상할 수 있겠는가? 문서를 구성했던 방식이 아닐 때에도 제목과 헤딩 사이에 끼게 될 것이다. 브라우저는 엘리먼트와 텍스트의 순서를 보존해야 한다.

    이 경우, p 엘리먼트는 세 개의 구별된 부분들을 갖는다.

    • em 엘리먼트 앞에 오는 텍스트
    • em 엘리먼트
    • em 엘리먼트 뒤에 오는 텍스트

    이 순서를 섞는다면 텍스트의 잘못된 부분에 강조를 적용한 것이다. 이 모든 것을 바로잡으려면 p 엘리먼트는 Listing 1의 HTML에 나타났던 순서 대로 세 개의 객체 자식들을 가져야 한다. 더욱이 강조된 텍스트인 "really"는 p의 자식 엘리먼트가 아니다. 이것은 p의 자식인 em의 자식이다.

    이 개념을 이해하는 것은 매우 중요하다. "really" 텍스트가 나머지 p 엘리먼트의 텍스트와 함께 디스플레이 되더라도 이것은 여전히 em 엘리먼트의 직접적인 자식이다. 이것은 나머지 p와는 다른 포맷팅을 가질 수 있고 나머지 텍스트와 개별적으로 움직일 수 있다.

    이를 유념하면서 Listing 2와 3의 HTML을 다이어그램으로 그리면서 텍스트에 정확한 부모를 유지하도록 한다. 정확한 부모로 유지시킨다.

     

    Listing 2. 약간의 트릭이 들어간 엘리먼트 중첩이 있는 마크업

    <html>
    <head>
    <title>This is a little tricky</title>
    </head>
    <body>
    <h1>Pay <u>close</u> attention, OK?</h1>
    <div>
    <p>This p really isn't <em>necessary</em>, but it makes the
    <span id="bold-text">structure <i>and</i> the organization</span>
    of the page easier to keep up with.</p>
    </div>
    </body>
    </html>

     

    Listing 3. 보다 트릭이 심한 엘리먼트의 중첩

    <html>
    <head>
    <title>Trickier nesting, still</title>
    </head>
    <body>
    <div id="main-body">
    <div id="contents">
    <table>
    <tr><th>Steps</th><th>Process</th></tr>
    <tr><td>1</td><td>Figure out the <em>root element</em>.</td></tr>
    <tr><td>2</td><td>Deal with the <span id="code">head</span> first,
    as it's usually easy.</td></tr>
    <tr><td>3</td><td>Work through the <span id="code">body</span>.
    Just <em>take your time</em>.</td></tr>
    </table>
    </div>
    <div id="closing">
    This link is <em>not</em> active, but if it were, the answers
    to this <a href="answers.html"><img src="exercise.gif" /></a> would
    be there. But <em>do the exercise anyway!</em>
    </div>
    </div>
    </body>
    </html>

     

    이러한 관행에 대한 해답은 이 글 끝부분의 GIF 파일인 (그림 2)와 (그림 3)에서 찾을 수 있다. 스스로 알아내기 전에 몰래 보지 않기를 바란다. 엄격한 규칙이 트리를 구성하는데 어떻게 적용되는지를 이해하면 도움이 될 것이다. HTML과 트리 구조를 마스터 한다면 정말로 도움이 될 것이다.

     

     

    애트리뷰트

     

    애트리뷰트를 어떻게 다루어야 하는지를 파악할 때 문제가 생긴 적이 있는가? 앞서 언급했지만 애트리뷰트는 고유의 객체 유형을 갖고 있지만 애트리뷰트는 엘리먼트의 자식이 아니다. 중첩 엘리먼트와 텍스트는 같은 레벨의 애트리뷰트가 아니고 Listing 2와 3에 대한 답에는 애트리뷰트가 나타나지 않는다는 것을 알 수 있다.

    사실 애트리뷰트는 브라우저가 사용하는 객체 모델에 저장되지만 이들은 특별한 경우이다. 각 엘리먼트는 여기에 사용되는 애트리뷰트 리스트를 갖고 있고 자식 객체의 리스트에서 분리된다. 따라서 div 엘리먼트는 "id" 애트리뷰트와 또 다른 이름 " class "를 포함하고 있는 리스트를 갖게 된다.

    엘리먼트용 애트리뷰트가 유일한 이름을 갖고 있어야 한다는 것을 기억하라. 다시 말해서, 하나의 엘리먼트가 두 개의 "id" 또는 두 개의 "class"애트리뷰트를 가질 수 없다. 보존하고 액세스 할 리스트를 매우 쉽게 만든다. 다음 글에서 보겠지만 getAttribute("id") 같은 메소드를 호출하여 애트리뷰트 값을 이름 별로 얻을 수 있다. 애트리뷰트를 추가하고 기존 애트리뷰트의 값을 비슷한 메소드 호출을 설정(재설정)할 수 있다.

    애트리뷰트의 독자성은 리스트를 자식 객체들의 리스트와 구별시킨다. p 엘리먼트는 그 안에 여러 em 엘리먼트를 갖고 있기 때문에 자식 객체의 리스트에는 중복 아이템이 포함될 수 있다. 자식 리스트와 애트리뷰트 리스트는 비슷하게 작동하지만 하나는 중복을 포함할 수 있고(객체의 자식) 하나는 그럴 수 없다는 것이다. (엘리먼트 객체의 애트리뷰트) 마지막으로 엘리먼트만이 애트리뷰트를 가질 수 있기 때문에 텍스트 객체는 여기에 첨부될 리스트가 없다.

     

     

    어지러운 HTML

     

    더 진행하기에 앞서 브라우저가 마크업을 트리 구현으로 변환하는 방법, 브라우저가 엉성한 폼의 마크업을 어떻게 다루는지를 볼 필요가 있다. 구성이 잘되었다(Well-formed)는 용어는 XML에서 광범위하게 사용되고 두 가지 기본적인 의미가 있다.

    모든 오프닝 태그는 여기에 매칭되는 클로징 태그를 갖고 있다. 따라서 모든 <p>는 </p>와 <div>는 </div>와 매칭된다.
    가장 안쪽의 오프닝 태그는 가장 안쪽의 클로징 태그와 매칭된다. 그 다음 안쪽의 오프닝 태그는 그 다음 안쪽의 클로징 태그와 매칭되는 식이다. 따라서 <b><i>bold and italics</b></i>는 옳지 않다. 가장 안쪽의 오프닝 태그인 <i>가 <b>와는 맞지 않기 때문이다. 이를 잘 구성하려면 오프닝 태그 순서를 바꾸거나 클로징 태그 순서를 바꾼다. (둘 다 바꾼다면 똑 같은 문제가 생긴다.)

    이 두 가지 규칙들을 자세히 연구해 보자. 두 규칙 모두 문서의 간단한 구성을 늘릴 뿐만 아니라 모호함을 제거한다. Bolding이 먼저 적용되고 그 다음에 italics를 적용해야 하는가? 아니면 그 반대인가? 순서와 다의성이 큰 문제인 것처럼 보이지만 CSS에서는 이 규칙들이 다른 규칙들을 무시할 수 있도록 한다. 따라서 b 엘리먼트 안에 있는 텍스트의 폰트가 i 엘리먼트 내의 폰트와 다르다면 포맷팅이 적용되는 순서는 매우 중요하다. 따라서 HTML 페이지의 좋은 구성이 중요한 것이다.

    잘 구성되지 않은 문서를 브라우저가 받는 경우 할 수 있는 최선을 다한다. 결과 트리 구조는 가장 좋은 경우는 원래 페이지 작성자가 의도했던 것과 비슷한 것이고 최악의 경우 완전히 다른 것이다. 브라우저에 페이지를 로딩하고 기대했던 것과 완전히 다른 일이 발생한다면 구조에 대해 다시 생각해 봐야 한다. 물론 픽스는 간단하다. 문서가 잘 구성되었는지를 확인하는 것이다. 표준화된 HTML을 작성하는 방법을 모르겠다면 참고자료를 참조하라.

     

     

    DOM

     

    지금 까지, 브라우저가 웹 페이지를 객체 구현으로 변환하는 것에 대해 배웠다. 아마도 여러분은 객체 구현이 DOM 트리라고 생각해왔을 것이다. DOM은 문서 객체 모델(Document Object Model)을 의미하고 World Wide Web Consortium (W3C)에서 사용할 수 있는 스팩이다.(참고자료 참조)

    DOM은 브라우저가 마크업을 나타낼 수 있도록 하는 객체의 유형과 속성들을 정의한다. (다음 글에서는 JavaScript와 Ajax 코드에서 DOM을 사용하는 방법을 설명하겠다.)

     

     

    문서 객체

     

    무엇보다도 객체 모델에 액세스 해야 한다. 이것은 매우 쉽다. 웹 페이지에서 실행되는 JavaScript 코드 조각에 있는 빌트인 document 변수를 사용하려면 다음과 같이 코드를 작성한다.

     

    var domTree = document;

     

    물론 이 코드는 그 자체로는 쓸모가 없지만 모든 웹 브라우저가 document 객체를 JavaScript 코드에 사용할 수 있도록 하고 객체는 완벽한 마크업 트리를 나타낸다.(그림 1)

     

     

    모든 것이 노드이다!

     

    확실히, document 객체는 중요하지만 단지 시작에 불과하다. 더 진행하기 전에 또 다른 용어인 노드(node) 개념을 익혀야 한다. 마크업의 각 부분이 객체에 의해 구현되지만 이는 하나의 객체(특정 유형의 객체)인 DOM 노드에 불과하다는 것을 이미 알 것이다. 보다 특별한 유형인 텍스트, 엘리먼트, 애트리뷰트는 이러한 기본적인 노드 유형에서 확장된다. 따라서 여러분은 텍스트 노드, 엘리먼트 노드, 애트리뷰트 노드를 갖고 있는 것이다.

    JavaScript로 프로그래밍을 했다면 DOM 코드를 사용하는 방법도 알 것이다. 이 Ajax 시리즈를 충실히 이행했다면 여러분도 DOM 코드를 사용한 것이다. 예를 들어, var number = document.getElementById("phone").value; 라인은 DOM을 사용하여 특정 엘리먼트를 찾아 그 엘리먼트의 값(이 경우 폼 필드)을 가져온다. 따라서 여러분이 인식 못했더라도 여러분은 document를 JavaScript 코드에 타이핑 할 때마다 DOM을 사용한 것이었다.

    여러분이 배웠던 용어를 정비하기 위해 DOM 트리는 객체의 트리지만 보다 구체적으로는 노드 객체들의 트리이다. Ajax 애플리케이션 또는 JavaScript에서 그러한 노드들과 작업하여 엘리먼트와 이것의 콘텐트를 지우고 특정 텍스트 조각을 강조하고 새로운 이미지 엘리먼트를 추가하는 등 특별한 효과를 만들 수 있다. 이 모든 것은 클라이언트 측(웹 브라우저에서 실행되는 코드)에서 발생하기 때문에 이러한 효과는 서버와 통신 없이 즉시 발생한다. 결국 보다 반응성 있는 애플리케이션이 될 것이다.

    대부분의 프로그래밍 언어에서 각 노드 유형에 맞는 실제 객체 이름들을 배우고 속성들을 배우고 유형과 캐스팅을 파악해야 한다. 하지만 이중 어떤 것도 JavaScript에서는 필요하지 않다. 변수를 만들어서 여기에 원하는 객체를 할당한다.

     

    var domTree = document;
    var phoneNumberElement = document.getElementById("phone");
    var phoneNumber = phoneNumberElement.value;

     

    변수를 만들고 여기에 정확한 유형을 핸들하는 유형과 JavaScript는 없다. 결과적으로 JavaScript에서 DOM을 사용하기가 매우 쉬워진다. (다음 글에서는 XML과 관련한 DOM에 초점을 맞춰 설명하겠다.)

     

     

    결론

     

    지금 여기에서 설명한 것이 DOM의 전부는 아니다. 사실 이 글은 DOM의 개요서에 지나지 않는다. 오늘 설명한 것 이상의 것이 DOM에는 있다.

    다음 글에서는 JavaScript에서 DOM을 사용하여 웹 페이지를 만들고 HTML을 수정하고 사용자 인터랙션을 높이는 방법을 설명하겠다. DOM을 주제로 다시 한면 설명하겠다. Ajax 애플리케이션의 중요한 부분인 DOM에 익숙해지기 바란다.

    바로 지금 DOM을 더 깊이 연구할 수 있다. DOM 트리로 옮기는 방법, 엘리먼트와 텍스트의 값을 얻는 방법, 노드 리스트를 통해 반복하는 방법 등을 자세히 설명하겠다.

    무엇보다도 트리 구조에 대해 생각해 보고 HTML을 통해서 웹 브라우저가 HTML을 마크업의 트리 뷰로 어떻게 전환하는지에 대해 생각해 보고 다음 글에 임하기 바란다. 또한, DOM 트리의 구성을 생각해 보고 이 글에 설명된 특별한 경우를 생각해 보라. 애트리뷰트, 그 안에 엘리먼트와 혼합된 텍스트, 텍스트 콘텐트를 갖고 있지 않은 엘리먼트(img 엘리먼트) 등을 생각해 보라.

    이러한 개념을 확실히 이해하고 JavaScript와 DOM의 신택스를 배운다면 도움이 될 것이다.

    여기 Listing 2와 2에 대한 답을 제시하겠다. 샘플 코드도 포함되어 있다.

    사용자 삽입 이미지


    그림 2. Listing 2에 대한 답



    사용자 삽입 이미지


    그림 3. Listing 3에 대한 답

     

     

    참고자료

    교육
    - developerWorks Ajax series :
       - "Ajax 마스터, Part 1: Ajax 소개" (December 2005).
       - "Ajax 마스터하기, Part 2: JavaScript와 Ajax를 이용한 비동기식 요청"(January 2006).
       - "Ajax 마스터하기, Part 3: Ajax의 고급 요청 및 응답" (February 2006).

    - DOM Home Page
    - DOM Level 3 Core Specification.
    - ECMAScript language bindings for DOM
    - "자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현"(developerWorks, September 2005).
    - "자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화" (developerWorks, October 2005).
    - "Call SOAP Web services with Ajax, Part 1: Build the Web services client:" (developerWorks, October 2005).
    - "Ajax: A New Approach to Web Applications:"
    - HTTP status codes.
    - Head Rush Ajax by Elisabeth Freeman, Eric Freeman, and Brett McLaughlin (February 2006, O'Reilly Media, Inc.)
    - Java and XML, Second Edition by Brett McLaughlin (August 2001, O'Reilly Media, Inc.)
    - JavaScript: The Definitive Guide by David Flanagan (November 2001, O'Reilly Media, Inc.)
    - Head First HTML with CSS & XHTML by Elizabeth and Eric Freeman (December 2005, O'Reilly Media, Inc.)
    - developerWorks Web architecture zone
    - developerWorks technical events and Webcasts

    제품 및 기술 얻기
    -IBM trial software

    토론
    -developerWorks blogs.

     

     

    사용자 삽입 이미지



    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3056

      Comments,     Trackbacks
    [Ajax] Ajax 마스터하기 - Ajax의 고급 요청 및 응답 [PART 03]

    [Ajax] Ajax 마스터하기 - Ajax의 고급 요청 및 응답 [PART 03]

     

    개요
    PART 01/Ajax 소개
    PART 02/JavaScript와 Ajax를 이용한 비동기식 요청
    PART 03/Ajax의 고급 요청 및 응답
    PART 04/웹 응답에 DOM 활용하기
    PART 05/DOM 다루기


     

    HTML, JavaScript™, DHTML, DOM으로 구성된 Ajax는 볼품없는 웹 인터페이스를 인터랙티브 Ajax 애플리케이션으로 변형하는 획기적인 방식이다. Ajax 전문가인 필자는 이러한 기술들이 어떻게 작용하는지 전체적인 개요를 비롯하여 세부사항 까지 설명한다. 또한 XMLHttpRequest 객체 같은 Ajax의 중심적인 개념들을 소개한다.

     

    5년 전, XML에 대해 무지했다면 아무도 얘기할 상대가 없는 미운 오리 새끼 신세가 되었을지도 모르겠다. Ruby 프로그램이 주목을 받았던 8개월 전, Ruby 프로그램 언어 기능에 대해 알지 못했던 프로그래머들은 냉수기 관련 산업세계에서 환영 받지 못했다. 그런 것처럼, 최신 기술단계로 입문하고자 한다면 Ajax에 대해 알아야 한다.

    하지만 Ajax는 일시적으로 유행하는 툴이 아니다. 웹 사이트를 구축하는 강력한 방식이며 완전히 새로운 언어를 배우는 것보다는 그다지 어렵지 않다.

    Ajax에 관해 자세히 들어가기 전에 잠시 Ajax의 기능에 대해 알아보자. 오늘날 애플리케이션을 작성할 시 두 가지 애플리케이션이 있다.

    • 데스크톱 애플리케이션
    • 웹 애플리케이션

    두 애플리케이션은 다 친숙한 것들이다. 일반적으로 데스크톱 애플리케이션은 CD상에 배치된 다음 (또는 웹 사이트에서 다운로드) 컴퓨터에 완전 설치된다. 이 애플리케이션은 인터넷을 이용해 업데이트를 다운로드하기도 하지만 애플리케이션 실행 코드는 데스크톱 상에 상주해 있다. 전혀 새로운 것이 아닌 웹 애플리케이션은 웹 서버 상에서 실행되며 웹 브라우저 상에서 접속된다.

    하지만 두 애플리케이션에 대한 코드 실행 위치보다 애플리케이션 작동방식 및 애플리케이션과 사용자와의 상호작용방식이 중요하다. 일반적으로 데스크톱 애플리케이션은 상당히 빠르고 (컴퓨터 상에서 실행되고 인터넷 상에서 대기 중인 상태가 안 나온다.), 대형 사용자 인터페이스(일반적으로 운영체제와 상호작용)를 갖추며 상당히 동적이다. 거의 대기시간 없이 메뉴 및 하위 메뉴를 클릭, 지시, 입력하고 풀업한다.

    반면 웹 애플리케이션은 가장 최신 것이며 데스크톱에서는 전혀 얻을 수 없는 서비스를 제공한다.(Amazon.com 및 eBay를 생각해 볼 것.) 하지만 웹 애플리케이션 기능으로 인해 서버 응답 대기, 스크린 재생 대기, Request 컴백 및 새 페이지 생성에 관한 대기 기능 등이 부수된다.

    분명 지나친 단순화 과정임에는 틀림없지만 기본 개념은 얻게 된다. 이미 눈치를 챘겠지만 Ajax는 데스크톱 애플리케이션 및 항상 업데이트 되는 웹 애플리케이션의 기능 및 상호작용 간의 차이를 줄여주는 역할을 한다. 여러분은 마치 데스크톱 애플리케이션에서 찾은 것처럼 동적 사용자 인터페이스 및 가상 제어기능을 사용한다. 하지만 웹 애플리케이션 상에서 데스크톱 애플리케이션을 이용할 수 있다. 그러면 대기 중인 것이 무엇인가? Ajax 및 볼품없는 웹 인터페이스가 응답 Ajax 애플리케이션으로 변환되는 과정에 대해 살펴보기로 하자.

    그러면 대기 중인 것이 무엇인가? Ajax 및 볼품없는 웹 인터페이스가 응답 Ajax 애플리케이션으로 변환되는 과정에 대해 살펴보기로 하자.

     

     

    오래된 기술, 새로운 기법

     

    Ajax에 관해 살펴보면 Ajax는 실지로 많은 기술들이 응집되어 있다. Ajax의 기본을 마치고 넘어가려면 몇 가지 다른 기술들(필자는 첫 번째 이 시리즈에서 각각의 기술에 관해 설명할 것이다.)을 면밀히 살펴보아야 한다. 하지만 이들 기술 가운데 어느 정도 알고 있는 것이 많은 건 다행이다. 더군다나 각각의 기술 대부분은 Java/Ruby같은 프로그래밍 언어만큼 어려운 게 아니라서 배우기 쉽다.

    Ajax 애플리케이션에 포함된 기본기술은 다음과 같다.

  • 웹 양식을 구축하고 애플리케이션 완료 때까지 사용되는 필드를 식별하는 데 HTML을 사용한다.
  • 자바 스크립트 코드는 Ajax 애플리케이션을 실행하는 중심 코드며 서버 애플리케이션과의 커뮤니케이션을 용이하게 한다.
  • DHTML(동적 HTML)은 웹 양식을 동적으로 업데이트 한다. div, span및 기타 동적 HTML 요소를 사용해 HTML을 마크업 한다.
  • 서버에서 복귀된 HTML 및 (때로) XML 구조를 다루는 데 있어 DOM, 즉 문서 객체 모델(Document Object Model)을 사용한다.

    이 기술들에 대해 간략히 요약하고 각 기술의 기능에 대해 좀 더 알아보기로 하는데 각 기술에 관한 자세한 사항은 차후 글에서 다룰 것이다. 우선은 Ajax의 구성요소 및 기술에 대해 친숙해 지는 데 초점을 맞추기로 한다. 자바 스크립트에 익숙할수록 Ajax에 담긴 기술에 관한 일반적인 지식 단계에서 각 기술에 관한 자세한 지식으로 넘어가는 게 더 쉬워진다.(또한 이로 인해 웹 애플리케이션 개발에 관한 문이 열리게 된다.)

     

    Ajax 정의
    Ajax는 비동기 JavaScript 및 XML의 약어이다.(DHTML도 마찬가지다.) Adaptive Path사의 Jesse James Garrett이 이 약어를 만들어냈으며(참고자료 참조), Jesse에 따르면 이 약어는 두문자어는 아니라고 한다.

     

     

     

    XMLHttpRequest 객체

     

    알고자 하는 객체 중 첫 번째는 아마도 가장 생소한 것이 아닌가 싶다. 그 객체는 일명 XMLHttpRequest인데 자바 스크립트 객체의 일종이며 Listing 1에 나와 있는 것처럼 단순하게 생성된다

     

    Listing 1. 새로운 XMLHttpRequest 객체 생성


    <script language="javascript" type="text/javascript">
    var xmlHttp = new XMLHttpRequest();
    </script>

     

    필자는 다음 글에서 이 객체에 대해 더 논의할 것이다. 하지만 지금 상태에서는 모든 서버 커뮤니케이션을 다루는 객체라는 사실만 알아둔다. 다음 사항으로 가기 전에 잠깐 생각해 보면 자바 스크립트 객체는 XMLHttpRequest를 통해 서버에 전달하는 자바 스크립트 기술의 일종이다. 이 객체는 애플리케이션 흐름이 정상적이지 않으며 Ajax 기술의 많은 부분을 차지하고 있다.

    정상적인 웹 애플리케이션에서 사용자는 양식 필드를 기입하며 제출 버튼을 클릭한다. 그러면 전 양식을 서버에 보내며 서버는 처리과정을 통해 양식을 스크립트(일반적으로 PHP, 자바 또는 CGI 과정/이와 유사한 과정)에 전송한다. 스크립트를 실행할 때 스트립트를 통해 완전히 새로운 페이지가 전송된다. 그 페이지는 데이터가 작성된 새로운 양식의 HTML/확인 페이지 또는 원 양식에 기입된 데이터에 근거해 선택된 옵션이 포함된 페이지일 수 있다. 물론, 서버 상의 스크립트/프로그램이 처리되면서 새로운 양식을 다시 보내는 동안 사용자는 대기해야 한다. 서버로부터 데이터를 다시 받을 때까지는 스크린 상에 아무 것도 없게 되며 결국 대화성은 낮게 된다. 사용자는 즉각적으로 응답을 받지 못하며 데스크톱 애플리케이션 상에서 작업하는 기분이 들지 않게 된다.

    Ajax는 근본적으로 자바 스크립트 기술 및 웹 양식 및 서버 간의 XMLHttpRequest 객체를 결합한다. 사용자가 웹 양식을 기입할 때 데이터는 직접 서버 스크립트에 전송되지 않고 자바 스크립트 코드에 전달된다. 대신 자바 스크립트 코드는 양식 데이터를 포착해 Request를 서버에 전송한다. 이 과정이 일어나는 동안, 사용자 스크린 상의 양식은 순식간에 나타나거나 깜빡이거나 사라지거나 정지하지 않는다. 즉 자바 스크립트 코드는 몰래 Request를 전송하며 사용자는 Request가 만들어졌는지도 알지 못한다. 게다가 Request를 비동기적으로 전송하기 때문에 더 좋은 상황이 된다. 이는 자바 스크립트에서 서버 응답을 그냥 대기하지 않는다는 것을 의미한다. 따라서, 사용자는 데이터를 계속 기입하고 화면이동하고 애플리케이션을 사용한다.

    그런 다음 서버는 자바 스크립트 코드(웹 양식에 대해 아직도 대기 중임)에 데이터를 다시 전송한다. 자바 스크립트 코드에서는 데이터와의 상호기능을 결정하며 연속적으로 양식 필드를 업데이트 하면서 애플리케이션에 즉각적인 응답을 준다. 결국 사용자는 양식을 제출/재생하는 작업 없이 새로운 데이터를 얻게 된다. 자바 스크립트 코드는 데이터를 얻고 계산도 수행하며 또 다른 Request를 전송하며 이런 모든 과정은 사용자 개입 없이도 된다! 이것이 바로 XMLHttpRequest 객체의 장점이다. XMLHttpRequest 객체는 서버와 같이 커뮤니케이션을 주고받고 사용자는 그 과정에서 벌어지는 과정을 알지 못한다. 이로 인해 데스크톱 애플리케이션과 마찬가지로 동적, 상호 반응적인 고도의 양방향 경험을 얻게 되지만 그 속에 인터넷의 모든 장점이 담겨 있다.

     

     

    자바 스크립트에 대한 부가사항

     

    일단 XMLHttpRequest에 대해 다루게 되면 나머지 자바 스크립트 코드는 상당히 평범한 것들이다. 사실 다음과 같은 기본적인 작업에 자바 스크립트 코드를 이용한다.

  • 양식 데이터 얻기: 자바 스크립트 코드로 HTML 양식에서 데이터를 꺼내 이를 서버에 전송하는 작업이 간단해진다.
  • 양식 상의 값 변환: 필드 값 설정에서 연속적인 이미지 교체작업에 이르는 양식 업데이트 작업 또한 간단하다.
  • HTML 및 XML 구문분석: 자바 스크립트 코드를 이용해 DOM(다음 섹션 참조)을 처리하고 서버에서 다시 전송하는 HTML 양식 및 임의의 XML 데이터에 관한 구조를 다루게 된다.

    첫 번째 두 항목에 대해서 여러분은 Listing 2에 나온 대로 getElementById()에 익숙해지려 할 것이다.

     

    Listing 2. 자바 스크립트 코드에서의 필드 값 포착 및 설정

    // Get the value of the "phone" field and stuff it in a variable called phone
    var phone = document.getElementById("phone").value;

    // Set some values on a form using an array called response
    document.getElementById("order").value = response[0];
    document.getElementById("address").value = response[1];

     

    Ajax 애플리케이션에서 특별히 획기적인 사항은 없고 상기 사항 정도면 충분하다. 이에 대해 상당히 복잡한 건 없다는 사실을 깨달아야 한다. 일단 XMLHttpRequest만 정복하면 Ajax 애플리케이션에서 나머지는 대부분 Listing 2에 나온 바와 같이 상당히 독창적인 HTML과 결합된 단순 자바 스크립트 코드다. 그런 다음 가끔 약간의 DOM 작업이 발생하게 된다. 이에 관해 살펴 보자.

     

     

    DOM으로 종료하기

     

    DOM, 즉 문서 객체 모델이라는 것이 있는데 이는 아주 중요하다. DOM에 대해 듣는 것은 그다지 어렵지 않다고 하는 사람들이 있다. HTML 디자이너에 의해서는 종종 사용되지 않으며 하이-엔드 프로그래밍 작업으로 들어가지 않는 한은 JavaScript 코더에서 흔치 않은 것이 바로 DOM이다. 종종 과중-업무 Java 및 C/C++ 프로그램 상에서 DOM을 종종 많이 활용하게 된다. 사실은 DOM이 배우기 어려운 특성 때문에 명성이 자자해 그 프로그램 상에서 종종 사용하는 것이 아닌가 싶다.

    다행히도 JavaScript 기술에 있어 DOM을 활용하는 일은 쉽고 대부분 직관적이다. 이 시점에서 필자는 DOM 사용법에 관해 보여 주고 적어도 이에 대한 몇 가지 코드 예를 제시하려 하지만 이 글의 의도와는 벗어나는 것 같다. DOM에 관해 대략적으로 다루는 것 없이도 Ajax에 대해 깊이 다룰 수 있다. 필자는 차후의 글에서 다시 DOM에 관해 다루려 한다. 하지만 지금 상황에서는 언급하지 않으려 한다. JavaScript 코드와 서버 사이에 XML을 이리저리 전송하고 HTML 양식을 변화시킬 때 DOM에 대해 자세히 다루게 될 것이다. 지금은 DOM없이 효과적인 Ajax 애플리케이션을 작동하는 게 쉬우므로DOM은 논외로 한다.

     

     

    Request 객체 얻기

     

    Ajax 애플리케이션에 관한 기본적 개념에 대해 배웠으면 몇 가지 특수사항에 대해 살펴 보자. XMLHttpRequest 객체는 Ajax 애플리케이션에서 중요하므로, 아마도 많은 이들에게는 생소한 것일 수도 있다. 거기서 필자는 논의를 시작한다. Listing 1에서 보다시피, XMLHttpRequest 객체를 생성, 사용하는 것은 상당히 쉬워야 한다. 잠깐만 기다려 보시라.

    수년 동안 브라우저에 관한 논란은 끊이지 않았고 동일한 브라우저로는 아무 것도 얻을 수 없다는 사실을 기억하는가? 믿건 말건, 소규모 브라우저에서도 이와 같은 논쟁은 끊이지 않고 있다. 더군다나 놀라운 사실은 XMLHttpRequest가 이 논란의 희생양 중 하나라는 것이다. 따라서 XMLHttpRequest 객체를 작동시키기 위해선 몇 가지 다른 작업을 해야 한다. 단계별로 설명하겠다.

     

     

    Microsoft 브라우저 다루기

     

    Microsoft 브라우저, Internet Explorer는 XML을 다룰 시 MSXML 구문분석계를 사용한다.(참고자료 참조) Internet Explorer 상에서 다뤄야 할 Ajax 애플리케이션을 작성할 시 독특한 방식으로 XMLHttpRequest 객체를 작성해야 한다.

    하지만 그렇게 간단한 작업은 아니다. Internet Explorer에 설치된 JavaScript 기술 버전에 따라 MSXML 버전도 변하게 되며 실지로 2개의 버전이 있다. 따라서 두 경우를 다루는 코드를 작성해야 한다. Microsoft 브라우저 상에서 XMLHttpRequest 객체를 생성하는 데 필요한 코드에 관해선 Listing 3을 보라.

     

    Listing 3. Microsoft 브라우저 상에서 XMLHttpRequest 객체 생성

    var xmlHttp = false;
    try {
    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e2) {
    xmlHttp = false;
    }
    }

     

    모든 작업이 정확히 맞아떨어지는 것은 아니다. 하지만 그래도 상관없다. 이 시리즈가 끝나기 전에 JavaScript 프로그래밍, 에러 취급 및 조건부 번역 및 기타 사항에 관해 자세히 다루게 될 것이다. 지금 현 상태에서는 두 가지 중심 라인만 다루고자 한다.

     

    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    and
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");.

     

    간단히 말해서, 이 코드로 MSXML의 한 버전을 이용해 XMLHttpRequest 객체 생성을 기한다. 하지만 객체가 생성되지 않는 경우 다른 버전을 사용해 XMLHttpRequest 객체를 생성한다. 두 코드 다 작동되지 않는 경우 xmlHttp 변수는 거짓으로 설정되고 작동되지 않는 것이 있다는 것을 코드에 알려 준다. 그럴 경우, 비-Microsoft 브라우저가 있을 가능성이 있다. 따라서 객체 생성을 위해선 다른 코드를 사용해야 한다.

     

     

    Mozilla 및 Microsoft 브라우저 다루기

     

    인터넷 브라우저를 선택하지 않거나 비-Microsoft 브라우저를 작성할 경우 다른 코드가 필요하다. 사실, 이 라인은 Listing 1에서 봤던 단순 코드라인이다.

     

    var xmlHttp = new XMLHttpRequest object;.

     

    이 단순한 라인으로 Mozilla, Firefox, Safari, Opera 및 임의의 양식/형태에서 Ajax애플리케이션을 지원하는 기타 비-Microsoft 브라우저에서 XMLHttpRequest 객체를 생성한다.

     

     

    지원기능 통합

     

    여기서 모든 브라우저를 지원하는 것이 중요하다. Internet Explorer/비-Microsoft 브라우저에서만 작동되는 애플리케이션을 작성하는 사람이 어디 있겠는가? 또한 더 심한 경우, 애플리케이션을 두 번 작성하고자 하는가? 물론 아니라고 믿는다. 따라서 코드에선 Internet Explorer 및 비-Microsoft 브라우저를 지원하는 기능이 포함되어야 한다. Listing 4에서는 다중-브라우저 방식으로 작동하는 코드에 대해 나와 있다.

     

    Listing 4. 다중 브라우저 방식으로 XMLHttpRequest 객체 생성하기

    /* Create a new XMLHttpRequest object to talk to the Web server */
    var xmlHttp = false;
    /*@cc_on @*/
    /*@if (@_jscript_version >= 5)
    try {
    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e2) {
    xmlHttp = false;
    }
    }
    @end @*/

    if (!xmlHttp && typeof XMLHttpRequest != 'undefined') {
    xmlHttp = new XMLHttpRequest();
    }

     

    지금 현재로선, 주석 및 @cc_on와 같은 어려운 태그를 무시한다. 이들은 다음 글에서 깊이 다룰 JavaScript 컴파일러 명령으로 오로지 XMLHttpRequest 객체 상에만 초점이 맞추어져 있다. 이 코드에 관한 핵심은 세 가지 과정으로 요약된다.

    1. 변수 xmlHttp를 생성해 앞으로 생성할 XMLHttpRequest 객체를 참조한다.
    2. Microsoft 브라우저에서의 객체를 시도, 생성한다.

    • Msxml2.XMLHTTP 객체를 사용해 XMLHttpRequest 객체를 시도, 생성한다.
    • 과정이 실패할 경우, Microsoft.XMLHTTP 객체를 사용해 XMLHttpRequest 객체를 시도, 생성한다.

    3. xmlHttp가 아직도 설정되지 않은 경우 비-Microsoft 방식으로 XMLHttpRequest 객체를 생성한다.

    위 과정 끝 단계 시 사용자가 실행하는 브라우저 종류에 관계없이 xmlHttp의 경우 유효한 XMLHttpRequest 객체를 인용한다.

     

     

    보안

     

    보안이란 무엇인가? 오늘날 브라우저는 사용자들에게 보안 레벨을 올리고 JavaScript 기술을 생성하며 브라우저 옵션을 해제하는 기능을 제공한다. 이 경우 코드가 작동되지 않는 경우도 있을 수 있다. 그 때 발생하는 문제를 적절하게 다뤄야 한다. 이에 관한 내용은 적어도 기사 한 분량을 차지할 정도라 나중에 다루기로 하겠다.(긴 시리즈가 될 것 같다, 그렇지 않은가? 하지만 걱정 마시라. 과정을 다 배우고 나면 이와 관련된 모든 사항을 숙달할 테니까.) 현재로선 강력하지만 완전하지 않은 코드를 작성하는 중이다. 이 코드는 Ajax 애플리케이션을 관리하는 데 좋다.

     

     

    Ajax 세계에서의 Request/Response

     

    인제 Ajax 애플리케이션에 대해 이해하고 XMLHttpRequest 객체 및 객체 생성에 관한 기본적인 개념을 얻는다. 자세히 읽다 보면 Ajax 애플리케이션은 웹 애플리케이션에 제출되는 HTML 양식보단 서버 상의 임의의 웹 애플리케이션에 대화하는 JavaScript 기술이라는 사실을 알게 된다.

    그러면 빠진 부분은 어떤 것인가? 실질적인 XMLHttpRequest 객체 사용법이다. 이 객체는 작성하는 각각의 Ajax 애플리케이션에서 일정 형태로 사용하는 중요 코드라 Ajax 애플리케이션이 포함된 기본 Request/응답 모델 모양을 통해 객체 사용법을 빨리 익힌다.

     

     

    Request 만들기

     

    새로운 XMLHttpRequest 객체가 있는 경우 이를 시험해 보자. 먼저 웹 페이지에서 호출하는 JavaScript 방법이 필요하다.(사용자가 텍스트에서 입력하거나 메뉴에서 옵션을 선택할 시와 같음.) 그 다음, 거의 모든 Ajax 애플리케이션에서의 동일한 기본 아웃라인을 따른다.

    1. 웹 양식으로부터 필요한 모든 데이터 얻기
    2. 연결할 URL 구축
    3. 서버 연결
    4. 서버 실행 종료 시 서버 실행 기능 설정
    5. Request 전송

    Listing 5는 위의 순서대로 5단계를 진행하는 Ajax 방법의 예에 관해 나와 있다.

     

    Listing 5. Ajax가 포함된 Request 만들기

    function callServer() {
    // Get the city and state from the web form
    var city = document.getElementById("city").value;
    var state = document.getElementById("state").value;
    // Only go on if there are values for both fields
    if ((city == null) || (city == "")) return;
    if ((state == null) || (state == "")) return;

    // Build the URL to connect to
    var url = "/scripts/getZipCode.php?city=" + escape(city) + "&state=" + escape(state);

    // Open a connection to the server
    xmlHttp.open("GET", url, true);

    // Setup a function for the server to run when it's done
    xmlHttp.onreadystatechange = updatePage;

    // Send the request
    xmlHttp.send(null);
    }

     

    Ajax 코드에 관한 많은 것이 명백하다. Ajax 코드의 첫번째 비트는 몇 가지 양식 필드 값을 포착하는 기본 JavaScript 코드를 사용한다. 그런 다음 이 코드에서는 연결 최종 목적지로 PHP 스크립트를 설정한다.

    PHP 스크립트의 URL을 지정한 다음(양식에서 나온) 단순한 GET 매개변수를 이용해 이 URL에 도시 및 국가를 추가한다. 그 다음 연결하면 먼저 XMLHttpRequest 객체가 작동되는 것을 보게 된다. 연결방법은 연결 URL 뿐만 아니라, GET 매개변수에도 나와 있다. 최종 매개변수를 true로 설정한 경우, 이 매개변수에선 비동기식 연결(Ajax를 만든다.)을 요구한다. false로 설정한 경우엔 Request를 만들 시 서버 상에서 Ajax에서의 JavaScript 코드가 대기하고 응답을 받을 때 코드가 지속된다. 사용자는 최종 매개변수를 true로 설정하면서 서버에서 배경에 있는 Request를 처리하는 동안 사용자는 웹 양식(심지어는 기타 JavaScript 방식)을 여전히 사용한다.

    한편 xmlHttp(이것은 XMLHttpRequest 객체의 인스턴스라는 사실을 기억하라.)의 onreadystatechange 속성으로 서버 실행이 종료될 시(5분/5시간 내에 종료될 수 있음) 서버 기능을 명령한다. 이 코드는 서버 상에서 대기하지 않기 때문에 서버가 기능을 인식해 서버에 응답할 수 있도록 하는 게 필요하다. 이 경우 서버에서 Request를 처리하면서 종료 시 이른바 updatePage()라 불리는 특수 방법을 트리거한다.

    최종적으로 send() 코드를 0(null) 값으로 호출한다. 데이터를 추가해 이를 서버에 전송하므로 Request에는 추가해서 보낼 게 없다. 이렇게 되면 Request를 발송하고 서버는 서버에 요구된 기능을 실행한다.

    이 코드에서 나오는 것이 없는 경우, 코드가 상당히 간단하다는 것을 명심하라. 이 코드는 Ajax 애플리케이션의 비동기적 특성을 제외하고는 상당히 단순하다. 이 코드를 통해 복잡한 HTTP Request/응답 코드보다는 근사한 애플리케이션 및 인터페이스에 완전 초점을 맞추도록 한다는 사실을 여러분은 높게 평가할 것이다.

    Listing 5의 코드는 코드를 얻는 방법만큼이나 쉽다. 데이터는 단순 텍스트이고 Request URL의 일부로 포함된다. GET 매개변수는 더 복잡한 POST대신 Request를 전송한다. 여기에 덧붙일 XML/컨텐츠 헤더가 없고 Request 본체에 전송할 데이터도 없다. 이게 바로 Ajax 유토피아다.

    그렇다고 미리 겁먹지 마라. 시리즈가 계속될수록 문제는 더 복잡해진다. 그 때는 POST Request를 전송하는 방법, Request 헤더 및 컨텐츠 형식을 설정하는 방법, 메시지에 XML을 설정하는 방법 및 Request에 보안기능을 추가하는 방법을 배우게 되는데 배우는 목록만 해도 상당히 길다! 지금은 이런 어려운 주제에 대해 신경 쓰지 말자! 그냥 기본만 충실하게 익히면 Ajax 전체 툴을 구축하게 된다

     

     

    응답 취급과정

     

    이제 서버 응답을 실지로 취급해야 한다. 이 시점에서는 정말로 두 가지 사항만 알면 된다.

  • xmlHttp.readyState 속성이 4와 같을 때까지는 어떤 작업도 해선 안 된다.
  • 서버는 xmlHttp.responseText 속성에 응답한다.

    2가지 항목 중 첫번째 항목인 준비 상태에 관해선 다음 글에서 대부분 다룰 것이다. 그 때는 HTTP Request 단계에 대해 알고 싶은 것 이상으로 배우게 된다. 지금 현재로선, xmlHttp.responseText 속성 값 4를 단순 점검하는 경우, 작업이 계속 진행된다.(다음 글에서 기대할 만한 사항이 나오게 된다.) 서버 응답을 얻기 위해 xmlHttp.readyState 속성을 사용하는 과정인 두 번째 항목은 쉽다. Listing 6은 Listing 5에서 전송된 값에 근거해 서버에서 호출하는 방법에 관한 예를 보여준다.

     

    Listing 6. 서버 응답 취급하기

    function updatePage() {
    if (xmlHttp.readyState == 4) {
    var response = xmlHttp.responseText;
    document.getElementById("zipCode").value = response;
    }
    }

     

    다시 보면, xmlHttp.readyState 코드는 그리 어렵거나 복잡하지 않다. 이 코드는 서버에서 해당 준비 상태로의 호출을 대기하고 서버에서 다시 복귀되는 값(이 경우, 사용자 기입 도시 및 국가에 대한 ZIP 코드)을 사용해 또 다른 형태의 양식 필드를 설정한다. 그 결과, zipCode 필드는 ZIP 코드와 함께 갑자기 나타난다. 하지만 사용자는 버튼을 클릭해서는 안 된다! 그게 바로 이전에 말했던 데스크톱 애플리케이션이다. Ajax 코드에는 응답성, 동적 상태 외의 더 많은 것이 있다. 독자들은 zipCode가 정상 텍스트 필드라는 것을 눈치챘을지도 모른다.

    일단 서버에서 zipCode를 복귀시키고 updatePage() 방식으로 도시/국가 ZIP 코드와 함께 zipCode 필드 값을 설정하는 경우 사용자는 값을 무효로 한다. 값을 무효로 하는 데는 두 가지 이유가 있다. 예에서 나오는 상황을 단순화시키고, 때로는 사용자가 서버에서 명령하는 것을 무효로 하기 위해서다. 이 두 가지를 명심하라. 좋은 사용자-인터페이스 설계를 위해 중요하다.

     

     

    웹 양식 다루기

     

    그러면 이 글에서 다룰 게 남아 있는가? 그다지 많지 않다. 양식에 기입할 정보를 포착해 이를 서버에 전송하고 응답에 관해 취급할 또 다른 JavaScript 방법을 제공하면서 심지어는 다시 응답될 때 필드 값을 설정하기까지 하는 JavaScript 방법을 다룬다. 여기서는 첫번째 JavaScript 방법을 호출해 전 과정을 시작하기만 하면 된다. 분명 HTTL 양식에 버튼을 추가하지만 2001년 버전과 거의 동일하다고 생각되지 않는가? Listing 7과 같이 JavaScript 기술을 활용한다.

     

    Listing 7. Ajax 프로세스 시작

    <form>
    <p>City: <input type="text" name="city" id="city" size="25"
    onChange="callServer();" /></p>
    <p>State: <input type="text" name="state" id="state" size="25"
    onChange="callServer();" /></p>
    <p>Zip Code: <input type="text" name="zipCode" id="zipCode" size="5" /></p>
    </form>

     

    이런 단면이 루틴 코드의 한 단면 이상을 보여준다고 생각된다면 맞는 말이다. ? 그렇다! 사용자가 도시/국가 필드에 관한 새로운 값을 입력할 경우 callServer() 방식을 전송한 다음 Ajax 애플리케이션이 시작된다. 이제 여러 상황을 다룰 만하다고 느껴지기 시작하는가? 좋다! 바로 그거다!

     

     

    맺음말

     

    이 시점에서 적어도 리소스 란에서 Ajax 애플리케이션에 관해 깊숙이 알려고 하는 경우, 첫번째 Ajax 애플리케이션을 작성할 준비가 되어 있지 않을 게다. 하지만 이런 애플리케이션이 작동하는 기본 개념 및 XMLHttpRequest 객체의 기본 개념을 이해하기 시작한 경우 이 객체, JavaScript-서버 간 대화 취급방식, HTML 양식 취급 및 심지어 DOM 관리 방식까지 모든 것을 배워야 한다.

    지금 현재로선, Ajax 애플리케이션이 얼마나 강력한 툴인지 생각하는 데 시간을 보낸다. 버튼만 클릭할 뿐만 아니라 필드에 입력하고 콤보 상자에서 옵션을 선택하고 심지어는 마우스를 스크린 주위에 끄는 경우 응답하는 웹 형식을 상상해 본다. 비동기식의 정확한 의미 및 Request 상에서 응답하기 위해 서버 상에서 실행하지만 대기하지 않는 JavaScript 코드에 관해 생각해 본다. 여러분이 부딪치는 문제의 종류는 어떤 것인가? 어떤 영역의 문제에 주의를 기울일 것인가? 프로그래밍에 이 새로운 접근방식을 설명하기 위해 양식 설계를 변환하는 방법은 어떤 것인가?

    이런 문제에 관해 실지로 생각할 시간을 보낸다면 잘라 붙이는 코드를 가지고 이를 잘 이해하지 못하는 애플리케이션에 포함시키는 것보다는 훨씬 더 낫다. 다음 글에서는 이와 같은 개념을 실제 작업에 응용해 본 작업에서처럼 애플리케이션을 만들어야 하는 코드에 관한 자세한 정보를 제공하기로 한다. 그 때까지 Ajax 애플리케이션의 가능성을 마음껏 즐겨라.

     

     

    참고자료

    교육
    - Adaptive Path
    - Jesse James Garrett, Ajax.
    - XMLHttpRequest object.
    - Microsoft Developer Network's XML Developer Center.
    - 자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현 (developerWorks, September 2005)
    - 자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화 (developerWorks, October 2005)
    - Using Ajax with PHP and Sajax (developerWorks, October 2005)
    - Call SOAP Web services with AJAX, Part 1: Build the Web services client (developerWorks, October 2005)
    - XML Matters: Beyond the DOM (developerWorks, May 2005)
    - Build apps with Asynchronous JavaScript with XML, or AJAX (developerWorks, November 2005)
    - Ajax for Java developers: Ajax with Direct Web Remoting (developerWorks, November 2005)
    - surveys AJAX/JavaScript libraries.
    - XUL Planet's object reference section details XMLHttpRequest
    - strategy white paper
    - Flickr.com.
    - GMail
    - Head Rush Ajax (O'Reilly Media, Inc., February 2006)
    - JavaScript: The Definitive Guide, 4th Edition (O'Reilly Media, Inc., November 2001)
    - developerWorks Web Architecture zone

    토론
    -포럼에 참여하기.
    -Ajax.NET Professional
    -developerWorks blogs.

     

    사용자 삽입 이미지


    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3052


     

    대부분의 웹 애플리케이션들은 서버에서 전체 HTML 페이지를 얻는 요청/응답 모델을 사용합니다. 다시 말해서, 이 모델은 버튼을 클릭하고, 서버를 기다리고, 또 다른 버튼을 클릭하고, 다시 기다리는 일이 다반사입니다. Ajax와 XMLHttpRequest 객체를 사용하면 서버 응답을 기다리지 않아도 되는 요청/응답 모델을 사용할 수 있습니다.

     

    지난 글(참고자료)에서는 Ajax 애플리케이션에 관한 서론 및 이 애플리케이션에 필요한 몇 가지 기본개념에 대해 알아봤다. 본 글에서는 JavaScript, HTML 및 XHTML, 동적 HTML, 심지어는 몇 가지 DOM(동적 객체 모델) 등 이미 알고 있는 수많은 기술에 대해 중점적으로 다뤘다.

    본 글에서는 모든 Ajax관련 객체 및 프로그래밍 방식의 기초인 XMLHttpRequest 객체에 대해 먼저 다룰 것이다. 이 객체는 모든 Ajax 애플리케이션 전반에 걸쳐 유일한 공통 줄기가 된다. 예상하다시피, XMLHttpRequest 객체를 완전히 이해해서 프로그래밍의 한계에 다다르고자 할 것이다. 사실, XMLHttpRequest 객체를 적절히 이용해도 분명 그 객체를 사용하지 못하는 경우가 있다. 도대체 XMLHttpRequest 객체는 무엇일까?

     

     

    Web 2.0

     

    먼저 코드에 관해 자세히 알아보기 전에 Web 2.0에 관한 개요를 살펴 보면서 확실한 개념을 얻도록 하자. Web 2.0이라는 용어를 들을 때 다음과 같이 " Web 1.0은 무엇입니까?" 라고 물어봐야 한다. Web 1.0에 대해선 거의 들어보지 못했지만 명료한 요청 및 응답 모델이 포함된 전통 웹을 가리켜 Web 1.0이라 한다. 예를 들어 Amazon.com으로 들어가서 버튼을 클릭하거나 탐색 용어를 입력하면 서버에 요청을 생성하고 이에 대한 응답이 브라우저로 다시 보낸다. 그 요청은 책, 타이틀 목록 이상으로 중요하며 실지로 또 다른 완전 HTML 페이지를 만들어낸다. 그 결과 새로운 HTML 페이지가 웹 브라우저 스크린에 다시 나타날 때 플래시/플리커링 현상이 나타나기도 한다. 사실, 각각의 새로운 페이지에서 나오는 요청, 응답을 분명히 알게 된다.

    Web 2.0은 이와 같은 왕복이동 움직임이 상당부분 필요 없다. 예를 들어, Google Maps 또는 Flickr(참고자료)를 방문하면 Google Maps 상에서는 맵을 끌어다가 재 드로잉을 약간만 해도 맵이 축소, 확대된다. 물론, 요청 및 응답은 상상을 초월할 정도로 계속 이루어진다. 이로 인해 사용자로서의 경험은 훨씬 짜릿하며 데스크톱 애플리케이션 상에 있는 것과 같이 느껴진다. 이런 새로운 느낌, 패러다임은 누군가가 Web 2.0에 대해 언급할 때 나오는 현상들이다.

    이와 같이 새로운 상호작용이 가능하도록 하는 방법에 대해 주의를 기울여야 한다. 분명 요청 및 필드 응답을 생성하지만 이로 인해 매 순간 요청/응답 상호작용에 관한 HTML 재 드로잉이 발생돼 느리고 볼품없는 웹 인터페이스를 생성하게 된다. 따라서 사용자가 요청을 생성하고 전반적인 HTML 페이지보다는 필요한 데이터만 포함하는 응답을 수신하는 방식이 필요하다. 사용자가 새로운 페이지를 보고자 할 때가 완전히 새로운 HTML을 얻는 유일한 경우다.

    하지만 대부분의 상호작용으로 인해 상세사항 추가/본문 텍스트 변환/기존 페이지에 데이터 겹쳐쓰기 등이 발생한다. 모든 경우, Ajax 및 Web 2.0방식으로 전체 HTML 페이지를 업데이트하지 않고 데이터를 전송, 수신한다. 이런 기능으로 임의의 수많은 웹 서퍼들은 애플리케이션의 속도가 빨라지고 응답성이 증가하는 것으로 느끼게 되며 상호작용이 반복적으로 이루어지게 된다.

     

     

    XMLHttpRequest

     

    이렇게 새롭고 놀라운 현상이 실지로 발생하기 위해선 XMLHttpRequest라 하는 JavaScript 객체에 관해 완전 익숙해져야 한다. 오랜 시간 동안 몇몇 브라우저에서 사용된 이 객체는 Web 2.0, Ajax 및 앞으로 이 글에서 배우게 될 기타 사항을 이해하는 데 있어 중요한 역할을 하게 된다. 실지로 빠른 이해를 위해 이 객체에서 사용되는 방법 및 속성에 대해 알아보자.

  • open(): 새로운 요청을 서버에 설정함.
  • send(): 요청을 서버에 전송함.
  • abort(): 현 요청에서 벗어남.
  • readyState: 현 HTML 준비상태를 제공함.
  • responseText: 요청에 응답하기 위해 서버에서 재전송하는 텍스트.

    위의 모든 명령을 다 이해하지 못하더라도(중요한 것을 이해하지 못한다 하더라도) 걱정하지 마라. 다음 글에서 각 명령에 대한 방법 및 속성에 관해 배우게 된다. 여기서는 XMLHttpRequest와 관련된 좋은 아이디어를 얻는 게 필요하다.여기서, 각 방법 및 속성은 요청 전송 및 응답 처리와 연관된다는 것을 명심하라. 사실, XMLHttpRequest 객체에 관한 방법, 속성을 다는 알지 못하기 때문에 이들이 매우 간단한 요청/응답 모델과 연관 있다는 것도 모르게 된다. 그래서 놀랍고도 새로운 GUI 객체, 또는 사용자 상호작용을 생성하는 흥미로운 몇 가지 방식 등에 관해서도 배우지 않는다. 별로 재미가 없는 것 같지만 XMLHttpRequest 객체 하나만 잘 사용해도 완전 애플리케이션을 변경할 수 있다.

     

     

    단순함

     

    우선, 새로운 변수를 생성한 다음 이를 XMLHttpRequest객체 인스턴스에 할당한다. JavaScript 상에서는 상당히 간단한 작업이다. 여기서 Listing 1에 보다시피, 객체 이름과 같이 new 키워드를 사용하면 된다.

     

    Listing 1. 새로운 XMLHttpRequest 객체 형성

    <script language="javascript" type="text/javascript">
    var request = new XMLHttpRequest();
    </script>

     

    새로운 객체 형성과정이 그다지 어려운 일은 아니지 않는가? JavaScript에서는 변수 상에 입력하는 과정이 필요 없어 Listing 2(자바에서 XMLHttpRequest 객체를 생성하는 과정)와 같이 값을 전혀 입력할 필요가 없다.

     

    Listing 2. XMLHttpRequest 객체를 생성하기 위한 자바 유사-코드

    XMLHttpRequest request = new XMLHttpRequest();

     

    따라서 JavaScript에서 var로 변수를 생성해 변수에 명칭("request" 등)을 부여한 다음 이를 XMLHttpRequest 객체의 새로운 인스턴스에 할당한다. 이 시점에서 XMLHttpRequest 객체를 사용할 준비가 된 것이다.

     

     

    에러 처리과정

     

    실제 세계에서, 에러가 발생할 수 있어 에러 발생코드는 에러 처리기능을 제공하지 않는다. 따라서 XMLHttpRequest를 생성한 다음 에러가 발생한 경우 이 객체의 기능을 점차 저하시킨다. 일례로, XMLHttpRequest객체를 지원하지 않는 구 브라우저들(믿건 말건, 사람들은 Netscape Navigator의 구 버전을 여전히 이용한다.)이 많아 사용자는 어디서 에러가 났는지 알 필요가 있다. Listing 3은 에러가 난 경우 XMLHttpRequest 객체를 생성하는 방식에 대해 나와 있다. 여기서 XMLHttpRequest 객체로 JavaScript 경고가 발생한다.

     

    Listing 3. 에러 처리기능으로 XMLHttpRequest 객체 생성

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (failed) {
    request = false;
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    </script>

     

    여기서 다음의 각 단계를 반드시 이해한다.

    1.request라는 새 변수를 생성한 다음 이를 거짓으로 설정한다. XMLHttpRequest 객체가 아직 생성되지 않은 상태에서 거짓 값으로 설정한다.
    2. try/catch 블록에서 추가로 다음과 같은 작업을 한다.

    1. XMLHttpRequest 객체를 시험한 다음 생성한다.
    2. 1번 과정이 실패한 경우(catch (failed)), request가 여전히 거짓으로 설정되어 있는지 확인한다.

    3. request가 여전히 거짓으로 설정되어 있는지 확인한다. (에러가 없는 경우, 거짓으로 설정되지 않는다.)
    4. 에러가 발생한 경우(request가 거짓인 경우), JavaScript 경고를 사용해 문제가 발생했다는 사실을 사용자에게 알린다.

    이런 작업은 상당히 간단하다. 실제로 대부분의 JavaScript 및 웹 개발자들은 객체를 읽고 작성하는 것보다는 이해하는 게 더 빠르다. 이제, XMLHttpRequest 객체를 생성하는 일부 에러-증명 코드가 생성되어 에러 여부를 알게 된다.

     

     

    Microsoft로 처리하기

     

    적어도 인터넷 상에서 이 코드를 적용하기 전까지는 이와 같은 작업이 무난하다. 이 코드를 적용하면 그림 1과 같이 에러가 나오게 된다.

    사용자 삽입 이미지

    그림1. 에러화면

    분명, 에러가 발생하고 있다. Internet Explorer는 구식 브라우저가 아니며, 전 세계의 70% 정도가 사용하는 툴이다. 즉, Microsoft 및 Internet Explorer를 지원하지 않는 한 웹 상에서 잘 운영하지 못하게 된다. 따라서 Microsoft 브라우저를 다룰 다른 방식이 필요하다.

    Microsoft는 Ajax를 지원하지만 이전과 다른 XMLHttpRequest 버전을 호출하며 사실은 여러 다른 버전을 호출한다. Internet Explorer의 새로운 버전을 사용하는 경우, Msxml2.XMLHTTP 라 하는 객체를 사용해야 한다. Internet Explorer의 구 버전에서는 Microsoft.XMLHTTP 객체를 사용한다. 그러므로 이와 같은 두 가지 객체 형태를 지원해야 한다. (비-Microsoft 브라우저에 대한 지원기능을 손실하지 않은 상태에서.) 이미 언급한 코드에 Microsoft 지원기능을 추가한 Listing 4를 참조하라.

     

    Microsoft가 잘 작동되는가?
    Ajax에 관해 쓴 글이 많고 Microsoft는 이 영역에 있어 점점 더 관심을 기울이고 있다. 사실 2006년 말에 출시될 것으로 예정된 Microsoft사의 Internet Explorer 최신버전인 버전 7.0은 XMLHttpRequest 객체를 직접 지원해 모든 Msxml2.XMLHTTP 생성코드 대신 new 키워드를 사용한다. 하지만 너무 빠져 들지 마라. 아직도 구 브라우저를 지원해야 하므로 크로스-브라우저 코드는 곧장 사라지지는 않을 전망이다.

     

    Listing 4. Microsoft 브라우저에 지원기능 추가

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    </script>

     

    사실 브라우저에 대한 지원기능이 손실되기 쉽다. 따라서 다음과 같이 단계별로 하길 권한다.

    1. request 명의 새 변수를 생성한 다음 이를 거짓으로 설정한다. XMLHttpRequest 객체가 아직 생성되지 않았다는 전제 하에 거짓으로 설정한다.
    2. try/catch 블록에서 추가로 다음과 같은 작업을 한다.

    1. XMLHttpRequest 객체를 시험한 다음 생성한다.
    2. 1번 과정이 실패한 경우 (catch (trymicrosoft)):
      1. 새로운 Microsoft 버전 (Msxml2.XMLHTTP)을 이용해 Microsoft 호환성 객체를 시험한 다음 생성한다.
      2. 전 과정이 실패한 경우(catch (othermicrosoft)), 이전 Microsoft 버전(Microsoft.XMLHTTP)을 이용해 Microsoft 호환성 객체를 시험한 다음 생성한다.
    3. 그래도 실패한 경우(catch (failed))에는, request가 여전히 거짓으로 설정되어 있는지 확인한다.

    3. request가 여전히 거짓으로 설정되어 있는지 다시 확인한다. (에러가 나지 않는 경우 거짓으로 설정되지 않는다.)
    4. 그래도 문제가 발생한 경우(request가 거짓인 경우), JavaScript 경고를 사용해 사용자에게 문제가 발생했다는 것을 알린다.

    코드를 변화시키고 Internet Explorer 상에서 다시 한 번 시도해 보면 에러 메시지 없이 생성한 형태를 보게 된다. 본인의 경우엔 그와 같은 시도가 그림 2와 같은 것으로 나타난다

    사용자 삽입 이미지

    그림 2. 정상적으로 작동하는 Internet Explorer

     

     

    동적/정적

     

    Listing 1, 3, 4를 다시 보면 모든 코드는 script 태그 내에 직접 포함되어 있다는 것을 알게 된다. JavaScript가 그와 같이 코드화되고 메소드/기능 본체 내에 들어가지 않은 경우, 이를 정적 JavaScript라 한다. 이는 페이지가 스크린 상에 나타나기 전 코드를 실행했다는 것을 의미한다.(코드 및 브라우저가 따로 실행될 경우, 사양과는 100% 일치하지 않지만 사용자와 페이지가 상호작용하기 전, 코드를 실행했다는 건 확실하다.) 일반적으로 그렇게 해서 대부분의 Ajax 프로그래머가 XMLHttpRequest 객체를 생성한다.

    즉, Listing 5처럼, 메소드에 이와 같은 코드를 첨가한다.

     

    Listing 5. XMLHttpRequest 생성코드를 메소드로 이동하기

    <script language="javascript" type="text/javascript">

    var request;

    function createRequest() {
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    }
    </script>

     

    이와 같이 코드를 설정하면, Ajax 작업을 하기 전 이와 같은 메소드를 호출해야 한다. 그럴 경우 Listing 6과 같은 것을 얻을 수도 있다.

     

    Listing 6. XMLHttpRequest 생성 메소드 사용

    <script language="javascript" type="text/javascript">

    var request;

    function createRequest() {
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    }

    function getCustomerInfo() {
    createRequest();
    // Do something with the request variable
    }
    </script>

     

    Listing 6을 활용하면 에러 통지기능을 지연시키므로 대부분의 Ajax 프로그래머들은 위의 방법을 활용하지 않는다. 10/15 필드가 있는 복잡한 형태에 선택상자 등등이 있다고 상상해 보면 사용자가 필드 14에 있는 텍스트를 형식에 나온 대로 기입할 때 몇 가지 Ajax 코드를 전송한다. 이 시점에서 getCustomerInfo()를 실행해 XMLHttpRequest 객체를 생성하려 했지만 실패한다. (이 예에서) 그러면 사용자에게 이 애플리케이션을 사용할 수 없다는 것을 경고로 알리게 된다 (많은 경우). 하지만 사용자는 이미 형식 상에서 데이터를 기입하느라 시간을 보냈다. 상당히 짜증을 내게 되면서 사용자는 결국엔 사이트로 관심을 기울이지 않게 된다.

    정적 JavaScript를 사용하는 경우, 사용자는 페이지에 에러가 나자마자 에러를 포착하게 된다. 또 짜증나는가? 아마도 사용자로선 웹 애플리케이션이 브라우저 상에서 작동되지 않을 때 상당히 죽을 맛일 게다. 하지만, 10분 동안 정보를 기입한 뒤 동일한 에러가 나오는 것보다는 확실히 낫다. 따라서 정적으로 코드를 설정하고 난 다음 발생할 수 있는 문제에 대해 사용자가 조기에 알도록 하는 게 중요하다고 본다.

     

     

    XMLHttpRequest로 요청 전송하기

     

    요청 객체가 있으면 요청/응답 사이클을 시작한다. 여기서 요청을 생성한 다음 응답을 수신하는 게 XMLHttpRequest 객체에서 이루고자 하는 유일한 것임을 명심하라. 사용자 인터페이스 변환, 이미지 교환 및 서버에서 재전송하는 데이터 해석 등의 작업은 페이지에 있는 JavaScript, CSS 또는 기타 코드에서 일어나는 현상이다. XMLHttpRequest 객체가 사용 대기 중일 때 서버에 요청을 생성하게 된다.

     

     

    샌드박스

     

    Ajax는 샌드박스 보안 모델이 포함되어 있다. 그 결과 Ajax 코드(특히 XMLHttpRequest 객체)는 실행 중인 동일한 도메인에만 요청을 생성한다. 다음 글에서 보안 및 Ajax에 관해 더 많은 것을 배우게 되겠지만 지금으로선 로컬 머신 상에서 작동하는 코드만으로도 로컬 머신 상의 서버측 스크립트에 요청을 생성한다는 것을 알게 된다. www.breakneckpizza.com상에서 Ajax 코드를 실행하는 경우, www.breakneckpizza.com상에서 실행하는 스크립트에 관한 요청을 생성한다.

     

     

    서버 URL 설정

     

    여기서 우선 결정할 것은 연결할 서버의 URL이다. URL은 Ajax에서만 있는 것은 아니다. 분명URL을 구성하는 방법에 대해 알아야 한다. 하지만 URL은 연결 설정 시 여전히 필수적인 것이다. 대부분의 애플리케이션에서 사용자가 다루는 형식에서 나온 데이터와 정적 데이터 세트를 결합해 URL을 구성한다. 예를 들어 Listing 7에서는 전화번호 필드의 값을 알아내고 그 데이터를 이용해 URL을 구성하는 JavaScript에 관해 나와 있다.

     

    Listing 7. 요청 URL 구축

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    }
    </script>

     

    여기서 딴지를 걸만한 게 없다. 먼저 여기 나온 코드는 phone 이라는 이름의 새로운 변수를 생성, 이를 "phone"의 ID로 형식 필드 값을 지정한다. Listing 8에는 phone 필드 및 id 속성에서 알 수 있는 특수 형태에 관한 XHTML에 관해 나와 있다.

     

    Listing 8. Break Neck Pizza 형식

    <body>
    <p><img src="breakneck-logo_4c.gif" alt="Break Neck Pizza" /></p>
    <form action="POST">
    <p>Enter your phone number:
    <input type="text" size="14" name="phone" id="phone"
    onChange="getCustomerInfo();" />
    </p>
    <p>Your order will be delivered to:</p>
    <div id="address"></div>
    <p>Type your order in here:</p>
    <p><textarea name="order" rows="6" cols="50" id="order"></textarea></p>
    <p><input type="submit" value="Order Pizza" id="submit" /></p>
    </form>
    </body>

     

    사용자가 전화번호를 입력/변경하는 경우, Listing 8에서 보는 대로 getCustomerInfo() 메소드가 나온다는 사실을 알아둔다. 이 방법으로 전화번호를 알아낸 다음 url 변수에 저장된 URL 문자열을 구성하는 데 활용한다. Ajax 코드는 묶여져 있고 동일한 도메인에만 연결되기 때문에 URL에서 도메인 명칭이 필요 없다는 사실을 명심해야 한다. 이 예에서 스크립트 명칭은 /cgi-local/lookupCustomer.php다. 결국 전화 번호는 상기 스트립트에 Get 매개변수로서 추가된다. ("phone=" + escape(phone))

    이전에 escape() 메소드를 알지 못한 경우, 이 메소드는 정확히 명백한 텍스트로 전송될 수 없는 문자로부터 벗어나는 데 사용된다. 예를 들어, 전화번호에서의 임의의 공간은 %20 문자로 바뀌며 이로 인해 URL과 같이 문자를 전송할 수 있게 된다.

    그런 다음 필요한 많은 매개변수를 추가한다. 예를 들어 또 다른 매개변수를 추가하고자 한다면 URL 상에 추가해 여러 매개변수를 ampersand(&) 문자로 분리시킨다. (첫 번째 매개변수는 의문부호(?)로 스크립트 명칭으로부터 분리되어 있다.)

     

     

    요청 열기

     

    URL이 연결된 상태에서 XMLHttpRequest 객체 상의 open() 메소드를 사용해 요청을 구성한다. 이 메소드는 5가지 매개변수가 있다.

  • request-type: 전송 요청 형태. GET/POST가 일반적인 값이고 HEAD 요청도 전송함.
  • url: 연결된 URL.
  • asynch: 비동기 요청을 설정할 경우 참값, 동기식 요청인 경우에는 거짓임. 이 매개변수는 옵션이고 기본값이 참값임.
  • username: 사용인증을 요구할 경우 사용자이름을 지정한다. 옵션 매개변수고 기본값이 없다.
    password: 사용인증을 요구할 경우 암호를 지정한다, 옵션 매개변수고 기본값이 없다.

    일반적으로 5개의 매개변수 중 3개의 첫 매개변수만 사용한다. 사실, 비동기식 요청을 원할 경우, 제3의 매개변수로 "true"을 설정한다. 그게 기본값 설정이다. 하지만 훌륭한 자체 문서화 작업으로 이 작업을 통해 항상 요청이 비동기식인지 아닌지 여부를 알 수 있다.

    기본값 설정을 완료한 다음 일반적으로 Listing 9와 비슷한 라인으로 작업을 완료한다.

     

    open() 메소드가 열릴까?
    인터넷 개발자들은 open() 메소드의 정확한 기능에 대해 서로 의견이 다르다. 실제로 이 메소드에 없는 기능은 요청 열기 기능이다. 네트워크 및 XHYML/Ajax 페이지와 연결 스크립트 간 데이터 이동을 감시했더라면 open() 메소드 호출 시 트래픽 현상이 발생하지도 않았을 것이다. Open() 명칭이 선택된 이유는 여전히 불분명하지만 분명 훌륭한 명칭선택이라 볼 수는 없다.

     

    Listing 9. 요청 열기

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    }

     

    일단 URL을 이해했으면 그 다음에는 상당히 단순하다. 대부분의 요청의 경우, GET을 사용하는 것만으로도 충분하다. (다음 글에서 POST를 사용하고자 하는 경우를 보게 된다.) URL과 같이 open() 메소드를 사용하기만 하면 된다.

     

     

    비동시성에 대한 문제

     

    이 시리즈의 후반부에서는 비동기식 코드 작성 및 사용에 관한 설명에 할애할 것이다. 하지만 open() 메소드에서 마지막 매개변수가 중요한 이유에 대해 알아야 한다. 정상 요청/응답 모델에서 Web 1.0,을 생각해 보면 클라이언트(로컬 머신 상에서 실행하는 브라우저/코드)는 서버에 요청을 생성한다. 그 요청은 동기식이다. 다시 말하면 클라이언트는 서버로부터의 응답이 올 때까지 대기한다. 클라이언트가 대기 중일 때 일반적으로 적어도 대기 중인 여러 통지 형태 중 하나만 얻으면 된다.

  • Hourglass (Windows 경우에만).
  • 회전 비치볼(일반적으로 Mac 머신에서의 경우임).
  • 애플리케이션은 기본적으로 정지되고 때로 커서가 변환되기도 한다.

    이런 특성으로 웹 애플리케이션은 볼품없거나 느린 것으로 보여진다. 즉 실제 대화성이 부족한 것이다. 버튼을 누르면 트리거된 요청이 응답되기 전까지는 애플리케이션을 사용할 수 없다. 광범위한 서버 처리작업을 요구하는 요청을 생성할 경우 대기시간은 어마어마할 것이다. (적어도 오늘날 멀티 프로세서, DSL, 비대기 세계의 경우처럼.)

    하지만 비동기식 요청은 서버가 응답할 때까지 대기하지 않는다. 요청을 전송한 다음에는 애플리케이션을 계속 실행한다. 사용자는 웹 형식에서 데이터를 기입한 다음 기타 버튼을 클릭하고 형식 기입을 종료한다. 회전하는 비치볼, 소용돌이치는 hourglass 및 대형 애플리케이션 정지 등의 현상이 생기지 않는다. 서버는 재빨리 요청에 응답하고 서버가 종료된 경우, 요청으로 인해 원 요청자는 서버가 종료되었음을 알게 된다. 결국 볼품없고 느린 대신 민감하고 대화성 있고 빠른 애플리케이션을 얻게 된다. 정확한 GUI 구성요소 및 웹 디자인 패러다임만 가지고는 느리고 동기적인 요청/응답 모델의 한계를 극복할 수 없다.

     

     

    요청 전송

     

    일단 open() 메소드로 요청을 구성하고 나면 요청 전송 준비를 한다. 다행히도, 요청을 전송하는 메소드를 open()의 경우에 비해 더 적절하게 명명한다. 명칭은 단순히 send()이다.

    send() 메소드는 단 하나의 매개변수인 전송 컨텐트만 있으면 된다. 그 메소드에 대해 너무 깊게 생각하기 이전에 이미 URL 자체를 통해 데이터를 전송했음을 기억하라.

     

    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);

     

    send() 메소드를 사용해 데이터를 전송하지만 URL자체를 통해서도 된다. 사실, GET 요청(일반 Ajax 이용률의 80%를 이루고 있음.)에서는 URL에서 데이터를 전송하는 게 더 용이하다. 안전한 정보/XML을 전송하기 시작한 경우, send() 메소드를 통한 전송 컨텐트에 대해 알아보려고 할 것이다. (이 시리즈 후반부에 안전한 데이터 및 XML 메시징에 대해 논의한다.) send()를 통해 데이터를 전송하지 않아도 되는 경우, 이 메소드에 대한 인수로 null을 전송하면 된다. 따라서 이 글을 통해 알게 된 예에서 보듯 요청 전송작업을 하는 게 필요하다.(Listing 10)

     

    Listing 10. 요청 전송

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.send(null);
    }

     

     

    콜백 메소드 지정

     

    이 시점에서, 새롭고 혁신적이거나 비동기적이라고 생각될 만한 작업을 거의 하지 못했다. open() 메소드의 키워드 "true"는 비동기식 요청을 설정한다고 하는 게 정확하다. 하지만 그거 말고도 open() 메소드 코드는 Java servlets및 JSP, PHP/Perl이 함께 어우러진 프로그래밍과 유사하다. 그렇다면 Ajax 및 Web 2.0에 담긴 커다란 비밀은 무엇일까? 그 비밀은 onreadystatechange라는 명칭의 XMLHttpRequest의 단순한 속성에서 나오게 된다.

    먼저, open() 코드에서 생성된 과정에 대해 확실히 이해한다.(Listing 10) 요청을 설정하고 생성한다. 게다가 이 XMLHttpRequest는 동기식 요청이라 자바 메소드(예에 나온 getCustomerInfo())는 서버 상에서 대기하지 않는다. open() 코드는 계속 진행되고 이 경우 자바 메소드는 정지되며 제어기능은 형태로 나오게 된다. 사용자들은 계속 정보를 입력하고 애플리케이션은 서버 상에서 대기하지 않는다.

    이렇게 되면 재미있는 질문이 나오게 된다. 서버가 요청 처리 과정을 완료할 시 발생하는 현상은 어떤 것인가? 적어도 코드가 지금 당장 유지되는 한은 아무 현상도 없다 라는 말이 정답이다. 분명 좋은 현상은 아니다. 따라서 서버에 XXMLHttpRequest객체에 의해 전송된 요청에 관한 처리과정을 완료할 경우 서버는 몇 가지 형태의 명령어를 포함해야 한다

    이런 상황에서 바로 onreadystatechange 속성이 작용한다. 이 속성으로 콜백 메소드를 지정한다. 콜백 메소드로 서버는 웹 페이지 코드로 다시 호출한다. 그러면서 서버에 어느 정도의 제어 기능이 전달된다. 또한 서버에서 요청을 종료할 때 콜백 메소드는 XMLHttpRequest 객체, 특히 onreadystatechange 속성에서 나타난다. 그 속성에서 지정된 방법이 어떤 메소드든 모두 호출된다. 웹 페이지 자체에서 벌어지는 현상에 관계없이 웹 페이지로 다시 호출할 때 서버에서 개시하기 때문에 콜백이라 부르는 것이다. 예를 들어, 사용자가 의자에 앉아 키보드를 사용하지 않는 동안 콜백 메소드를 호출하기도 한다. 하지만 사용자가 입력하고 마우스를 움직이고, 화면 이동시키고 버튼을 클릭하는 동안에도 콜백 메소드를 호출하기도 한다. 사용자가 하는 업무는 그다지 중요하지 않다.

    이런 상황에서 비동시성이 작용한다. 사용자는 다른 레벨에 있는 동안 한 레벨에 있는 형식을 작동하고 서버는 요청에 응답한 다음 onreadystatechange 속성에서 명시된 콜백 메소드를 전송한다. 따라서 Listing 11에 나온 대로 코드에 콜백 메소드를 지정해야 한다.

     

    JavaScript에서의 기능 참조
    JavaScript는 약결합 언어며 이 언어에서 모두 다 변수로 참조 가능하다. updatePage()라는 이름의 함수를 선언한 경우, JavaScript는 그 함수 이름을 변수로 취급한다. 즉 updatePage()라는 이름의 변수로 코드에 있는 함수를 참조한다.

     

    Listing 11. 콜백 메소드 설정

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

     

    특히 onreadystatechange 속성이 결정된 코드 위치에 주의를 기울인다. 그 위치는 바로 send()가 호출되기 전의 위치다. 요청을 전송하기 전 onreadystatechange 속성을 설정해야 한다. 그래야만, 서버에서 요청 응답을 종료할 때 onreadystatechange 속성을 탐지하게 된다. 인제는 이 글의 마지막 부분에서 중점적으로 다룰 updatePage() 코드에 대해 알아보겠다.

     

     

    서버 응답 처리

     

    요청을 만들면 사용자는 웹 형식에서 여유롭게 작업하며 (서버에서 요청을 처리하는 동안에는) 서버는 요청 처리과정을 완료한다. 서버는 onreadystatechange 속성에서 나타나며 호출방법을 결정한다. 그런 일이 일어나면 비동기식/동기식 애플리케이션 등의 기타 다른 애플리케이션으로 애플리케이션을 생각할 수도 있다. 즉, 서버에 응답하는 특수 액션 작성 메소드를 취할 필요가 없다. 형식을 변환하고, 사용자를 또 다른 URL에 안내하거나 서버에 응답하는 데 필요한 것들을 하면 된다. 이 단락에서 우리는 서버 응답 및 이에 대한 일반조치 및 사용자가 아는 형식의 일부를 자유롭게 변경하는 것에 대해 중점적으로 다루겠다.

     

     

    콜백 및 Ajax

     

    이미 서버가 종료될 때의 현상을 서버가 인식하는 방법에 대해 이미 알았다. 일단 XMLHttpRequest 객체의 onreadystatechange 속성을 실행함수 이름에 설정한다. 그 다음 서버에서 요청을 처리하면 서버는 자동적으로 그 함수를 호출한다. 또한 콜백 메소드에 있는 임의의 매개변수에 대해 그리 걱정하지 않아도 된다. Listing 12와 같이 단순한 메소드에서 시작하기 때문이다.

     

    Listing 12. 콜백 메소드 코드화

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

    function updatePage() {
    alert("Server is done!");
    }
    </script>

     

    이렇게 하면 간단한 경고가 울리면서 서버가 종료될 때를 알려준다. 자체 페이지에 updatePage() 코드를 시험하고 페이지를 저장한 다음 브라우저에 페이지를 끌어올린다.(이 예에서 XHTML을 원할 경우, Listing 8을 참조한다.) 전화번호를 입력하고 필드를 설정하지 않을 경우 경고는 팝업되어야 한다. 하지만 확인을 클릭한 경우에도 경고는 팝업을 연속한다.

    사용자 삽입 이미지

    그림 3. 경고를 팝업하는 Ajax 코드

    브라우저에 ‘따라 웹 형식에서 경고 팝업을 중지할 때까지 경고가 두 번, 세 번, 심지어는 네 번까지 울린다. 그러면 무슨 일이 벌어지고 있는 것인가? 요청/응답 사이클의 중요 구성요소인 HTTP 준비상태에 대해 고려하지 않았다.

     

     

    HTTP 준비 상태

     

    초기에 필자는 서버에서 요청이 종료되면 XMLHttpRequest의 onreadystatechange 속성에서 호출되는 메소드를 탐지한다고 가르쳤다. 사실, HTTP 준비 상태가 변할 때마다 서버에서는 방금 전에 언급한 메소드를 호출한다. 그러면 그 말이 의미하는 것은 무엇인가? 일단 먼저 HTTP 준비상태에 관해 이해해야 한다.

    HTTP 준비상태는 요청의 상태를 나타내며 주로 요청을 시작했는지, 요청에 응답했는지, 요청/응답 모델을 완성했는지 여부를 결정하는 데 활용된다. HTTP 준비상태는 서버에서 공급되는 모든 응답 텍스트/데이터를 읽어 들이는 데 안전한지 여부를 결정하는 데 도움이 되기도 한다. 여기서 Ajax 애플리케이션에서의 5가지 준비상태에 관해 알아야 한다.

  • 0: 요청이 개시되지 않음.(open()을 호출하기 전)
  • 1: 요청을 설정했지만 전송되지는 않았음.(send()를 호출하기 전)
  • 2: 요청을 설정한 다음 처리 중(이 시점에서 일반적으로 응답에서 나온 컨텐트 헤더를 얻는다.)
  • 3: 요청 처리 중; 종종 응답에서 부분적인 데이터를 사용할 수 있다. 하지만 서버는 자체 응답이 완료되지 않았다.
  • 4: 응답 완료. 서버 응답을 얻은 다음 이를 활용한다.

    거의 모든 크로스-브라우저 이슈에서도 그렇듯 예상치 못한 방식으로 이와 같은 준비 상태를 이용한다. 준비상태는 항상 0~1, 2, 3, 4로 단계적으로 이동한다고 예상할지도 모른다. 하지만 실지로는 그렇지 않다. 0/1상태를 보고하지 않고 곧바로 2로 건너뛰어 3,4까지 가는 브라우저도 있고 모든 상태를 보고하는 브라우저도 있다. 지난 단락에서 보듯, 서버에서는 몇 번이고 updatePage()코드를 호출하고 호출 때마다 경고 상자가 팝업된다. 그건 여러분이 의도하는 바가 아닐 것이다!

    Ajax 프로그래밍의 경우, 직접 다뤄야 할 상태는 오로지 상태 4다. 이는 서버 응답이 완료되었고 응답 데이터를 점검, 사용하는 데 안전하다는 것을 의미한다. 이를 설명하기 위해 콜백 메소드에 나온 첫 번째 라인은 Listing 13에서 나온 바여야 한다.

     

    Listing 13. 준비상태 점검

    function updatePage() {
    if (request.readyState == 4)
    alert("Server is done!");
    }

     

    이런 변환으로 서버가 정말로 그 과정을 종료했는지 확인한다. Ajax 코드의 이 버전을 실행한다. 그러면 한 번에 경고 메시지만을 얻어야 한다.

     

     

    HTTP 상태 코드

     

    Listing 13에서의 코드의 성공에도 불구하고 여전히 문제는 상존한다. 그러면 서버가 요청에 응답하고 요청 처리과정을 완료했지만 에러를 보고한 경우는 어찌 되는가? Ajax, JSP, 정규 HTML 형식 또는 기타 형태의 코드로 서버측 코드를 호출 중인 경우에 서버측 코드를 관찰해야 한다는 점을 주목한다. 웹 세계에서는 HTTP 코드로 요청에서 발생할지도 모르는 여러 가지 상황을 다룬다.

    예를 들어, URL에 관한 요청을 입력했지만, URL을 부정확하게 입력해 404 에러코드가 나와 페이지가 없어졌다고 해보자. 이 코드는 HTTP 요청을 상태로 수신하는 여러 상태 코드 가운데 하나에 지나지 않는다.(참고자료) 403, 401 코드는 둘 다 안전하거나 금지된 데이터 처리를 의미하는 것으로 역시 공통적이다. 각 경우에 있어 이런 코드들은 완전 응답에서 나오는 코드들이다. 즉, 서버는 요청을 수행하지만(HTTP 준비상태는 4임), 클라이언트가 예상한 데이터가 나오지 않을 수도 있다.

    여기서 준비 상태에 덧붙여, HTTP 상태를 점검할 필요가 있다. 단순히 확인을 의미하는 상태코드 200을 탐색하는 중에 있다. 준비상태 4와 상태코드 200인 상태에서 서버 데이터를 처리할 준비가 되어 있고 그 데이터는 반드시 요청된 형태여야 한다. (에러 또는 문제가 있는 정보 단편이 아님.) Listing 14에서 보듯이 콜백 메소드에 또 다른 상태 점검기능을 추가한다.

     

    Listing 14. HTTP 상태 코드 점검

    function updatePage() {
    if (request.readyState == 4)
    if (request.status == 200)
    alert("Server is done!");
    }

     

    복잡성을 줄이고 더 강력한 에러 처리기능을 추가하려면 기타 상태코드에 관한 점검기능/두 가지 기능을 추가할지도 모른다. Listing 15에 있는 updatePage()의 수정 버전을 점검한다.

     

    Listing 15. 간단한 에러 점검기능 추가

    function updatePage() {
    if (request.readyState == 4)
    if (request.status == 200)
    alert("Server is done!");
    else if (request.status == 404)
    alert("Request URL does not exist");
    else
    alert("Error: status code is " + request.status);
    }

     

    이제 getCustomerInfo()에 있는 URL을 비실제 URL로 변환시킨 다음 일어나는 현상을 보면 요청한 URL은 존재하지 않는다는 의미의 경고가 울린다. 이런 경고 가지고도 모든 에러상태를 거의 처리하지 않는다. 하지만 웹 애플리케이션에서 발생할 수 있는 문제의 80%는 해결하는 단순한 진전이 아닐 수 없다.

     

     

    응답 텍스트 읽기

     

    인제 요청을 준비상태를 통해 완전히 처리하고, 서버로 정상적인 확인 응답을 상태 코드를 통해 받았으므로 서버에서 재전송되는 데이터를 최종적으로 처리한다. 이 데이터는 XMLHttpRequest객체의 responseText 속성에 저장된다.

    포맷/길이에 의한 responseText 속성의 텍스트 모양에 관한 상세사항은 이 장에서는 논하지 않기로 한다. 이렇게 되면 서버는 이 텍스트를 실지로 임의로 설정한다. 예를 들어, 한 스크립트로 콤마-분리 값 및 파이프-분리 값이 나오고 또 다른 파이프-분리 값은 텍스트의 긴 문자열로 나올 수도 있다. 이런 현상은 서버에 따라 다르게 된다.

    이 글에서 사용된 예의 경우, 서버는 파이프 기호로 분리된 고객의 마지막 순서 및 주소가 나오게 된다. 형식의 구성요소 값을 설정하는 데 순서 및 고객의 마지막 순서 및 주소를 활용한다. Listing 16은 디스플레이를 업데이트하는 코드에 대해 나와 있다.

     

    Listing 16. 서버 응답 처리

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "");
    } else
    alert("status is " + request.status);
    }
    }

     

    우선 JavaScript split() 메소드를 이용해 파이프 기호 상에서 responseText를 얻고 분할한다. 값은 response의 형태로 배열된다. 고객의 마지막 순서에 관한 첫 번째 값은 response[0] 형태의 배열로 처리되고 "순서" ID와 함께 필드 값으로 설정된다. response[1]에서 두 번째 값은 고객 주소로 처리하는 데 좀 더 오랜 시간이 걸린다. 주소 라인은 정상 라인 분리자("\n" 문자) 로 분리되기 때문에 코드는 정상라인 분리자를 XHTML-형 라인 분리자(< br />)로 바꾸어야 한다. 정규 식 및 replace() 함수의 활용을 통해 분리자를 바꾸는 과정이 이루어진다. 결국 변경 텍스트는 HTML 형태에서 div 의 내부 HTML로 설정된다. 결국 그림 4에도 나오듯이 텍스트 형식은 순식간에 고객정보로 업데이트된다.

    사용자 삽입 이미지

    그림 4. 고객 데이터 검색 후의 Break Neck 형식

     

    이 글을 마치기 전에 XMLHttpRequest 객체의 중요한 속성 중 하나인 responseXML 속성에 대해 언급한다. 이 속성은 서버가 XML과의 응답을 선택한 경우, XML 응답을 포함한다. (상상이 되는가?) XML 응답 처리는 평범한 텍스트 처리과정과 상당히 다르며, 문장분석 및 문서 객체 모델(DOM)을 포함한다. 다음 글에서는 XML에 대해 다루게 된다. responseXML 은 공통적으로 responseText과 관련된 논의에서 나오기 때문에 언급할 가치가 있는 것이다. 많은 단순 Ajax 애플리케이션의 경우, responseText만 있으면 된다. 하지만 Ajax 애플리케이션을 통해 XML을 처리하는 방법에 대해서도 곧 배우게 된다.

     

     

    맺음말

     

    XMLHttpRequest 객체에 대해서는 인제 좀 지루하게 들릴지도 모른다. 필자는 단일 객체, 특히 간단한 객체에 대한 전반적인 글을 거의 읽지 못했다. 하지만 Ajax를 사용하고 작성하는 각 페이지 및 애플리케이션에서 계속 XMLHttpRequest 객체를 사용하게 된다. 아직도 XMLHttpRequest 객체에 대해 언급되지 않은 것들이 많은 건 사실이다. 다음 글에서는 요청에서 GET 및 POST를 사용하고 서버로부터의 응답 및 요청의 컨텐트 헤더를 설정하고 읽어들이는 방법을 배운다. 그러면 요청을 코드화하고 심지어는 요청/응답 모델에서 XML을 다루는 방법을 배우게 될 것이다.

    좀 더 상세하게 나가면 일반적으로 사용하는 Ajax 툴킷에 관해서도 알게 된다. 이 툴킷은 본 글에서 논의된 상세사항의 대부분을 실지로 요약한 것이다. 한편 툴킷을 손쉽게 이용하는 경우, 낮은 레벨의 상세사항을 코드화하는 이유에 대해 궁금해할 수도 있다. 사실은 애플리케이션 상에서 발생하는 현상을 이해하지 못하는 경우, 애플리케이션에서 일어나는 에러를 이해하는 게 어려워진다.

    따라서, 이와 같은 사항을 간과하거나 지나치면 안 된다. 가변성 툴킷에서 에러가 발생할 경우, 머리를 끄적이면서 e-메일을 보내지 않아도 된다. 직접 XMLHttpRequest 사용법을 이해하면 가장 이상한 문제를 디버그하고 수정하는 것도 쉬워진다. 툴킷에 집중하면서 모든 문제를 해결하지 않는 한 툴킷은 그런대로 괜찮다.

    따라서, XMLHttpRequest 객체에 대해 친숙해져라. 사실, 툴킷을 사용하는 Ajax 코드를 실행할 경우 XMLHttpRequest 객체 및 속성, 메소드를 사용해Ajax 코드를 재작성한다. 상당히 좋은 연습이 될 것이며 현재 이 객체에서 벌어지는 현상에 대해 더 잘 이해하게 될 것이다.

    다음 글에서는 XMLHttpRequest에 대해 좀 더 자세하게 들어간다. 이 객체에서 어려운 속성(responseXML등의), POST 요청 사용법 및 몇 가지 다른 포맷에서의 데이터를 전송하는 방법을 조사할 것이다. 한 달 동안 코드화 작업을 시작해 코드를 다시 점검한다.

     

    참고자료

    교육
    - Ajax 마스터, Part 1: Ajax 소개 (developerWorks, December 2005)
    - 자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현 (developerWorks, September 2005)
    - 자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화 (developerWorks, October 2005)
    - Call SOAP Web services with Ajax (developerWorks, October 2005)
    - Google GMail
    - Flickr
    - Ajax: A New Approach to Web Applications
    - Why Ajax Matters Now
    - Microsoft Developer Network's XML Developer Center.
    - online documentation.
    - HTTP status codes
    - developerWorks Web Architecture zone

    제품 및 기술 얻기
    - Head Rush Ajax by Elisabeth Freeman, Eric Freeman, and Brett McLaughlin (February 2006, O'Reilly Media, Inc.)
    - Java and XML, Second Edition by Brett McLaughlin (August 2001, O'Reilly Media, Inc.)
    - JavaScript: The Definitive Guide by David Flanagan (November 2001, O'Reilly Media, Inc.)
    - Head First HTML with CSS & XHTML by Elizabeth and Eric Freeman (December 2005, O'Reilly Media, Inc.)

    토론
    -포럼에 참여하기.
    -developerWorks blogs.

     

     

    사용자 삽입 이미지


    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3054


     

    많은 웹 개발자들에게 간단한 요청을 만들고 간단한 응답을 받는 것은 사실 그들이 필요로 하는 전부이다. 하지만 Ajax를 마스터하고자 하는 개발자들에게는 HTTP 상태 코드, 준비 상태, XMLHttpRequest 객체에 대한 완벽한 이해가 필요하다. Brett McLaughlin은 다양한 상태 코드들을 보여주고 브라우저가 이들 각각을 핸들하는 방법을 설명한다. 비교적 덜 사용되는 HTTP 요청에 대해서도 설명한다.

     

    지난 글에서는 , XMLHttpRequest 객체에 대해 구체적으로 소개했다. 이것은 서버측 애플리케이션이나 스크립트에 대한 요청을 핸들하고, 서버측 컴포넌트에서 리턴 데이터를 처리하는 Ajax 애플리케이션의 주요 특징이다. 모든 Ajax 애플리케이션은 XMLHttpRequest 객체를 사용하기 때문에 Ajax 애플리케이션의 작동은 여기에 얼마나 익숙해지냐에 달려있다.

    이번에는 지난 글에서 다루었던 기초를 넘어서 요청 객체의 세 가지 핵심 부분들에 대해 자세히 설명하겠다.

  • HTTP 준비 상태
  • HTTP 상태 코드
  • 요청 유형들

    이들 각각은 요청이라는 배관의 일부로 간주된다. 결국, 작은 상세가 이러한 주제들에 대해 기록된다. 하지만 Ajax 프로그래밍을 염두하고 있다면 준비 상태, 상태 코드, 요청에 익숙해 져야 한다. 애플리케이션에서 무엇인가 잘못되고 있다면 준비 상태, HEAD 요청을 하는 방법, 또는 400 상태 코드가 의미하는 것이 무엇인지를 이해하면 5분의 디버깅으로 끝낼 수 있거나 5시간 동안 좌절과 혼돈 속에서 방황할 수 있다.

    HTTP 준비 상태 먼저 보도록 하자.

     

     

    HTTP 준비 상태

     

    지난 글에서 XMLHttpRequest 객체는 readyState 라는 속성을 갖고 있다고 설명했다. 이 속성은 서버가 요청을 완료하고 콜백 함수가 그 서버에서 온 데이터를 사용하여 웹 폼이나 페이지를 업데이트 하도록 한다. Listing 1은 이것에 대한 예제이다.(참고자료 참조)

     

    Listing 1. 콜백 함수에서 서버의 응답 처리하기

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "< br />");
    } else
    alert("status is " + request.status);
    }
    }

     

    XMLHttpRequest 또는 XMLHttp: 또 다른 이름의 장미
    Microsoft™와 Internet Explorer는 Mozilla, Opera, Safari, 비 Microsoft 계열 브라우저에서 사용되는 XMLHttpRequest 객체 대신 XMLHttp 라는 객체를 사용한다. 단순하게 하기 위해서 이 두 가지 객체 모두 XMLHttpRequest로 칭하기로 한다. 웹을 검색하다 보면 이런 경우가 비일비재 하고 마이크로소프트도 Internet Explorer 7.0의 요청 객체의 이름으로 XMLHttpRequest를 사용하고 있다. ("JavaScript와 Ajax를 이용한 비동기식 요청" 참조)

     

    이것은 전형적인 준비 상태의 사용법이다. "4"라는 숫자에서 짐작하듯 여러 가지 다른 준비 상태들이 있다.(참고자료 참조)

  • 0: (open()을 호출하기 전에는) 요청이 초기화 되지 않는다.
  • 1: (send()를 호출하기 전에는) 요청은 설정은 되지만 보내지지 않는다.
  • 2: 요청이 보내지고 처리 중에 있다. (이 시점에서 응답에서 콘텐트 헤더를 얻을 수 있다.)
  • 3: 요청이 처리 중에 있다. 부분적인 데이터를 응답에서 사용할 수 있지만 서버는 이 응답으로는 종료되지 않는다.
  • 4: 응답이 완료된다. 서버의 응답을 받고 이를 사용한다.

    Ajax 프로그래밍의 기초 이상으로 넘어가고 싶다면 이러한 상태 뿐만 아니라 이들이 언제 발생하고 어떻게 사용하는지에 대해 알아야 한다. 우선, 가장 중요한 것은 어떤 요청 상태가 될 것인지를 배워야 한다. 이는 별로 기분 좋은 일이 아니고 몇 가지 특별한 경우가 포함되어 있다.

     

     

    숨어있는 준비 상태

     

    readyState 0 (readyState == 0)으로 표시되는 첫 번째 준비 상태는 초기화 되지 않은 요청을 나타낸다. 요청 객체에 대해 open()을 호출하면 속성은 1로 설정된다. 대부분 요청을 초기화 하면서 open()을 호출하기 때문에 readyState == 0을 보는 일은 드물다. 더욱이 초기화 되지 않은 준비 상태는 실제 애플리케이션에서는 쓸모 없다.

    Listing 2를 보면 0으로 설정된 준비 상태가 되는 방법을 알 수 있다.

     

    Listing 2. 준비 상태 0

    function getSalesData() {
    // Create a request object
    createRequest();
    alert("Ready state is: " + request.readyState);

    // Setup (initialize) the request
    var url = "/boards/servlet/UpdateBoardSales";
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

     

    이 간단한 예제에서 getSalesData()는 웹 페이지가 요청을 시작하기 위해 호출하는 함수이다. (예를 들어, 버튼이 클릭 될 때.) open()이 호출되기 전에 준비 상태를 체크 해야 한다. 그림 1은 이 애플리케이션을 실행한 결과이다.

    사용자 삽입 이미지

    그림 1. 준비 상태 0

    분명히 이것은 좋지 않다. open()이 호출되지 않았다는 것을 확인해야 한다. 실제 Ajax 프로그래밍에서 이러한 준비 상태의 유일한 사용은 다중 함수들에 같은 XMLHttpRequest 객체를 사용하여 다중 요청을 만드는 경우이다. 그러한 상황에서, 여러분은 요청 객체가 새로운 요청을 만들기 전에 초기화 되지 않은 상태(readyState == 0)에 있다는 것을 확인해야 한다. 이로서 또 다른 함수가 동시에 객체를 사용하는 것을 방지할 수 있다.

     

     

    진행중인 요청의 준비 상태 보기

     

    0 준비 상태 외에 요청 객체는 전형적인 요청 응답에서 또 다른 준비 상태를 경험하게 된다. 그리고 마지막으로는 준비 상태 4로 끝난다. 이 때는 대부분의 콜백 함수에서 if (request.readyState == 4)가 된다. 서버가 완료되고 웹 페이지를 업데이트 하거나 서버에서 받은 데이터를 기반으로 액션을 취하는 시기이다.

    프로세스를 실제로 보는 것은 간단하다. 준비 상태가 4 라면 콜백에서 단순히 코드를 실행시키는 것 대신 콜백이 호출될 때 마다 준비 상태를 출력한다.(Listing 3)

     

    Listing 3. 준비 상태 점검

    function updatePage() {
    // Output the current ready state
    alert("updatePage() called with ready state of " + request.readyState);
    }

     

    0이 4와 같을 때
    다중 JavaScript 함수들이 같은 요청 객체를 사용하는 경우, 그 요청 객체가 사용되고 있지 않다는 것을 확인하기 위해 준비 상태 0을 확인하면 문제가 많아질 수 있다. readyState == 4는 완료된 요청을 나타내기 때문에, 4로 설정된 준비 상태인 채로 사용되지 않은 요청 객체를 종종 보게 된다. abort()이라고 하는 요청 객체를 리셋하는 함수가 있지만 이는 여기에 사용하는 것이 아니다. 다중 함수들을 사용해야 한다면 다중 함수에 객체를 공유하는 것 보다 각 함수용 요청 객체를 생성 및 사용하는 것이 낫다.

     

    이것이 어떻게 실행되는지 확실히 모르겠다면 웹 페이지에서 호출할 함수를 만들고 서버측 컴포넌트로 요청을 보내도록 한다.(Listing 2) 요청을 설정할 때 콜백 함수를 updatePage()로 설정한다. 요청 객체의 onreadystatechange 속성을 updatePage()로 설정한다.

    이 코드는 onreadystatechange가 정확히 무엇을 의미하는지 잘 보여주고 있다. 요청의 준비 상태가 변할 때 마다 updatePage()가 호출되고 경고를 받는다. 그림 2는 호출되는 함수의 샘플이다. 이 경우 준비 상태는 1이다.

    사용자 삽입 이미지

    그림 2. 준비 상태 1

    코드를 직접 실행해 보라. 웹 페이지에 넣고 이벤트 핸들러를 활성화 한다. (버튼을 누르거나, 요청을 실행하기 위해 설정하는 모든 메소드를 사용하라.) 콜백 함수는 여러 번 실행될 것이다. 요청의 준비 상태가 변할 때 마다 각 준비 상태에 대한 경고를 보게 된다. 이는 각 단계를 통해 요청을 따라가는 최상의 방법이다.

     

     

    브라우저 차이

     

    이 프로세스에 대해 기본적인 개념이 쌓였다면 여러 가지 다양한 브라우저에서 웹 페이지로 액세스 해보라. 준비 상태가 처리되는 방식에 차이가 있을 것이다. 예를 들어, Firefox 1.5에서, 준비 상태는 다음과 같다.

    • 1
    • 2
    • 3
    • 4

    요청의 각 단계들이 다 나타나기 때문에 놀랍지도 않다. 하지만 Safari를 사용하여 같은 애플리케이션에 액세스 하면 재미있는 것을 발견하게 된다. 다음은 Safari 2.0.1에서 보게 되는 상태이다.

    • 2
    • 3
    • 4

    Safari는 첫 번째 준비 상태를 배제하고 그 이유에 대해서는 자세히 나와있지 않다. 바로 이것이 Safari 방식이다. 또한 중요한 포인트이기도 하다. 서버에서 데이터를 사용하기 전에 요청의 준비 상태가 4라는 것을 확인하는 것은 좋은 생각인 반면 일시적인 준비 상태에 의존하는 코드를 작성하는 것은 다른 브라우저 마다 다른 결과를 얻을 수 있는 확실한 방법이다.

    예를 들어, Opera 8.5를 사용할 때 상황은 더 악화된다.

    • 3
    • 4

    Internet Explorer는 다음과 같은 상태로 반응한다.

    • 1
    • 2
    • 3
    • 4

    요청과 관련하여 문제가 있다면 문제의 원인을 찾을 수 있는 첫 번째 장소이다. 요청의 준비 상태를 보여주는 경고를 추가하여 상황이 정상적으로 돌아가는지를 확인할 수 있다. Internet Explorer와 Firefox 모두 테스트 하면 네 개의 모든 준비 상태를 얻을 수 있고 각 요청 단계를 검사할 수 있다.

    이제는 응답 쪽을 살펴보도록 하자.

     

     

    응답 데이터

     

    요청 동안에 다양한 준비 상태가 발생할 수 있다는 것을 이해했다면 XMLHttpRequest객체의 또 다른 중요한 부분에 대해 살펴보도록 하자. 바로 responseText 속성이다. 이것은 서버에서 데이터를 얻을 때 사용되는 속성이다. 서버가 요청 처리를 완료하면 그 요청에 응답하는데 필요한 데이터를 요청의 responseText에 둔다. 그런 다음 콜백 함수가 그 데이터를 사용한다.(Listing 1과 Listing 4 참조)

     

    Listing 4. 서버에서 응답 사용하기

    function updatePage() {
    if (request.readyState == 4) {
    var newTotal = request.responseText;
    var totalSoldEl = document.getElementById("total-sold");
    var netProfitEl = document.getElementById("net-profit");
    replaceText(totalSoldEl, newTotal);

    /* Figure out the new net profit */
    var boardCostEl = document.getElementById("board-cost");
    var boardCost = getText(boardCostEl);
    var manCostEl = document.getElementById("man-cost");
    var manCost = getText(manCostEl);
    var profitPerBoard = boardCost - manCost;
    var netProfit = profitPerBoard * newTotal;

    /* Update the net profit on the sales form */
    netProfit = Math.round(netProfit * 100) / 100;
    replaceText(netProfitEl, netProfit);
    }

     

    Listing 1은 매우 간단하다. Listing 4는 좀 더 복잡하다. 시작하려면 준비 상태를 검사하고 responseText 속성에서 값을 얻어야 한다

     

     

    요청하는 동안 응답 텍스트 보기

     

    준비 상태와 마찬가지로 responseText 속성의 값은 요청의 수명 주기에 걸쳐 변화한다. Listing 5의 코드를 사용하여 요청의 응답 텍스트를 테스트한다. 준비 상태도 마찬가지로 테스트 한다.

     

    Listing 5. responseText 속성 테스트 하기

    function updatePage() {
    // Output the current ready state
    alert("updatePage() called with ready state of " + request.readyState +
    " and a response text of '" + request.responseText + "'");
    }

     

    브라우저에서 웹 애플리케이션을 열고 요청을 활성화 한다. 이 코드를 최대한 활용하려면 Firefox나 Internet Explorer를 사용한다. 이 두 개의 브라우저는 요청 동안 모든 준비 상태들을 보고하기 때문이다. 준비 상태 2에서 responseText 속성은 정의되지 않는다.(그림 3) JavaScript 콘솔이 열려있었다면 에러가 생겼을 것이다.

    사용자 삽입 이미지

    그림 3. 준비 상태 2의 응답 텍스트

    준비 상태 3에서, 서버는 responseText 속성에 값을 배치한다.(그림 4)

    사용자 삽입 이미지

    그림 4. 준비 상태 3의 응답 텍스트

    준비 상태 3의 응답은 스크립트 마다, 서버 마다, 브라우저 마다 다르다. 애플리케이션을 디버깅 하는데 매우 유용하다.

     

     

    안전한 데이터 얻기

     

    모든 문서와 스팩들에서는 준비 상태가 4가 되어야지만 데이터를 안전하게 사용할 수 있다고 나와있다. 나를 믿으라. 준비 상태가 3일 때에도 responseText 속성에서 데이터를 얻을 수 있다. 하지만 여러분의 애플리케이션에서 이것에 의존하는 것은 좋지 않은 생각이다. 준비 상태 3에서 완전한 데이터에 의존하는 코드를 작성하는 것은 데이터가 불완전하다는 증거이다.

    준비 상태가 3일 때 사용자에게 피드백을 제공하는 것이 좋은 생각이다. alert() 같은 함수를 사용하는 것은 좋지 않다. Ajax를 사용하고 사용자와 경고 다이얼로그 박스를 차단시키는 것은 좋지 않지만 준비 상태가 변할 때 마다 폼이나 페이지에 대한 필드를 업데이트 할 수 있다. 예를 들어, 프로그레스 인디케이터의 넓이를 준비 상태 1에 25 퍼센트, 준비 상태 2에 50 퍼센트, 준비 상태 3에 75 퍼센트, 준비 상태 4에 100 퍼센트를 설정한다.

    물론 알다시피, 이 방식은 좋기는 하지만, 브라우저에 의존적이다. Opera에서는 첫 번째 두 개의 준비 상태를 결코 얻지 못하고 Safari는 처음 1 상태를 누락시킨다.

    이제 상태 코드에 대해 알아보자.

     

     

    HTTP 상태 코드

     

    Ajax 프로그래밍 기술에서 준비 상태와 서버의 응답 외에도, Ajax 애플리케이션에 또 다른 고급 레벨을 추가할 수 있다. 바로 HTTP 상태 코드이다. 이 코드들은 Ajax에서는 새우울 것이 없다. 웹에 있는 한 언제나 존재하는 것들이다. 웹 브라우저를 통해 이들을 보았을 것이다.

    • 401: Unauthorized
    • 403: Forbidden
    • 404: Not Found

    이 외에도 더 있다.(참고자료) Ajax 애플리케이션에 또 다른 제어 및 응답 레이어를 추가하려면 요청과 반응에 상태 코드를 검사해야 한다.

     

    200: Everything is OK

    많은 Ajax 애플리케이션에서 준비 상태를 점검하고 서버 응답으로 온 데이터로 작업하는 콜백 함수를 볼 수 있다.(Listing 6)

     

    Listing 6. 상태 코드를 무시하는 콜백 함수

    function updatePage() {
    if (request.readyState == 4) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "
    ");
    }
    }

     

    이것은 근시안적이고 에러를 많이 만드는 Ajax 프로그래밍 방식이다. 스크립트가 인증을 필요로 하는데 요청이 유효 증명을 제공하지 않으면 서버는 403 또는 401 같은 에러를 리턴한다. 하지만 서버가 요청에 응답하기 때문에 준비 상태는 4로 설정될 것이다. 결과적으로 사용자는 유효 데이터를 얻지 못하고 JavaScript가 존재하지 않는 서버 데이터를 사용하려고 할 때 에러를 얻게 된다.

    서버가 요청을 완료하고 "Everything is OK" 상태 코드를 리턴했다는 것을 확인하는 것은 간단한 일이다. 이 코드는 "200"이고 XMLHttpRequest 객체의 status 속성을 통해서 보고된다. 서버가 요청으로 끝나고 OK 상태를 리포트 했다는 것을 확인하려면 추가 체크를 콜백 함수에 추가한다.(Listing 7)

     

    Listing 7. 유효 상태 코드 추가

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "
    ");
    } else
    alert("status is " + request.status);
    }
    }

     

    코드에 몇 줄을 추가하는 것으로 무엇이 잘못되었는지를 알 수 있고 사용자는 아무런 설명이 없는 데이터 데신 유용한 에러 메시지들을 받을 수 있다.

     

     

    리다이렉션과 재 라우팅

     

    에러에 대해 이야기 하기 전에 Ajax를 사용할 때 걱정하지 않아도 될 부분에 대해 말해두겠다. 바로 리다이렉션이다. HTTP 상태 코드에서, 이것은 300 대의 상태 코드이다.

  • 301: Moved permanently
  • 302: Found (요청이 또 다른 URL/URI로 리다이렉션 된다.)
  • 305: Use Proxy (요청은 프록시를 사용하여 요청 받은 리소스에 액세스 해야 한다.)

    Ajax 프로그래머가 리다이렉션에 대해 염려 할 필요가 없는 이유가 두 가지 있다.

  • Ajax 애플리케이션들은 특정 서버측 스크립트, 서블릿, 애플리케이션을 위해 작성된다. 그 컴포넌트를 없애거나 다른 곳으로 이동하기 위함이다. 리소스는 변경되었다는 것을 (이미 이동했기 때문에)알고, 요청에서 URL을 변경하고 이러한 종류의 결과를 절대 만나지 않게 된다.

  • 보다 관련성 있는 이유가 있다. Ajax 애플리케이션과 요청들은 샌드박스화 되어있다. Ajax 요청을 만드는 웹 페이지를 공급하는 도메인은 그러한 요청에 응답해야 하는 도메인이다. 따라서 ebay.com에서 공급 받은 웹 페이지는 Ajax 스타일의 요청을 amazon.com에서 실행되는 스크립트에 할 수 없다. ibm.com 상의 Ajax 애플리케이션은 netbeans.org에서 실행되는 서블릿으로 요청할 수 없다.

    결국, 요청은 보안 에러를 만들지 않고서는 또 따른 서버로 리다이렉션 될 수 없다. 그러한 경우에, 상태 코드를 전혀 얻을 수 없다. 디버그 콘솔에 JavaScript 에러를 갖게 된다. 따라서 많은 상태 코드에 대해 생각하는 동안 리다이렉션 코드 정도는 무시할 수 있는 것이다.

     

    엣지 케이스와 하드 케이스
    이 부분에서, 신참 프로그래머들은 이러한 혼란에 대해 궁금할 것이다. Ajax 요청의 5 퍼센트 정도는 2와 3 정도의 준비 상태와 403 같은 상태 코드로 작동해야 한다. (사실, 1 퍼센트 미만이다.) 이러한 케이스는 중요하고, 엣지 케이스(edge cases)라고 일컬어진다. 이상한 조건들이 부합되는 특수한 상황인 것이다. 일상적인 것은 아니지만 사용자를 곤란에 처하게 한다.

    일반적인 사용자들은 애플리케이션이 정확히 작동하는지 매번 잊지만 그렇지 않을 때는 분명히 기억한다. 엣지 케이스와 하드 케이스를 핸들 할 수 있다면 사이트 사용자들을 만족시킬 수 있을 것이다.

     

     

    에러

     

    일단, 상태 코드 200을 관리했고 300 계열의 상태 코드는 대충 무시하면 다양한 유형의 에러들을 나타내는 400 계열의 코드만 남게 된다. Listing 7을 보면 에러가 처리되는 동안 사용자에게 출력되는 매우 일반적인 에러 메시지라는 것을 알게 된다. 이것은 올바른 방향으로 가는 단계지만 사용자와 프로그래머에게는 매우 쓸모없는 메시지이다.

    우선 소실된 페이지에 대한 지원을 추가한다. 이는 제품 시스템에서는 실제로 발생하지는 않지만 스크립트를 이동시키는 테스트나 정확하지 않은 URL을 입력할 때 자주 일어나는 일이다. 404 에러를 보고하면 혼란스러워 하는 사용자와 프로그래머에게 더 많은 도움말을 제공할 것이다. 예를 들어, 서버 상의 스크립트가 제거되거나 Listing 7에서 그 코드를 사용하면 다음과 같은 에러가 생긴다.(그림 5)

    사용자 삽입 이미지

    그림 5. 일반적인 에러 핸들링

    사용자는 문제가 무엇인지 잘 모른다. 인증에 관련된 것인지, 소실된 스크립트 인지, 사용자 에러인지 알 수 없다. 몇 가지 간단한 코드 추가로 이 에러는 더욱 구체화 된다. Listing 8을 보면 소실된 스크립트와 인증 에러까지 구체적인 메시지와 함께 처리된다.

  •  

    Listing 8. 유효 상태 코드 점검

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "
    ");
    } else if (request.status == 404) {
    alert ("Requested URL is not found.");
    } else if (request.status == 403) {
    alert("Access denied.");

    } else
    alert("status is " + request.status);
    }
    }

     

    이는 오히려 더 간단하지만 추가 정보 까지 제공한다. 그림 6은 그림 5와 같은 에러를 보여주지만 이번에는 에러 핸들링 코드가 더 나은 그림을 제공하고 있다.

    사용자 삽입 이미지

    그림 6. 구체적인 에러 핸들링

    여러분의 애플리케이션에서 인증 때문에 오류가 발생했을 때 사용자 이름과 패스워드를 지우고 에러 메시지를 스크린에 추가하는 것을 고려할 수도 있다. 이와 비슷한 방식이 소실된 스크립트나 다른 400 유형의 에러들을 핸들하는데 사용될 수 있다. 여러분이 어떤 선택을 하든 서버에서 리턴 된 상태 코드를 핸들하는 것으로 시작한다.

     

     

    추가 요청 유형

     

    XMLHttpRequest 객체를 제어하고 싶다면 HEAD 요청을 레파토리에 추가하라. 이전 두 개의 기사에서 GET 요청을 하는 방법을 설명했다. 앞으로는 POST 요청을 사용하여 서버로 데이터를 보내는 것을 설명하도록 하겠다. 향상된 에러 핸들링과 정보 수집을 위해 HEAD 요청에 대해 배워야 한다.

     

     

    요청하기

     

    HEAD 요청은 실제로 매우 간단하다. 첫 번째 매개변수로서 "GET" 또는 "POST" 대신 "HEAD"로 open() 메소드를 호출한다.(Listing 9)

     

    Listing 9. HEAD 요청

    function getSalesData() {
    createRequest();
    var url = "/boards/servlet/UpdateBoardSales";
    request.open("HEAD", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

     

    이와 같이 HEAD 요청을 하면 서버는 GET이나 POST 요청 때 처럼 실제 응답을 리턴하지 않는다. 대신, 서버는 응답에 있는 콘텐트가 마지막으로 수정된 시간이 포함된 리소스의 헤더를 리턴한다. 게다가 몇 가지 재미있는 정보도 추가한다. 이들을 사용하여 서버가 리소스를 처리 및 리턴하기 전에 리소스에 대해 알 수 있다.

    이와 같은 요청으로 할 수 있는 가장 쉬운 일은 모든 응답 헤더들을 나누는 것이다. 이로서 HEAD 요청을 통해 무엇이 가능한지를 알 수 있다. Listing 10은 HEAD 요청에서 모든 응답 헤더를 출력하는 콜백 함수이다.

     

    Listing 10. HEAD 요청에서 모든 응답 헤더 프린트 하기

    function updatePage() {
    if (request.readyState == 4) {
    alert(request.getAllResponseHeaders());
    }
    }

     

    그림 7에서 서버에 HEAD 요청을 한 간단한 Ajax 애플리케이션에서 온 응답 헤더를 볼 수 있다.

    사용자 삽입 이미지

    그림 7. HEAD 요청에서 온 응답 헤더

    이러한 헤더들을 개별적으로 사용하여 Ajax 애플리케이션에서 추가 정보나 기능을 제공할 수 있다.

     

     

    URL 검사

     

    URL이 존재하지 않을 때 404 에러를 검사하는 방법을 이미 보았다. 이것이 일반적인 문제라면, 특정 스크립트나 서블릿이 잠시 동안 오프라인에 있었다면, GET 또는 POST 요청을 하기 전에 URL을 검사해 보는 것이 좋다. HEAD 요청을 하고 콜백 함수에서 404 에러를 검사한다. Listing 11은 샘플 콜백을 보여준다.

     

    Listing 11. URL이 존재하는지 여부 검사

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    alert("URL exists");
    } else if (request.status == 404) {
    alert("URL does not exist.");
    } else {
    alert("Status is: " + request.status);
    }
    }
    }

     

    솔직히 말하면 이것의 가치는 별로 없다. 서버는 요청에 응답해야 하고 응답을 분석하여 응답 헤더에 파퓰레이트 하기 때문에 여러분은 프로세싱 시간을 저축할 수 없다. 게다가 요청을 하고 HEAD 요청을 사용하여 URL이 존재하는지 보는 것에도 많은 시간이 걸린다. Listing 7에서 처럼 에러를 핸들링 하기 보다 GET이나 POST를 사용하여 요청하기 때문이다. 무엇을 사용할 수 있는지를 정확히 아는 데는 가끔 유용하다.

     

     

    유용한 HEAD 요청

     

    HEAD 요청이 유용한 한 가지 부분은 콘텐트 길이나 콘텐트 유형을 검사할 때이다. 요청을 처리하기 위해 많은 양의 데이터를 보낼 것인지, 서버가 HTML, 텍스트, XML 대신 바이너리 데이터를 리턴해야 할지를 결정할 수 있다. (이 세 가지 모두 바이너리 데이터 보다 JavaScript에서 처리하는 것이 더 쉽다.)

    이 경우, 적절한 헤더 이름을 사용하고 이를 XMLHttpRequest 객체의 getResponseHeader() 메소드로 보낸다. 따라서 응답의 길이를 알려면 request.getResponseHeader("Content-Length");를 호출한다. 콘텐트 유형을 알려면 request.getResponseHeader("Content-Type");를 사용한다.

    많은 애플리케이션에서 HEAD 요청을 하면 어떤 기능도 추가하지 않고 요청의 속도를 늦출 수 있다. (HEAD 요청을 실행하여 응답에 대한 데이터를 얻고 후속 GET 또는 POST 요청을 통해 응답을 실제로 받는다.) 하지만 스크립트나 서버측 컴포넌트에 대해 확실하지 않은 경우 HEAD 요청으로 기본적인 데이터를 받을 수 있다.

     

     

    결론

     

    Ajax와 웹 프로그래머에게 이 글은 다소 어려울 것이다. HEAD 요청을 하는 것의 가치는 무엇인가? JavaScript에서 리다이렉션 상태 코드를 핸들해야 하는 때는 언제인가? 이 모두 좋은 질문이다. 간단한 애플리케이션의 경우, 이 모든 것은 가치가 별로 없다.

    하지만 웹이 단순한 애플리케이션만 수용하는 것은 아니다. 사용자는 점점 고급화 되고 고객들도 강력한 에러 리포팅을 원한다. 관리자 역시 애플리케이션이 조금만 느려져도 해고를 당하게 된다.

    간단한 애플리케이션을 넘어 XMLHttpRequest에 대한 이해를 높여야 할 때이다.

  • 다양한 준비 상태를 이해하고 이들이 브라우저 마다 어떻게 다른지를 이해하면 애플리케이션을 빠르게 디버깅 할 수 있다. 준비 상태에 기반하여 창조적인 기능을 만들고 요청자의 상태에 대해 사용자와 고객에게 보고할 수 있다.

  • 상태 코드를 핸들했다면 스크립트 에러, 예기치 못한 응답들, 엣지 케이스들을 다룰 수 있다. 결국, 애플리케이션은 언제나 잘 작동될 것이다.

  • 여기에 더하여 HEAD 요청을 만들고, URL의 존재를 검사하고 파일이 언제 수정되었는지를 파악하고 사용자가 유효 페이지를 얻었는지를 확인할 수 있다면 언제나 최신의 정보와 강력한 기능으로 사용자들을 만족시킬 수 있을 것이다.

    이들은 모두 Ajax의 강점이지만 극히 일부분이다. Ajax를 사용하여 애플리케이션이 에러와 문제들을 부드럽게 해결할 수 있는 강력한 토대를 구현한다면 사용자는 여러분의 사이트를 방문할 것이다. 다음 글에서는 보다 더 재미있고 흥미 있는 주제들을 나누도록 하겠다.

     

    다운로드 하십시오

    설명이름크기다운로드 방식
    Example code for this articlewa-ajaxintro3_ajax-xhr_adv.zip183 KBHTTP

     

     

    참고자료

    교육
    - "Ajax 마스터, Part 1: Ajax 소개" (developerWorks, December 2005)
    - "Ajax 마스터하기, Part 2: JavaScript와 Ajax를 이용한 비동기식 요청" (developerWorks, January 2006)
    - "자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현" (developerWorks, September 2005)
    - "자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화" (developerWorks, October 2005)
    - "Call SOAP Web services with Ajax, Part 1: Build the Web services client" (developerWorks, October 2005)
    - Google GMail, Google Maps
    - Flickr
    - "Ajax: A New Approach to Web Applications
    - HTTP status codes
    - Head Rush Ajax by Elisabeth Freeman, Eric Freeman, and Brett McLaughlin (February 2006, O'Reilly Media, Inc.)
    - Java and XML , Second Edition by Brett McLaughlin (August 2001, O'Reilly Media, Inc.)
    - JavaScript: The Definitive Guide by David Flanagan (November 2001, O'Reilly Media, Inc.)
    - Head First HTML with CSS & XHTML by Elizabeth and Eric Freeman (December 2005, O'Reilly Media, Inc.)
    - developerWorks Web architecture zone
    - developerWorks technical events and Webcasts

    제품 및 기술 얻기
    -IBM trial software

    토론
    -포럼에 참여하기.
    -developerWorks blogs.

     

     

    사용자 삽입 이미지


    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3055

      Comments,     Trackbacks
    [Ajax] Ajax 마스터하기 - JavaScript와 Ajax를 이용한 비동기식 요청

    [Ajax] Ajax 마스터하기 - JavaScript와 Ajax를 이용한 비동기식 요청 [PART 02]

     

    개요
    PART 01/Ajax 소개
    PART 02/JavaScript와 Ajax를 이용한 비동기식 요청
    PART 03/Ajax의 고급 요청 및 응답
    PART 04/웹 응답에 DOM 활용하기
    PART 05/DOM 다루기


     

    HTML, JavaScript™, DHTML, DOM으로 구성된 Ajax는 볼품없는 웹 인터페이스를 인터랙티브 Ajax 애플리케이션으로 변형하는 획기적인 방식이다. Ajax 전문가인 필자는 이러한 기술들이 어떻게 작용하는지 전체적인 개요를 비롯하여 세부사항 까지 설명한다. 또한 XMLHttpRequest 객체 같은 Ajax의 중심적인 개념들을 소개한다.

     

    5년 전, XML에 대해 무지했다면 아무도 얘기할 상대가 없는 미운 오리 새끼 신세가 되었을지도 모르겠다. Ruby 프로그램이 주목을 받았던 8개월 전, Ruby 프로그램 언어 기능에 대해 알지 못했던 프로그래머들은 냉수기 관련 산업세계에서 환영 받지 못했다. 그런 것처럼, 최신 기술단계로 입문하고자 한다면 Ajax에 대해 알아야 한다.

    하지만 Ajax는 일시적으로 유행하는 툴이 아니다. 웹 사이트를 구축하는 강력한 방식이며 완전히 새로운 언어를 배우는 것보다는 그다지 어렵지 않다.

    Ajax에 관해 자세히 들어가기 전에 잠시 Ajax의 기능에 대해 알아보자. 오늘날 애플리케이션을 작성할 시 두 가지 애플리케이션이 있다.

    • 데스크톱 애플리케이션
    • 웹 애플리케이션

    두 애플리케이션은 다 친숙한 것들이다. 일반적으로 데스크톱 애플리케이션은 CD상에 배치된 다음 (또는 웹 사이트에서 다운로드) 컴퓨터에 완전 설치된다. 이 애플리케이션은 인터넷을 이용해 업데이트를 다운로드하기도 하지만 애플리케이션 실행 코드는 데스크톱 상에 상주해 있다. 전혀 새로운 것이 아닌 웹 애플리케이션은 웹 서버 상에서 실행되며 웹 브라우저 상에서 접속된다.

    하지만 두 애플리케이션에 대한 코드 실행 위치보다 애플리케이션 작동방식 및 애플리케이션과 사용자와의 상호작용방식이 중요하다. 일반적으로 데스크톱 애플리케이션은 상당히 빠르고 (컴퓨터 상에서 실행되고 인터넷 상에서 대기 중인 상태가 안 나온다.), 대형 사용자 인터페이스(일반적으로 운영체제와 상호작용)를 갖추며 상당히 동적이다. 거의 대기시간 없이 메뉴 및 하위 메뉴를 클릭, 지시, 입력하고 풀업한다.

    반면 웹 애플리케이션은 가장 최신 것이며 데스크톱에서는 전혀 얻을 수 없는 서비스를 제공한다.(Amazon.com 및 eBay를 생각해 볼 것.) 하지만 웹 애플리케이션 기능으로 인해 서버 응답 대기, 스크린 재생 대기, Request 컴백 및 새 페이지 생성에 관한 대기 기능 등이 부수된다.

    분명 지나친 단순화 과정임에는 틀림없지만 기본 개념은 얻게 된다. 이미 눈치를 챘겠지만 Ajax는 데스크톱 애플리케이션 및 항상 업데이트 되는 웹 애플리케이션의 기능 및 상호작용 간의 차이를 줄여주는 역할을 한다. 여러분은 마치 데스크톱 애플리케이션에서 찾은 것처럼 동적 사용자 인터페이스 및 가상 제어기능을 사용한다. 하지만 웹 애플리케이션 상에서 데스크톱 애플리케이션을 이용할 수 있다. 그러면 대기 중인 것이 무엇인가? Ajax 및 볼품없는 웹 인터페이스가 응답 Ajax 애플리케이션으로 변환되는 과정에 대해 살펴보기로 하자.

    그러면 대기 중인 것이 무엇인가? Ajax 및 볼품없는 웹 인터페이스가 응답 Ajax 애플리케이션으로 변환되는 과정에 대해 살펴보기로 하자.

     

     

    오래된 기술, 새로운 기법

     

    Ajax에 관해 살펴보면 Ajax는 실지로 많은 기술들이 응집되어 있다. Ajax의 기본을 마치고 넘어가려면 몇 가지 다른 기술들(필자는 첫 번째 이 시리즈에서 각각의 기술에 관해 설명할 것이다.)을 면밀히 살펴보아야 한다. 하지만 이들 기술 가운데 어느 정도 알고 있는 것이 많은 건 다행이다. 더군다나 각각의 기술 대부분은 Java/Ruby같은 프로그래밍 언어만큼 어려운 게 아니라서 배우기 쉽다.

    Ajax 애플리케이션에 포함된 기본기술은 다음과 같다.

  • 웹 양식을 구축하고 애플리케이션 완료 때까지 사용되는 필드를 식별하는 데 HTML을 사용한다.
  • 자바 스크립트 코드는 Ajax 애플리케이션을 실행하는 중심 코드며 서버 애플리케이션과의 커뮤니케이션을 용이하게 한다.
  • DHTML(동적 HTML)은 웹 양식을 동적으로 업데이트 한다. div, span및 기타 동적 HTML 요소를 사용해 HTML을 마크업 한다.
  • 서버에서 복귀된 HTML 및 (때로) XML 구조를 다루는 데 있어 DOM, 즉 문서 객체 모델(Document Object Model)을 사용한다.

    이 기술들에 대해 간략히 요약하고 각 기술의 기능에 대해 좀 더 알아보기로 하는데 각 기술에 관한 자세한 사항은 차후 글에서 다룰 것이다. 우선은 Ajax의 구성요소 및 기술에 대해 친숙해 지는 데 초점을 맞추기로 한다. 자바 스크립트에 익숙할수록 Ajax에 담긴 기술에 관한 일반적인 지식 단계에서 각 기술에 관한 자세한 지식으로 넘어가는 게 더 쉬워진다.(또한 이로 인해 웹 애플리케이션 개발에 관한 문이 열리게 된다.)

     

    Ajax 정의
    Ajax는 비동기 JavaScript 및 XML의 약어이다.(DHTML도 마찬가지다.) Adaptive Path사의 Jesse James Garrett이 이 약어를 만들어냈으며(참고자료 참조), Jesse에 따르면 이 약어는 두문자어는 아니라고 한다.

     

     

     

    XMLHttpRequest 객체

     

    알고자 하는 객체 중 첫 번째는 아마도 가장 생소한 것이 아닌가 싶다. 그 객체는 일명 XMLHttpRequest인데 자바 스크립트 객체의 일종이며 Listing 1에 나와 있는 것처럼 단순하게 생성된다

     

    Listing 1. 새로운 XMLHttpRequest 객체 생성


    <script language="javascript" type="text/javascript">
    var xmlHttp = new XMLHttpRequest();
    </script>

     

    필자는 다음 글에서 이 객체에 대해 더 논의할 것이다. 하지만 지금 상태에서는 모든 서버 커뮤니케이션을 다루는 객체라는 사실만 알아둔다. 다음 사항으로 가기 전에 잠깐 생각해 보면 자바 스크립트 객체는 XMLHttpRequest를 통해 서버에 전달하는 자바 스크립트 기술의 일종이다. 이 객체는 애플리케이션 흐름이 정상적이지 않으며 Ajax 기술의 많은 부분을 차지하고 있다.

    정상적인 웹 애플리케이션에서 사용자는 양식 필드를 기입하며 제출 버튼을 클릭한다. 그러면 전 양식을 서버에 보내며 서버는 처리과정을 통해 양식을 스크립트(일반적으로 PHP, 자바 또는 CGI 과정/이와 유사한 과정)에 전송한다. 스크립트를 실행할 때 스트립트를 통해 완전히 새로운 페이지가 전송된다. 그 페이지는 데이터가 작성된 새로운 양식의 HTML/확인 페이지 또는 원 양식에 기입된 데이터에 근거해 선택된 옵션이 포함된 페이지일 수 있다. 물론, 서버 상의 스크립트/프로그램이 처리되면서 새로운 양식을 다시 보내는 동안 사용자는 대기해야 한다. 서버로부터 데이터를 다시 받을 때까지는 스크린 상에 아무 것도 없게 되며 결국 대화성은 낮게 된다. 사용자는 즉각적으로 응답을 받지 못하며 데스크톱 애플리케이션 상에서 작업하는 기분이 들지 않게 된다.

    Ajax는 근본적으로 자바 스크립트 기술 및 웹 양식 및 서버 간의 XMLHttpRequest 객체를 결합한다. 사용자가 웹 양식을 기입할 때 데이터는 직접 서버 스크립트에 전송되지 않고 자바 스크립트 코드에 전달된다. 대신 자바 스크립트 코드는 양식 데이터를 포착해 Request를 서버에 전송한다. 이 과정이 일어나는 동안, 사용자 스크린 상의 양식은 순식간에 나타나거나 깜빡이거나 사라지거나 정지하지 않는다. 즉 자바 스크립트 코드는 몰래 Request를 전송하며 사용자는 Request가 만들어졌는지도 알지 못한다. 게다가 Request를 비동기적으로 전송하기 때문에 더 좋은 상황이 된다. 이는 자바 스크립트에서 서버 응답을 그냥 대기하지 않는다는 것을 의미한다. 따라서, 사용자는 데이터를 계속 기입하고 화면이동하고 애플리케이션을 사용한다.

    그런 다음 서버는 자바 스크립트 코드(웹 양식에 대해 아직도 대기 중임)에 데이터를 다시 전송한다. 자바 스크립트 코드에서는 데이터와의 상호기능을 결정하며 연속적으로 양식 필드를 업데이트 하면서 애플리케이션에 즉각적인 응답을 준다. 결국 사용자는 양식을 제출/재생하는 작업 없이 새로운 데이터를 얻게 된다. 자바 스크립트 코드는 데이터를 얻고 계산도 수행하며 또 다른 Request를 전송하며 이런 모든 과정은 사용자 개입 없이도 된다! 이것이 바로 XMLHttpRequest 객체의 장점이다. XMLHttpRequest 객체는 서버와 같이 커뮤니케이션을 주고받고 사용자는 그 과정에서 벌어지는 과정을 알지 못한다. 이로 인해 데스크톱 애플리케이션과 마찬가지로 동적, 상호 반응적인 고도의 양방향 경험을 얻게 되지만 그 속에 인터넷의 모든 장점이 담겨 있다.

     

     

    자바 스크립트에 대한 부가사항

     

    일단 XMLHttpRequest에 대해 다루게 되면 나머지 자바 스크립트 코드는 상당히 평범한 것들이다. 사실 다음과 같은 기본적인 작업에 자바 스크립트 코드를 이용한다.

  • 양식 데이터 얻기: 자바 스크립트 코드로 HTML 양식에서 데이터를 꺼내 이를 서버에 전송하는 작업이 간단해진다.
  • 양식 상의 값 변환: 필드 값 설정에서 연속적인 이미지 교체작업에 이르는 양식 업데이트 작업 또한 간단하다.
  • HTML 및 XML 구문분석: 자바 스크립트 코드를 이용해 DOM(다음 섹션 참조)을 처리하고 서버에서 다시 전송하는 HTML 양식 및 임의의 XML 데이터에 관한 구조를 다루게 된다.

    첫 번째 두 항목에 대해서 여러분은 Listing 2에 나온 대로 getElementById()에 익숙해지려 할 것이다.

     

    Listing 2. 자바 스크립트 코드에서의 필드 값 포착 및 설정

    // Get the value of the "phone" field and stuff it in a variable called phone
    var phone = document.getElementById("phone").value;

    // Set some values on a form using an array called response
    document.getElementById("order").value = response[0];
    document.getElementById("address").value = response[1];

     

    Ajax 애플리케이션에서 특별히 획기적인 사항은 없고 상기 사항 정도면 충분하다. 이에 대해 상당히 복잡한 건 없다는 사실을 깨달아야 한다. 일단 XMLHttpRequest만 정복하면 Ajax 애플리케이션에서 나머지는 대부분 Listing 2에 나온 바와 같이 상당히 독창적인 HTML과 결합된 단순 자바 스크립트 코드다. 그런 다음 가끔 약간의 DOM 작업이 발생하게 된다. 이에 관해 살펴 보자.

     

     

    DOM으로 종료하기

     

    DOM, 즉 문서 객체 모델이라는 것이 있는데 이는 아주 중요하다. DOM에 대해 듣는 것은 그다지 어렵지 않다고 하는 사람들이 있다. HTML 디자이너에 의해서는 종종 사용되지 않으며 하이-엔드 프로그래밍 작업으로 들어가지 않는 한은 JavaScript 코더에서 흔치 않은 것이 바로 DOM이다. 종종 과중-업무 Java 및 C/C++ 프로그램 상에서 DOM을 종종 많이 활용하게 된다. 사실은 DOM이 배우기 어려운 특성 때문에 명성이 자자해 그 프로그램 상에서 종종 사용하는 것이 아닌가 싶다.

    다행히도 JavaScript 기술에 있어 DOM을 활용하는 일은 쉽고 대부분 직관적이다. 이 시점에서 필자는 DOM 사용법에 관해 보여 주고 적어도 이에 대한 몇 가지 코드 예를 제시하려 하지만 이 글의 의도와는 벗어나는 것 같다. DOM에 관해 대략적으로 다루는 것 없이도 Ajax에 대해 깊이 다룰 수 있다. 필자는 차후의 글에서 다시 DOM에 관해 다루려 한다. 하지만 지금 상황에서는 언급하지 않으려 한다. JavaScript 코드와 서버 사이에 XML을 이리저리 전송하고 HTML 양식을 변화시킬 때 DOM에 대해 자세히 다루게 될 것이다. 지금은 DOM없이 효과적인 Ajax 애플리케이션을 작동하는 게 쉬우므로DOM은 논외로 한다.

     

     

    Request 객체 얻기

     

    Ajax 애플리케이션에 관한 기본적 개념에 대해 배웠으면 몇 가지 특수사항에 대해 살펴 보자. XMLHttpRequest 객체는 Ajax 애플리케이션에서 중요하므로, 아마도 많은 이들에게는 생소한 것일 수도 있다. 거기서 필자는 논의를 시작한다. Listing 1에서 보다시피, XMLHttpRequest 객체를 생성, 사용하는 것은 상당히 쉬워야 한다. 잠깐만 기다려 보시라.

    수년 동안 브라우저에 관한 논란은 끊이지 않았고 동일한 브라우저로는 아무 것도 얻을 수 없다는 사실을 기억하는가? 믿건 말건, 소규모 브라우저에서도 이와 같은 논쟁은 끊이지 않고 있다. 더군다나 놀라운 사실은 XMLHttpRequest가 이 논란의 희생양 중 하나라는 것이다. 따라서 XMLHttpRequest 객체를 작동시키기 위해선 몇 가지 다른 작업을 해야 한다. 단계별로 설명하겠다.

     

     

    Microsoft 브라우저 다루기

     

    Microsoft 브라우저, Internet Explorer는 XML을 다룰 시 MSXML 구문분석계를 사용한다.(참고자료 참조) Internet Explorer 상에서 다뤄야 할 Ajax 애플리케이션을 작성할 시 독특한 방식으로 XMLHttpRequest 객체를 작성해야 한다.

    하지만 그렇게 간단한 작업은 아니다. Internet Explorer에 설치된 JavaScript 기술 버전에 따라 MSXML 버전도 변하게 되며 실지로 2개의 버전이 있다. 따라서 두 경우를 다루는 코드를 작성해야 한다. Microsoft 브라우저 상에서 XMLHttpRequest 객체를 생성하는 데 필요한 코드에 관해선 Listing 3을 보라.

     

    Listing 3. Microsoft 브라우저 상에서 XMLHttpRequest 객체 생성

    var xmlHttp = false;
    try {
    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e2) {
    xmlHttp = false;
    }
    }

     

    모든 작업이 정확히 맞아떨어지는 것은 아니다. 하지만 그래도 상관없다. 이 시리즈가 끝나기 전에 JavaScript 프로그래밍, 에러 취급 및 조건부 번역 및 기타 사항에 관해 자세히 다루게 될 것이다. 지금 현 상태에서는 두 가지 중심 라인만 다루고자 한다.

     

    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    and
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");.

     

    간단히 말해서, 이 코드로 MSXML의 한 버전을 이용해 XMLHttpRequest 객체 생성을 기한다. 하지만 객체가 생성되지 않는 경우 다른 버전을 사용해 XMLHttpRequest 객체를 생성한다. 두 코드 다 작동되지 않는 경우 xmlHttp 변수는 거짓으로 설정되고 작동되지 않는 것이 있다는 것을 코드에 알려 준다. 그럴 경우, 비-Microsoft 브라우저가 있을 가능성이 있다. 따라서 객체 생성을 위해선 다른 코드를 사용해야 한다.

     

     

    Mozilla 및 Microsoft 브라우저 다루기

     

    인터넷 브라우저를 선택하지 않거나 비-Microsoft 브라우저를 작성할 경우 다른 코드가 필요하다. 사실, 이 라인은 Listing 1에서 봤던 단순 코드라인이다.

     

    var xmlHttp = new XMLHttpRequest object;.

     

    이 단순한 라인으로 Mozilla, Firefox, Safari, Opera 및 임의의 양식/형태에서 Ajax애플리케이션을 지원하는 기타 비-Microsoft 브라우저에서 XMLHttpRequest 객체를 생성한다.

     

     

    지원기능 통합

     

    여기서 모든 브라우저를 지원하는 것이 중요하다. Internet Explorer/비-Microsoft 브라우저에서만 작동되는 애플리케이션을 작성하는 사람이 어디 있겠는가? 또한 더 심한 경우, 애플리케이션을 두 번 작성하고자 하는가? 물론 아니라고 믿는다. 따라서 코드에선 Internet Explorer 및 비-Microsoft 브라우저를 지원하는 기능이 포함되어야 한다. Listing 4에서는 다중-브라우저 방식으로 작동하는 코드에 대해 나와 있다.

     

    Listing 4. 다중 브라우저 방식으로 XMLHttpRequest 객체 생성하기

    /* Create a new XMLHttpRequest object to talk to the Web server */
    var xmlHttp = false;
    /*@cc_on @*/
    /*@if (@_jscript_version >= 5)
    try {
    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e2) {
    xmlHttp = false;
    }
    }
    @end @*/

    if (!xmlHttp && typeof XMLHttpRequest != 'undefined') {
    xmlHttp = new XMLHttpRequest();
    }

     

    지금 현재로선, 주석 및 @cc_on와 같은 어려운 태그를 무시한다. 이들은 다음 글에서 깊이 다룰 JavaScript 컴파일러 명령으로 오로지 XMLHttpRequest 객체 상에만 초점이 맞추어져 있다. 이 코드에 관한 핵심은 세 가지 과정으로 요약된다.

    1. 변수 xmlHttp를 생성해 앞으로 생성할 XMLHttpRequest 객체를 참조한다.
    2. Microsoft 브라우저에서의 객체를 시도, 생성한다.

    • Msxml2.XMLHTTP 객체를 사용해 XMLHttpRequest 객체를 시도, 생성한다.
    • 과정이 실패할 경우, Microsoft.XMLHTTP 객체를 사용해 XMLHttpRequest 객체를 시도, 생성한다.

    3. xmlHttp가 아직도 설정되지 않은 경우 비-Microsoft 방식으로 XMLHttpRequest 객체를 생성한다.

    위 과정 끝 단계 시 사용자가 실행하는 브라우저 종류에 관계없이 xmlHttp의 경우 유효한 XMLHttpRequest 객체를 인용한다.

     

     

    보안

     

    보안이란 무엇인가? 오늘날 브라우저는 사용자들에게 보안 레벨을 올리고 JavaScript 기술을 생성하며 브라우저 옵션을 해제하는 기능을 제공한다. 이 경우 코드가 작동되지 않는 경우도 있을 수 있다. 그 때 발생하는 문제를 적절하게 다뤄야 한다. 이에 관한 내용은 적어도 기사 한 분량을 차지할 정도라 나중에 다루기로 하겠다.(긴 시리즈가 될 것 같다, 그렇지 않은가? 하지만 걱정 마시라. 과정을 다 배우고 나면 이와 관련된 모든 사항을 숙달할 테니까.) 현재로선 강력하지만 완전하지 않은 코드를 작성하는 중이다. 이 코드는 Ajax 애플리케이션을 관리하는 데 좋다.

     

     

    Ajax 세계에서의 Request/Response

     

    인제 Ajax 애플리케이션에 대해 이해하고 XMLHttpRequest 객체 및 객체 생성에 관한 기본적인 개념을 얻는다. 자세히 읽다 보면 Ajax 애플리케이션은 웹 애플리케이션에 제출되는 HTML 양식보단 서버 상의 임의의 웹 애플리케이션에 대화하는 JavaScript 기술이라는 사실을 알게 된다.

    그러면 빠진 부분은 어떤 것인가? 실질적인 XMLHttpRequest 객체 사용법이다. 이 객체는 작성하는 각각의 Ajax 애플리케이션에서 일정 형태로 사용하는 중요 코드라 Ajax 애플리케이션이 포함된 기본 Request/응답 모델 모양을 통해 객체 사용법을 빨리 익힌다.

     

     

    Request 만들기

     

    새로운 XMLHttpRequest 객체가 있는 경우 이를 시험해 보자. 먼저 웹 페이지에서 호출하는 JavaScript 방법이 필요하다.(사용자가 텍스트에서 입력하거나 메뉴에서 옵션을 선택할 시와 같음.) 그 다음, 거의 모든 Ajax 애플리케이션에서의 동일한 기본 아웃라인을 따른다.

    1. 웹 양식으로부터 필요한 모든 데이터 얻기
    2. 연결할 URL 구축
    3. 서버 연결
    4. 서버 실행 종료 시 서버 실행 기능 설정
    5. Request 전송

    Listing 5는 위의 순서대로 5단계를 진행하는 Ajax 방법의 예에 관해 나와 있다.

     

    Listing 5. Ajax가 포함된 Request 만들기

    function callServer() {
    // Get the city and state from the web form
    var city = document.getElementById("city").value;
    var state = document.getElementById("state").value;
    // Only go on if there are values for both fields
    if ((city == null) || (city == "")) return;
    if ((state == null) || (state == "")) return;

    // Build the URL to connect to
    var url = "/scripts/getZipCode.php?city=" + escape(city) + "&state=" + escape(state);

    // Open a connection to the server
    xmlHttp.open("GET", url, true);

    // Setup a function for the server to run when it's done
    xmlHttp.onreadystatechange = updatePage;

    // Send the request
    xmlHttp.send(null);
    }

     

    Ajax 코드에 관한 많은 것이 명백하다. Ajax 코드의 첫번째 비트는 몇 가지 양식 필드 값을 포착하는 기본 JavaScript 코드를 사용한다. 그런 다음 이 코드에서는 연결 최종 목적지로 PHP 스크립트를 설정한다.

    PHP 스크립트의 URL을 지정한 다음(양식에서 나온) 단순한 GET 매개변수를 이용해 이 URL에 도시 및 국가를 추가한다. 그 다음 연결하면 먼저 XMLHttpRequest 객체가 작동되는 것을 보게 된다. 연결방법은 연결 URL 뿐만 아니라, GET 매개변수에도 나와 있다. 최종 매개변수를 true로 설정한 경우, 이 매개변수에선 비동기식 연결(Ajax를 만든다.)을 요구한다. false로 설정한 경우엔 Request를 만들 시 서버 상에서 Ajax에서의 JavaScript 코드가 대기하고 응답을 받을 때 코드가 지속된다. 사용자는 최종 매개변수를 true로 설정하면서 서버에서 배경에 있는 Request를 처리하는 동안 사용자는 웹 양식(심지어는 기타 JavaScript 방식)을 여전히 사용한다.

    한편 xmlHttp(이것은 XMLHttpRequest 객체의 인스턴스라는 사실을 기억하라.)의 onreadystatechange 속성으로 서버 실행이 종료될 시(5분/5시간 내에 종료될 수 있음) 서버 기능을 명령한다. 이 코드는 서버 상에서 대기하지 않기 때문에 서버가 기능을 인식해 서버에 응답할 수 있도록 하는 게 필요하다. 이 경우 서버에서 Request를 처리하면서 종료 시 이른바 updatePage()라 불리는 특수 방법을 트리거한다.

    최종적으로 send() 코드를 0(null) 값으로 호출한다. 데이터를 추가해 이를 서버에 전송하므로 Request에는 추가해서 보낼 게 없다. 이렇게 되면 Request를 발송하고 서버는 서버에 요구된 기능을 실행한다.

    이 코드에서 나오는 것이 없는 경우, 코드가 상당히 간단하다는 것을 명심하라. 이 코드는 Ajax 애플리케이션의 비동기적 특성을 제외하고는 상당히 단순하다. 이 코드를 통해 복잡한 HTTP Request/응답 코드보다는 근사한 애플리케이션 및 인터페이스에 완전 초점을 맞추도록 한다는 사실을 여러분은 높게 평가할 것이다.

    Listing 5의 코드는 코드를 얻는 방법만큼이나 쉽다. 데이터는 단순 텍스트이고 Request URL의 일부로 포함된다. GET 매개변수는 더 복잡한 POST대신 Request를 전송한다. 여기에 덧붙일 XML/컨텐츠 헤더가 없고 Request 본체에 전송할 데이터도 없다. 이게 바로 Ajax 유토피아다.

    그렇다고 미리 겁먹지 마라. 시리즈가 계속될수록 문제는 더 복잡해진다. 그 때는 POST Request를 전송하는 방법, Request 헤더 및 컨텐츠 형식을 설정하는 방법, 메시지에 XML을 설정하는 방법 및 Request에 보안기능을 추가하는 방법을 배우게 되는데 배우는 목록만 해도 상당히 길다! 지금은 이런 어려운 주제에 대해 신경 쓰지 말자! 그냥 기본만 충실하게 익히면 Ajax 전체 툴을 구축하게 된다

     

     

    응답 취급과정

     

    이제 서버 응답을 실지로 취급해야 한다. 이 시점에서는 정말로 두 가지 사항만 알면 된다.

  • xmlHttp.readyState 속성이 4와 같을 때까지는 어떤 작업도 해선 안 된다.
  • 서버는 xmlHttp.responseText 속성에 응답한다.

    2가지 항목 중 첫번째 항목인 준비 상태에 관해선 다음 글에서 대부분 다룰 것이다. 그 때는 HTTP Request 단계에 대해 알고 싶은 것 이상으로 배우게 된다. 지금 현재로선, xmlHttp.responseText 속성 값 4를 단순 점검하는 경우, 작업이 계속 진행된다.(다음 글에서 기대할 만한 사항이 나오게 된다.) 서버 응답을 얻기 위해 xmlHttp.readyState 속성을 사용하는 과정인 두 번째 항목은 쉽다. Listing 6은 Listing 5에서 전송된 값에 근거해 서버에서 호출하는 방법에 관한 예를 보여준다.

     

    Listing 6. 서버 응답 취급하기

    function updatePage() {
    if (xmlHttp.readyState == 4) {
    var response = xmlHttp.responseText;
    document.getElementById("zipCode").value = response;
    }
    }

     

    다시 보면, xmlHttp.readyState 코드는 그리 어렵거나 복잡하지 않다. 이 코드는 서버에서 해당 준비 상태로의 호출을 대기하고 서버에서 다시 복귀되는 값(이 경우, 사용자 기입 도시 및 국가에 대한 ZIP 코드)을 사용해 또 다른 형태의 양식 필드를 설정한다. 그 결과, zipCode 필드는 ZIP 코드와 함께 갑자기 나타난다. 하지만 사용자는 버튼을 클릭해서는 안 된다! 그게 바로 이전에 말했던 데스크톱 애플리케이션이다. Ajax 코드에는 응답성, 동적 상태 외의 더 많은 것이 있다. 독자들은 zipCode가 정상 텍스트 필드라는 것을 눈치챘을지도 모른다.

    일단 서버에서 zipCode를 복귀시키고 updatePage() 방식으로 도시/국가 ZIP 코드와 함께 zipCode 필드 값을 설정하는 경우 사용자는 값을 무효로 한다. 값을 무효로 하는 데는 두 가지 이유가 있다. 예에서 나오는 상황을 단순화시키고, 때로는 사용자가 서버에서 명령하는 것을 무효로 하기 위해서다. 이 두 가지를 명심하라. 좋은 사용자-인터페이스 설계를 위해 중요하다.

     

     

    웹 양식 다루기

     

    그러면 이 글에서 다룰 게 남아 있는가? 그다지 많지 않다. 양식에 기입할 정보를 포착해 이를 서버에 전송하고 응답에 관해 취급할 또 다른 JavaScript 방법을 제공하면서 심지어는 다시 응답될 때 필드 값을 설정하기까지 하는 JavaScript 방법을 다룬다. 여기서는 첫번째 JavaScript 방법을 호출해 전 과정을 시작하기만 하면 된다. 분명 HTTL 양식에 버튼을 추가하지만 2001년 버전과 거의 동일하다고 생각되지 않는가? Listing 7과 같이 JavaScript 기술을 활용한다.

     

    Listing 7. Ajax 프로세스 시작

    <form>
    <p>City: <input type="text" name="city" id="city" size="25"
    onChange="callServer();" /></p>
    <p>State: <input type="text" name="state" id="state" size="25"
    onChange="callServer();" /></p>
    <p>Zip Code: <input type="text" name="zipCode" id="zipCode" size="5" /></p>
    </form>

     

    이런 단면이 루틴 코드의 한 단면 이상을 보여준다고 생각된다면 맞는 말이다. ? 그렇다! 사용자가 도시/국가 필드에 관한 새로운 값을 입력할 경우 callServer() 방식을 전송한 다음 Ajax 애플리케이션이 시작된다. 이제 여러 상황을 다룰 만하다고 느껴지기 시작하는가? 좋다! 바로 그거다!

     

     

    맺음말

     

    이 시점에서 적어도 리소스 란에서 Ajax 애플리케이션에 관해 깊숙이 알려고 하는 경우, 첫번째 Ajax 애플리케이션을 작성할 준비가 되어 있지 않을 게다. 하지만 이런 애플리케이션이 작동하는 기본 개념 및 XMLHttpRequest 객체의 기본 개념을 이해하기 시작한 경우 이 객체, JavaScript-서버 간 대화 취급방식, HTML 양식 취급 및 심지어 DOM 관리 방식까지 모든 것을 배워야 한다.

    지금 현재로선, Ajax 애플리케이션이 얼마나 강력한 툴인지 생각하는 데 시간을 보낸다. 버튼만 클릭할 뿐만 아니라 필드에 입력하고 콤보 상자에서 옵션을 선택하고 심지어는 마우스를 스크린 주위에 끄는 경우 응답하는 웹 형식을 상상해 본다. 비동기식의 정확한 의미 및 Request 상에서 응답하기 위해 서버 상에서 실행하지만 대기하지 않는 JavaScript 코드에 관해 생각해 본다. 여러분이 부딪치는 문제의 종류는 어떤 것인가? 어떤 영역의 문제에 주의를 기울일 것인가? 프로그래밍에 이 새로운 접근방식을 설명하기 위해 양식 설계를 변환하는 방법은 어떤 것인가?

    이런 문제에 관해 실지로 생각할 시간을 보낸다면 잘라 붙이는 코드를 가지고 이를 잘 이해하지 못하는 애플리케이션에 포함시키는 것보다는 훨씬 더 낫다. 다음 글에서는 이와 같은 개념을 실제 작업에 응용해 본 작업에서처럼 애플리케이션을 만들어야 하는 코드에 관한 자세한 정보를 제공하기로 한다. 그 때까지 Ajax 애플리케이션의 가능성을 마음껏 즐겨라.

     

     

    참고자료

    교육
    - Adaptive Path
    - Jesse James Garrett, Ajax.
    - XMLHttpRequest object.
    - Microsoft Developer Network's XML Developer Center.
    - 자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현 (developerWorks, September 2005)
    - 자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화 (developerWorks, October 2005)
    - Using Ajax with PHP and Sajax (developerWorks, October 2005)
    - Call SOAP Web services with AJAX, Part 1: Build the Web services client (developerWorks, October 2005)
    - XML Matters: Beyond the DOM (developerWorks, May 2005)
    - Build apps with Asynchronous JavaScript with XML, or AJAX (developerWorks, November 2005)
    - Ajax for Java developers: Ajax with Direct Web Remoting (developerWorks, November 2005)
    - surveys AJAX/JavaScript libraries.
    - XUL Planet's object reference section details XMLHttpRequest
    - strategy white paper
    - Flickr.com.
    - GMail
    - Head Rush Ajax (O'Reilly Media, Inc., February 2006)
    - JavaScript: The Definitive Guide, 4th Edition (O'Reilly Media, Inc., November 2001)
    - developerWorks Web Architecture zone

    토론
    -포럼에 참여하기.
    -Ajax.NET Professional
    -developerWorks blogs.

     

    사용자 삽입 이미지


    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3052


     

    대부분의 웹 애플리케이션들은 서버에서 전체 HTML 페이지를 얻는 요청/응답 모델을 사용합니다. 다시 말해서, 이 모델은 버튼을 클릭하고, 서버를 기다리고, 또 다른 버튼을 클릭하고, 다시 기다리는 일이 다반사입니다. Ajax와 XMLHttpRequest 객체를 사용하면 서버 응답을 기다리지 않아도 되는 요청/응답 모델을 사용할 수 있습니다.

     

    지난 글(참고자료)에서는 Ajax 애플리케이션에 관한 서론 및 이 애플리케이션에 필요한 몇 가지 기본개념에 대해 알아봤다. 본 글에서는 JavaScript, HTML 및 XHTML, 동적 HTML, 심지어는 몇 가지 DOM(동적 객체 모델) 등 이미 알고 있는 수많은 기술에 대해 중점적으로 다뤘다.

    본 글에서는 모든 Ajax관련 객체 및 프로그래밍 방식의 기초인 XMLHttpRequest 객체에 대해 먼저 다룰 것이다. 이 객체는 모든 Ajax 애플리케이션 전반에 걸쳐 유일한 공통 줄기가 된다. 예상하다시피, XMLHttpRequest 객체를 완전히 이해해서 프로그래밍의 한계에 다다르고자 할 것이다. 사실, XMLHttpRequest 객체를 적절히 이용해도 분명 그 객체를 사용하지 못하는 경우가 있다. 도대체 XMLHttpRequest 객체는 무엇일까?

     

     

    Web 2.0

     

    먼저 코드에 관해 자세히 알아보기 전에 Web 2.0에 관한 개요를 살펴 보면서 확실한 개념을 얻도록 하자. Web 2.0이라는 용어를 들을 때 다음과 같이 " Web 1.0은 무엇입니까?" 라고 물어봐야 한다. Web 1.0에 대해선 거의 들어보지 못했지만 명료한 요청 및 응답 모델이 포함된 전통 웹을 가리켜 Web 1.0이라 한다. 예를 들어 Amazon.com으로 들어가서 버튼을 클릭하거나 탐색 용어를 입력하면 서버에 요청을 생성하고 이에 대한 응답이 브라우저로 다시 보낸다. 그 요청은 책, 타이틀 목록 이상으로 중요하며 실지로 또 다른 완전 HTML 페이지를 만들어낸다. 그 결과 새로운 HTML 페이지가 웹 브라우저 스크린에 다시 나타날 때 플래시/플리커링 현상이 나타나기도 한다. 사실, 각각의 새로운 페이지에서 나오는 요청, 응답을 분명히 알게 된다.

    Web 2.0은 이와 같은 왕복이동 움직임이 상당부분 필요 없다. 예를 들어, Google Maps 또는 Flickr(참고자료)를 방문하면 Google Maps 상에서는 맵을 끌어다가 재 드로잉을 약간만 해도 맵이 축소, 확대된다. 물론, 요청 및 응답은 상상을 초월할 정도로 계속 이루어진다. 이로 인해 사용자로서의 경험은 훨씬 짜릿하며 데스크톱 애플리케이션 상에 있는 것과 같이 느껴진다. 이런 새로운 느낌, 패러다임은 누군가가 Web 2.0에 대해 언급할 때 나오는 현상들이다.

    이와 같이 새로운 상호작용이 가능하도록 하는 방법에 대해 주의를 기울여야 한다. 분명 요청 및 필드 응답을 생성하지만 이로 인해 매 순간 요청/응답 상호작용에 관한 HTML 재 드로잉이 발생돼 느리고 볼품없는 웹 인터페이스를 생성하게 된다. 따라서 사용자가 요청을 생성하고 전반적인 HTML 페이지보다는 필요한 데이터만 포함하는 응답을 수신하는 방식이 필요하다. 사용자가 새로운 페이지를 보고자 할 때가 완전히 새로운 HTML을 얻는 유일한 경우다.

    하지만 대부분의 상호작용으로 인해 상세사항 추가/본문 텍스트 변환/기존 페이지에 데이터 겹쳐쓰기 등이 발생한다. 모든 경우, Ajax 및 Web 2.0방식으로 전체 HTML 페이지를 업데이트하지 않고 데이터를 전송, 수신한다. 이런 기능으로 임의의 수많은 웹 서퍼들은 애플리케이션의 속도가 빨라지고 응답성이 증가하는 것으로 느끼게 되며 상호작용이 반복적으로 이루어지게 된다.

     

     

    XMLHttpRequest

     

    이렇게 새롭고 놀라운 현상이 실지로 발생하기 위해선 XMLHttpRequest라 하는 JavaScript 객체에 관해 완전 익숙해져야 한다. 오랜 시간 동안 몇몇 브라우저에서 사용된 이 객체는 Web 2.0, Ajax 및 앞으로 이 글에서 배우게 될 기타 사항을 이해하는 데 있어 중요한 역할을 하게 된다. 실지로 빠른 이해를 위해 이 객체에서 사용되는 방법 및 속성에 대해 알아보자.

  • open(): 새로운 요청을 서버에 설정함.
  • send(): 요청을 서버에 전송함.
  • abort(): 현 요청에서 벗어남.
  • readyState: 현 HTML 준비상태를 제공함.
  • responseText: 요청에 응답하기 위해 서버에서 재전송하는 텍스트.

    위의 모든 명령을 다 이해하지 못하더라도(중요한 것을 이해하지 못한다 하더라도) 걱정하지 마라. 다음 글에서 각 명령에 대한 방법 및 속성에 관해 배우게 된다. 여기서는 XMLHttpRequest와 관련된 좋은 아이디어를 얻는 게 필요하다.여기서, 각 방법 및 속성은 요청 전송 및 응답 처리와 연관된다는 것을 명심하라. 사실, XMLHttpRequest 객체에 관한 방법, 속성을 다는 알지 못하기 때문에 이들이 매우 간단한 요청/응답 모델과 연관 있다는 것도 모르게 된다. 그래서 놀랍고도 새로운 GUI 객체, 또는 사용자 상호작용을 생성하는 흥미로운 몇 가지 방식 등에 관해서도 배우지 않는다. 별로 재미가 없는 것 같지만 XMLHttpRequest 객체 하나만 잘 사용해도 완전 애플리케이션을 변경할 수 있다.

     

     

    단순함

     

    우선, 새로운 변수를 생성한 다음 이를 XMLHttpRequest객체 인스턴스에 할당한다. JavaScript 상에서는 상당히 간단한 작업이다. 여기서 Listing 1에 보다시피, 객체 이름과 같이 new 키워드를 사용하면 된다.

     

    Listing 1. 새로운 XMLHttpRequest 객체 형성

    <script language="javascript" type="text/javascript">
    var request = new XMLHttpRequest();
    </script>

     

    새로운 객체 형성과정이 그다지 어려운 일은 아니지 않는가? JavaScript에서는 변수 상에 입력하는 과정이 필요 없어 Listing 2(자바에서 XMLHttpRequest 객체를 생성하는 과정)와 같이 값을 전혀 입력할 필요가 없다.

     

    Listing 2. XMLHttpRequest 객체를 생성하기 위한 자바 유사-코드

    XMLHttpRequest request = new XMLHttpRequest();

     

    따라서 JavaScript에서 var로 변수를 생성해 변수에 명칭("request" 등)을 부여한 다음 이를 XMLHttpRequest 객체의 새로운 인스턴스에 할당한다. 이 시점에서 XMLHttpRequest 객체를 사용할 준비가 된 것이다.

     

     

    에러 처리과정

     

    실제 세계에서, 에러가 발생할 수 있어 에러 발생코드는 에러 처리기능을 제공하지 않는다. 따라서 XMLHttpRequest를 생성한 다음 에러가 발생한 경우 이 객체의 기능을 점차 저하시킨다. 일례로, XMLHttpRequest객체를 지원하지 않는 구 브라우저들(믿건 말건, 사람들은 Netscape Navigator의 구 버전을 여전히 이용한다.)이 많아 사용자는 어디서 에러가 났는지 알 필요가 있다. Listing 3은 에러가 난 경우 XMLHttpRequest 객체를 생성하는 방식에 대해 나와 있다. 여기서 XMLHttpRequest 객체로 JavaScript 경고가 발생한다.

     

    Listing 3. 에러 처리기능으로 XMLHttpRequest 객체 생성

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (failed) {
    request = false;
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    </script>

     

    여기서 다음의 각 단계를 반드시 이해한다.

    1.request라는 새 변수를 생성한 다음 이를 거짓으로 설정한다. XMLHttpRequest 객체가 아직 생성되지 않은 상태에서 거짓 값으로 설정한다.
    2. try/catch 블록에서 추가로 다음과 같은 작업을 한다.

    1. XMLHttpRequest 객체를 시험한 다음 생성한다.
    2. 1번 과정이 실패한 경우(catch (failed)), request가 여전히 거짓으로 설정되어 있는지 확인한다.

    3. request가 여전히 거짓으로 설정되어 있는지 확인한다. (에러가 없는 경우, 거짓으로 설정되지 않는다.)
    4. 에러가 발생한 경우(request가 거짓인 경우), JavaScript 경고를 사용해 문제가 발생했다는 사실을 사용자에게 알린다.

    이런 작업은 상당히 간단하다. 실제로 대부분의 JavaScript 및 웹 개발자들은 객체를 읽고 작성하는 것보다는 이해하는 게 더 빠르다. 이제, XMLHttpRequest 객체를 생성하는 일부 에러-증명 코드가 생성되어 에러 여부를 알게 된다.

     

     

    Microsoft로 처리하기

     

    적어도 인터넷 상에서 이 코드를 적용하기 전까지는 이와 같은 작업이 무난하다. 이 코드를 적용하면 그림 1과 같이 에러가 나오게 된다.

    사용자 삽입 이미지

    그림1. 에러화면

    분명, 에러가 발생하고 있다. Internet Explorer는 구식 브라우저가 아니며, 전 세계의 70% 정도가 사용하는 툴이다. 즉, Microsoft 및 Internet Explorer를 지원하지 않는 한 웹 상에서 잘 운영하지 못하게 된다. 따라서 Microsoft 브라우저를 다룰 다른 방식이 필요하다.

    Microsoft는 Ajax를 지원하지만 이전과 다른 XMLHttpRequest 버전을 호출하며 사실은 여러 다른 버전을 호출한다. Internet Explorer의 새로운 버전을 사용하는 경우, Msxml2.XMLHTTP 라 하는 객체를 사용해야 한다. Internet Explorer의 구 버전에서는 Microsoft.XMLHTTP 객체를 사용한다. 그러므로 이와 같은 두 가지 객체 형태를 지원해야 한다. (비-Microsoft 브라우저에 대한 지원기능을 손실하지 않은 상태에서.) 이미 언급한 코드에 Microsoft 지원기능을 추가한 Listing 4를 참조하라.

     

    Microsoft가 잘 작동되는가?
    Ajax에 관해 쓴 글이 많고 Microsoft는 이 영역에 있어 점점 더 관심을 기울이고 있다. 사실 2006년 말에 출시될 것으로 예정된 Microsoft사의 Internet Explorer 최신버전인 버전 7.0은 XMLHttpRequest 객체를 직접 지원해 모든 Msxml2.XMLHTTP 생성코드 대신 new 키워드를 사용한다. 하지만 너무 빠져 들지 마라. 아직도 구 브라우저를 지원해야 하므로 크로스-브라우저 코드는 곧장 사라지지는 않을 전망이다.

     

    Listing 4. Microsoft 브라우저에 지원기능 추가

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    </script>

     

    사실 브라우저에 대한 지원기능이 손실되기 쉽다. 따라서 다음과 같이 단계별로 하길 권한다.

    1. request 명의 새 변수를 생성한 다음 이를 거짓으로 설정한다. XMLHttpRequest 객체가 아직 생성되지 않았다는 전제 하에 거짓으로 설정한다.
    2. try/catch 블록에서 추가로 다음과 같은 작업을 한다.

    1. XMLHttpRequest 객체를 시험한 다음 생성한다.
    2. 1번 과정이 실패한 경우 (catch (trymicrosoft)):
      1. 새로운 Microsoft 버전 (Msxml2.XMLHTTP)을 이용해 Microsoft 호환성 객체를 시험한 다음 생성한다.
      2. 전 과정이 실패한 경우(catch (othermicrosoft)), 이전 Microsoft 버전(Microsoft.XMLHTTP)을 이용해 Microsoft 호환성 객체를 시험한 다음 생성한다.
    3. 그래도 실패한 경우(catch (failed))에는, request가 여전히 거짓으로 설정되어 있는지 확인한다.

    3. request가 여전히 거짓으로 설정되어 있는지 다시 확인한다. (에러가 나지 않는 경우 거짓으로 설정되지 않는다.)
    4. 그래도 문제가 발생한 경우(request가 거짓인 경우), JavaScript 경고를 사용해 사용자에게 문제가 발생했다는 것을 알린다.

    코드를 변화시키고 Internet Explorer 상에서 다시 한 번 시도해 보면 에러 메시지 없이 생성한 형태를 보게 된다. 본인의 경우엔 그와 같은 시도가 그림 2와 같은 것으로 나타난다

    사용자 삽입 이미지

    그림 2. 정상적으로 작동하는 Internet Explorer

     

     

    동적/정적

     

    Listing 1, 3, 4를 다시 보면 모든 코드는 script 태그 내에 직접 포함되어 있다는 것을 알게 된다. JavaScript가 그와 같이 코드화되고 메소드/기능 본체 내에 들어가지 않은 경우, 이를 정적 JavaScript라 한다. 이는 페이지가 스크린 상에 나타나기 전 코드를 실행했다는 것을 의미한다.(코드 및 브라우저가 따로 실행될 경우, 사양과는 100% 일치하지 않지만 사용자와 페이지가 상호작용하기 전, 코드를 실행했다는 건 확실하다.) 일반적으로 그렇게 해서 대부분의 Ajax 프로그래머가 XMLHttpRequest 객체를 생성한다.

    즉, Listing 5처럼, 메소드에 이와 같은 코드를 첨가한다.

     

    Listing 5. XMLHttpRequest 생성코드를 메소드로 이동하기

    <script language="javascript" type="text/javascript">

    var request;

    function createRequest() {
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    }
    </script>

     

    이와 같이 코드를 설정하면, Ajax 작업을 하기 전 이와 같은 메소드를 호출해야 한다. 그럴 경우 Listing 6과 같은 것을 얻을 수도 있다.

     

    Listing 6. XMLHttpRequest 생성 메소드 사용

    <script language="javascript" type="text/javascript">

    var request;

    function createRequest() {
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");
    }

    function getCustomerInfo() {
    createRequest();
    // Do something with the request variable
    }
    </script>

     

    Listing 6을 활용하면 에러 통지기능을 지연시키므로 대부분의 Ajax 프로그래머들은 위의 방법을 활용하지 않는다. 10/15 필드가 있는 복잡한 형태에 선택상자 등등이 있다고 상상해 보면 사용자가 필드 14에 있는 텍스트를 형식에 나온 대로 기입할 때 몇 가지 Ajax 코드를 전송한다. 이 시점에서 getCustomerInfo()를 실행해 XMLHttpRequest 객체를 생성하려 했지만 실패한다. (이 예에서) 그러면 사용자에게 이 애플리케이션을 사용할 수 없다는 것을 경고로 알리게 된다 (많은 경우). 하지만 사용자는 이미 형식 상에서 데이터를 기입하느라 시간을 보냈다. 상당히 짜증을 내게 되면서 사용자는 결국엔 사이트로 관심을 기울이지 않게 된다.

    정적 JavaScript를 사용하는 경우, 사용자는 페이지에 에러가 나자마자 에러를 포착하게 된다. 또 짜증나는가? 아마도 사용자로선 웹 애플리케이션이 브라우저 상에서 작동되지 않을 때 상당히 죽을 맛일 게다. 하지만, 10분 동안 정보를 기입한 뒤 동일한 에러가 나오는 것보다는 확실히 낫다. 따라서 정적으로 코드를 설정하고 난 다음 발생할 수 있는 문제에 대해 사용자가 조기에 알도록 하는 게 중요하다고 본다.

     

     

    XMLHttpRequest로 요청 전송하기

     

    요청 객체가 있으면 요청/응답 사이클을 시작한다. 여기서 요청을 생성한 다음 응답을 수신하는 게 XMLHttpRequest 객체에서 이루고자 하는 유일한 것임을 명심하라. 사용자 인터페이스 변환, 이미지 교환 및 서버에서 재전송하는 데이터 해석 등의 작업은 페이지에 있는 JavaScript, CSS 또는 기타 코드에서 일어나는 현상이다. XMLHttpRequest 객체가 사용 대기 중일 때 서버에 요청을 생성하게 된다.

     

     

    샌드박스

     

    Ajax는 샌드박스 보안 모델이 포함되어 있다. 그 결과 Ajax 코드(특히 XMLHttpRequest 객체)는 실행 중인 동일한 도메인에만 요청을 생성한다. 다음 글에서 보안 및 Ajax에 관해 더 많은 것을 배우게 되겠지만 지금으로선 로컬 머신 상에서 작동하는 코드만으로도 로컬 머신 상의 서버측 스크립트에 요청을 생성한다는 것을 알게 된다. www.breakneckpizza.com상에서 Ajax 코드를 실행하는 경우, www.breakneckpizza.com상에서 실행하는 스크립트에 관한 요청을 생성한다.

     

     

    서버 URL 설정

     

    여기서 우선 결정할 것은 연결할 서버의 URL이다. URL은 Ajax에서만 있는 것은 아니다. 분명URL을 구성하는 방법에 대해 알아야 한다. 하지만 URL은 연결 설정 시 여전히 필수적인 것이다. 대부분의 애플리케이션에서 사용자가 다루는 형식에서 나온 데이터와 정적 데이터 세트를 결합해 URL을 구성한다. 예를 들어 Listing 7에서는 전화번호 필드의 값을 알아내고 그 데이터를 이용해 URL을 구성하는 JavaScript에 관해 나와 있다.

     

    Listing 7. 요청 URL 구축

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    }
    </script>

     

    여기서 딴지를 걸만한 게 없다. 먼저 여기 나온 코드는 phone 이라는 이름의 새로운 변수를 생성, 이를 "phone"의 ID로 형식 필드 값을 지정한다. Listing 8에는 phone 필드 및 id 속성에서 알 수 있는 특수 형태에 관한 XHTML에 관해 나와 있다.

     

    Listing 8. Break Neck Pizza 형식

    <body>
    <p><img src="breakneck-logo_4c.gif" alt="Break Neck Pizza" /></p>
    <form action="POST">
    <p>Enter your phone number:
    <input type="text" size="14" name="phone" id="phone"
    onChange="getCustomerInfo();" />
    </p>
    <p>Your order will be delivered to:</p>
    <div id="address"></div>
    <p>Type your order in here:</p>
    <p><textarea name="order" rows="6" cols="50" id="order"></textarea></p>
    <p><input type="submit" value="Order Pizza" id="submit" /></p>
    </form>
    </body>

     

    사용자가 전화번호를 입력/변경하는 경우, Listing 8에서 보는 대로 getCustomerInfo() 메소드가 나온다는 사실을 알아둔다. 이 방법으로 전화번호를 알아낸 다음 url 변수에 저장된 URL 문자열을 구성하는 데 활용한다. Ajax 코드는 묶여져 있고 동일한 도메인에만 연결되기 때문에 URL에서 도메인 명칭이 필요 없다는 사실을 명심해야 한다. 이 예에서 스크립트 명칭은 /cgi-local/lookupCustomer.php다. 결국 전화 번호는 상기 스트립트에 Get 매개변수로서 추가된다. ("phone=" + escape(phone))

    이전에 escape() 메소드를 알지 못한 경우, 이 메소드는 정확히 명백한 텍스트로 전송될 수 없는 문자로부터 벗어나는 데 사용된다. 예를 들어, 전화번호에서의 임의의 공간은 %20 문자로 바뀌며 이로 인해 URL과 같이 문자를 전송할 수 있게 된다.

    그런 다음 필요한 많은 매개변수를 추가한다. 예를 들어 또 다른 매개변수를 추가하고자 한다면 URL 상에 추가해 여러 매개변수를 ampersand(&) 문자로 분리시킨다. (첫 번째 매개변수는 의문부호(?)로 스크립트 명칭으로부터 분리되어 있다.)

     

     

    요청 열기

     

    URL이 연결된 상태에서 XMLHttpRequest 객체 상의 open() 메소드를 사용해 요청을 구성한다. 이 메소드는 5가지 매개변수가 있다.

  • request-type: 전송 요청 형태. GET/POST가 일반적인 값이고 HEAD 요청도 전송함.
  • url: 연결된 URL.
  • asynch: 비동기 요청을 설정할 경우 참값, 동기식 요청인 경우에는 거짓임. 이 매개변수는 옵션이고 기본값이 참값임.
  • username: 사용인증을 요구할 경우 사용자이름을 지정한다. 옵션 매개변수고 기본값이 없다.
    password: 사용인증을 요구할 경우 암호를 지정한다, 옵션 매개변수고 기본값이 없다.

    일반적으로 5개의 매개변수 중 3개의 첫 매개변수만 사용한다. 사실, 비동기식 요청을 원할 경우, 제3의 매개변수로 "true"을 설정한다. 그게 기본값 설정이다. 하지만 훌륭한 자체 문서화 작업으로 이 작업을 통해 항상 요청이 비동기식인지 아닌지 여부를 알 수 있다.

    기본값 설정을 완료한 다음 일반적으로 Listing 9와 비슷한 라인으로 작업을 완료한다.

     

    open() 메소드가 열릴까?
    인터넷 개발자들은 open() 메소드의 정확한 기능에 대해 서로 의견이 다르다. 실제로 이 메소드에 없는 기능은 요청 열기 기능이다. 네트워크 및 XHYML/Ajax 페이지와 연결 스크립트 간 데이터 이동을 감시했더라면 open() 메소드 호출 시 트래픽 현상이 발생하지도 않았을 것이다. Open() 명칭이 선택된 이유는 여전히 불분명하지만 분명 훌륭한 명칭선택이라 볼 수는 없다.

     

    Listing 9. 요청 열기

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    }

     

    일단 URL을 이해했으면 그 다음에는 상당히 단순하다. 대부분의 요청의 경우, GET을 사용하는 것만으로도 충분하다. (다음 글에서 POST를 사용하고자 하는 경우를 보게 된다.) URL과 같이 open() 메소드를 사용하기만 하면 된다.

     

     

    비동시성에 대한 문제

     

    이 시리즈의 후반부에서는 비동기식 코드 작성 및 사용에 관한 설명에 할애할 것이다. 하지만 open() 메소드에서 마지막 매개변수가 중요한 이유에 대해 알아야 한다. 정상 요청/응답 모델에서 Web 1.0,을 생각해 보면 클라이언트(로컬 머신 상에서 실행하는 브라우저/코드)는 서버에 요청을 생성한다. 그 요청은 동기식이다. 다시 말하면 클라이언트는 서버로부터의 응답이 올 때까지 대기한다. 클라이언트가 대기 중일 때 일반적으로 적어도 대기 중인 여러 통지 형태 중 하나만 얻으면 된다.

  • Hourglass (Windows 경우에만).
  • 회전 비치볼(일반적으로 Mac 머신에서의 경우임).
  • 애플리케이션은 기본적으로 정지되고 때로 커서가 변환되기도 한다.

    이런 특성으로 웹 애플리케이션은 볼품없거나 느린 것으로 보여진다. 즉 실제 대화성이 부족한 것이다. 버튼을 누르면 트리거된 요청이 응답되기 전까지는 애플리케이션을 사용할 수 없다. 광범위한 서버 처리작업을 요구하는 요청을 생성할 경우 대기시간은 어마어마할 것이다. (적어도 오늘날 멀티 프로세서, DSL, 비대기 세계의 경우처럼.)

    하지만 비동기식 요청은 서버가 응답할 때까지 대기하지 않는다. 요청을 전송한 다음에는 애플리케이션을 계속 실행한다. 사용자는 웹 형식에서 데이터를 기입한 다음 기타 버튼을 클릭하고 형식 기입을 종료한다. 회전하는 비치볼, 소용돌이치는 hourglass 및 대형 애플리케이션 정지 등의 현상이 생기지 않는다. 서버는 재빨리 요청에 응답하고 서버가 종료된 경우, 요청으로 인해 원 요청자는 서버가 종료되었음을 알게 된다. 결국 볼품없고 느린 대신 민감하고 대화성 있고 빠른 애플리케이션을 얻게 된다. 정확한 GUI 구성요소 및 웹 디자인 패러다임만 가지고는 느리고 동기적인 요청/응답 모델의 한계를 극복할 수 없다.

     

     

    요청 전송

     

    일단 open() 메소드로 요청을 구성하고 나면 요청 전송 준비를 한다. 다행히도, 요청을 전송하는 메소드를 open()의 경우에 비해 더 적절하게 명명한다. 명칭은 단순히 send()이다.

    send() 메소드는 단 하나의 매개변수인 전송 컨텐트만 있으면 된다. 그 메소드에 대해 너무 깊게 생각하기 이전에 이미 URL 자체를 통해 데이터를 전송했음을 기억하라.

     

    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);

     

    send() 메소드를 사용해 데이터를 전송하지만 URL자체를 통해서도 된다. 사실, GET 요청(일반 Ajax 이용률의 80%를 이루고 있음.)에서는 URL에서 데이터를 전송하는 게 더 용이하다. 안전한 정보/XML을 전송하기 시작한 경우, send() 메소드를 통한 전송 컨텐트에 대해 알아보려고 할 것이다. (이 시리즈 후반부에 안전한 데이터 및 XML 메시징에 대해 논의한다.) send()를 통해 데이터를 전송하지 않아도 되는 경우, 이 메소드에 대한 인수로 null을 전송하면 된다. 따라서 이 글을 통해 알게 된 예에서 보듯 요청 전송작업을 하는 게 필요하다.(Listing 10)

     

    Listing 10. 요청 전송

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.send(null);
    }

     

     

    콜백 메소드 지정

     

    이 시점에서, 새롭고 혁신적이거나 비동기적이라고 생각될 만한 작업을 거의 하지 못했다. open() 메소드의 키워드 "true"는 비동기식 요청을 설정한다고 하는 게 정확하다. 하지만 그거 말고도 open() 메소드 코드는 Java servlets및 JSP, PHP/Perl이 함께 어우러진 프로그래밍과 유사하다. 그렇다면 Ajax 및 Web 2.0에 담긴 커다란 비밀은 무엇일까? 그 비밀은 onreadystatechange라는 명칭의 XMLHttpRequest의 단순한 속성에서 나오게 된다.

    먼저, open() 코드에서 생성된 과정에 대해 확실히 이해한다.(Listing 10) 요청을 설정하고 생성한다. 게다가 이 XMLHttpRequest는 동기식 요청이라 자바 메소드(예에 나온 getCustomerInfo())는 서버 상에서 대기하지 않는다. open() 코드는 계속 진행되고 이 경우 자바 메소드는 정지되며 제어기능은 형태로 나오게 된다. 사용자들은 계속 정보를 입력하고 애플리케이션은 서버 상에서 대기하지 않는다.

    이렇게 되면 재미있는 질문이 나오게 된다. 서버가 요청 처리 과정을 완료할 시 발생하는 현상은 어떤 것인가? 적어도 코드가 지금 당장 유지되는 한은 아무 현상도 없다 라는 말이 정답이다. 분명 좋은 현상은 아니다. 따라서 서버에 XXMLHttpRequest객체에 의해 전송된 요청에 관한 처리과정을 완료할 경우 서버는 몇 가지 형태의 명령어를 포함해야 한다

    이런 상황에서 바로 onreadystatechange 속성이 작용한다. 이 속성으로 콜백 메소드를 지정한다. 콜백 메소드로 서버는 웹 페이지 코드로 다시 호출한다. 그러면서 서버에 어느 정도의 제어 기능이 전달된다. 또한 서버에서 요청을 종료할 때 콜백 메소드는 XMLHttpRequest 객체, 특히 onreadystatechange 속성에서 나타난다. 그 속성에서 지정된 방법이 어떤 메소드든 모두 호출된다. 웹 페이지 자체에서 벌어지는 현상에 관계없이 웹 페이지로 다시 호출할 때 서버에서 개시하기 때문에 콜백이라 부르는 것이다. 예를 들어, 사용자가 의자에 앉아 키보드를 사용하지 않는 동안 콜백 메소드를 호출하기도 한다. 하지만 사용자가 입력하고 마우스를 움직이고, 화면 이동시키고 버튼을 클릭하는 동안에도 콜백 메소드를 호출하기도 한다. 사용자가 하는 업무는 그다지 중요하지 않다.

    이런 상황에서 비동시성이 작용한다. 사용자는 다른 레벨에 있는 동안 한 레벨에 있는 형식을 작동하고 서버는 요청에 응답한 다음 onreadystatechange 속성에서 명시된 콜백 메소드를 전송한다. 따라서 Listing 11에 나온 대로 코드에 콜백 메소드를 지정해야 한다.

     

    JavaScript에서의 기능 참조
    JavaScript는 약결합 언어며 이 언어에서 모두 다 변수로 참조 가능하다. updatePage()라는 이름의 함수를 선언한 경우, JavaScript는 그 함수 이름을 변수로 취급한다. 즉 updatePage()라는 이름의 변수로 코드에 있는 함수를 참조한다.

     

    Listing 11. 콜백 메소드 설정

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

     

    특히 onreadystatechange 속성이 결정된 코드 위치에 주의를 기울인다. 그 위치는 바로 send()가 호출되기 전의 위치다. 요청을 전송하기 전 onreadystatechange 속성을 설정해야 한다. 그래야만, 서버에서 요청 응답을 종료할 때 onreadystatechange 속성을 탐지하게 된다. 인제는 이 글의 마지막 부분에서 중점적으로 다룰 updatePage() 코드에 대해 알아보겠다.

     

     

    서버 응답 처리

     

    요청을 만들면 사용자는 웹 형식에서 여유롭게 작업하며 (서버에서 요청을 처리하는 동안에는) 서버는 요청 처리과정을 완료한다. 서버는 onreadystatechange 속성에서 나타나며 호출방법을 결정한다. 그런 일이 일어나면 비동기식/동기식 애플리케이션 등의 기타 다른 애플리케이션으로 애플리케이션을 생각할 수도 있다. 즉, 서버에 응답하는 특수 액션 작성 메소드를 취할 필요가 없다. 형식을 변환하고, 사용자를 또 다른 URL에 안내하거나 서버에 응답하는 데 필요한 것들을 하면 된다. 이 단락에서 우리는 서버 응답 및 이에 대한 일반조치 및 사용자가 아는 형식의 일부를 자유롭게 변경하는 것에 대해 중점적으로 다루겠다.

     

     

    콜백 및 Ajax

     

    이미 서버가 종료될 때의 현상을 서버가 인식하는 방법에 대해 이미 알았다. 일단 XMLHttpRequest 객체의 onreadystatechange 속성을 실행함수 이름에 설정한다. 그 다음 서버에서 요청을 처리하면 서버는 자동적으로 그 함수를 호출한다. 또한 콜백 메소드에 있는 임의의 매개변수에 대해 그리 걱정하지 않아도 된다. Listing 12와 같이 단순한 메소드에서 시작하기 때문이다.

     

    Listing 12. 콜백 메소드 코드화

    <script language="javascript" type="text/javascript">
    var request = false;
    try {
    request = new XMLHttpRequest();
    } catch (trymicrosoft) {
    try {
    request = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (othermicrosoft) {
    try {
    request = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (failed) {
    request = false;
    }
    }
    }

    if (!request)
    alert("Error initializing XMLHttpRequest!");

    function getCustomerInfo() {
    var phone = document.getElementById("phone").value;
    var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
    request.open("GET", url, true);
    request.onreadystatechange = updatePage;
    request.send(null);
    }

    function updatePage() {
    alert("Server is done!");
    }
    </script>

     

    이렇게 하면 간단한 경고가 울리면서 서버가 종료될 때를 알려준다. 자체 페이지에 updatePage() 코드를 시험하고 페이지를 저장한 다음 브라우저에 페이지를 끌어올린다.(이 예에서 XHTML을 원할 경우, Listing 8을 참조한다.) 전화번호를 입력하고 필드를 설정하지 않을 경우 경고는 팝업되어야 한다. 하지만 확인을 클릭한 경우에도 경고는 팝업을 연속한다.

    사용자 삽입 이미지

    그림 3. 경고를 팝업하는 Ajax 코드

    브라우저에 ‘따라 웹 형식에서 경고 팝업을 중지할 때까지 경고가 두 번, 세 번, 심지어는 네 번까지 울린다. 그러면 무슨 일이 벌어지고 있는 것인가? 요청/응답 사이클의 중요 구성요소인 HTTP 준비상태에 대해 고려하지 않았다.

     

     

    HTTP 준비 상태

     

    초기에 필자는 서버에서 요청이 종료되면 XMLHttpRequest의 onreadystatechange 속성에서 호출되는 메소드를 탐지한다고 가르쳤다. 사실, HTTP 준비 상태가 변할 때마다 서버에서는 방금 전에 언급한 메소드를 호출한다. 그러면 그 말이 의미하는 것은 무엇인가? 일단 먼저 HTTP 준비상태에 관해 이해해야 한다.

    HTTP 준비상태는 요청의 상태를 나타내며 주로 요청을 시작했는지, 요청에 응답했는지, 요청/응답 모델을 완성했는지 여부를 결정하는 데 활용된다. HTTP 준비상태는 서버에서 공급되는 모든 응답 텍스트/데이터를 읽어 들이는 데 안전한지 여부를 결정하는 데 도움이 되기도 한다. 여기서 Ajax 애플리케이션에서의 5가지 준비상태에 관해 알아야 한다.

  • 0: 요청이 개시되지 않음.(open()을 호출하기 전)
  • 1: 요청을 설정했지만 전송되지는 않았음.(send()를 호출하기 전)
  • 2: 요청을 설정한 다음 처리 중(이 시점에서 일반적으로 응답에서 나온 컨텐트 헤더를 얻는다.)
  • 3: 요청 처리 중; 종종 응답에서 부분적인 데이터를 사용할 수 있다. 하지만 서버는 자체 응답이 완료되지 않았다.
  • 4: 응답 완료. 서버 응답을 얻은 다음 이를 활용한다.

    거의 모든 크로스-브라우저 이슈에서도 그렇듯 예상치 못한 방식으로 이와 같은 준비 상태를 이용한다. 준비상태는 항상 0~1, 2, 3, 4로 단계적으로 이동한다고 예상할지도 모른다. 하지만 실지로는 그렇지 않다. 0/1상태를 보고하지 않고 곧바로 2로 건너뛰어 3,4까지 가는 브라우저도 있고 모든 상태를 보고하는 브라우저도 있다. 지난 단락에서 보듯, 서버에서는 몇 번이고 updatePage()코드를 호출하고 호출 때마다 경고 상자가 팝업된다. 그건 여러분이 의도하는 바가 아닐 것이다!

    Ajax 프로그래밍의 경우, 직접 다뤄야 할 상태는 오로지 상태 4다. 이는 서버 응답이 완료되었고 응답 데이터를 점검, 사용하는 데 안전하다는 것을 의미한다. 이를 설명하기 위해 콜백 메소드에 나온 첫 번째 라인은 Listing 13에서 나온 바여야 한다.

     

    Listing 13. 준비상태 점검

    function updatePage() {
    if (request.readyState == 4)
    alert("Server is done!");
    }

     

    이런 변환으로 서버가 정말로 그 과정을 종료했는지 확인한다. Ajax 코드의 이 버전을 실행한다. 그러면 한 번에 경고 메시지만을 얻어야 한다.

     

     

    HTTP 상태 코드

     

    Listing 13에서의 코드의 성공에도 불구하고 여전히 문제는 상존한다. 그러면 서버가 요청에 응답하고 요청 처리과정을 완료했지만 에러를 보고한 경우는 어찌 되는가? Ajax, JSP, 정규 HTML 형식 또는 기타 형태의 코드로 서버측 코드를 호출 중인 경우에 서버측 코드를 관찰해야 한다는 점을 주목한다. 웹 세계에서는 HTTP 코드로 요청에서 발생할지도 모르는 여러 가지 상황을 다룬다.

    예를 들어, URL에 관한 요청을 입력했지만, URL을 부정확하게 입력해 404 에러코드가 나와 페이지가 없어졌다고 해보자. 이 코드는 HTTP 요청을 상태로 수신하는 여러 상태 코드 가운데 하나에 지나지 않는다.(참고자료) 403, 401 코드는 둘 다 안전하거나 금지된 데이터 처리를 의미하는 것으로 역시 공통적이다. 각 경우에 있어 이런 코드들은 완전 응답에서 나오는 코드들이다. 즉, 서버는 요청을 수행하지만(HTTP 준비상태는 4임), 클라이언트가 예상한 데이터가 나오지 않을 수도 있다.

    여기서 준비 상태에 덧붙여, HTTP 상태를 점검할 필요가 있다. 단순히 확인을 의미하는 상태코드 200을 탐색하는 중에 있다. 준비상태 4와 상태코드 200인 상태에서 서버 데이터를 처리할 준비가 되어 있고 그 데이터는 반드시 요청된 형태여야 한다. (에러 또는 문제가 있는 정보 단편이 아님.) Listing 14에서 보듯이 콜백 메소드에 또 다른 상태 점검기능을 추가한다.

     

    Listing 14. HTTP 상태 코드 점검

    function updatePage() {
    if (request.readyState == 4)
    if (request.status == 200)
    alert("Server is done!");
    }

     

    복잡성을 줄이고 더 강력한 에러 처리기능을 추가하려면 기타 상태코드에 관한 점검기능/두 가지 기능을 추가할지도 모른다. Listing 15에 있는 updatePage()의 수정 버전을 점검한다.

     

    Listing 15. 간단한 에러 점검기능 추가

    function updatePage() {
    if (request.readyState == 4)
    if (request.status == 200)
    alert("Server is done!");
    else if (request.status == 404)
    alert("Request URL does not exist");
    else
    alert("Error: status code is " + request.status);
    }

     

    이제 getCustomerInfo()에 있는 URL을 비실제 URL로 변환시킨 다음 일어나는 현상을 보면 요청한 URL은 존재하지 않는다는 의미의 경고가 울린다. 이런 경고 가지고도 모든 에러상태를 거의 처리하지 않는다. 하지만 웹 애플리케이션에서 발생할 수 있는 문제의 80%는 해결하는 단순한 진전이 아닐 수 없다.

     

     

    응답 텍스트 읽기

     

    인제 요청을 준비상태를 통해 완전히 처리하고, 서버로 정상적인 확인 응답을 상태 코드를 통해 받았으므로 서버에서 재전송되는 데이터를 최종적으로 처리한다. 이 데이터는 XMLHttpRequest객체의 responseText 속성에 저장된다.

    포맷/길이에 의한 responseText 속성의 텍스트 모양에 관한 상세사항은 이 장에서는 논하지 않기로 한다. 이렇게 되면 서버는 이 텍스트를 실지로 임의로 설정한다. 예를 들어, 한 스크립트로 콤마-분리 값 및 파이프-분리 값이 나오고 또 다른 파이프-분리 값은 텍스트의 긴 문자열로 나올 수도 있다. 이런 현상은 서버에 따라 다르게 된다.

    이 글에서 사용된 예의 경우, 서버는 파이프 기호로 분리된 고객의 마지막 순서 및 주소가 나오게 된다. 형식의 구성요소 값을 설정하는 데 순서 및 고객의 마지막 순서 및 주소를 활용한다. Listing 16은 디스플레이를 업데이트하는 코드에 대해 나와 있다.

     

    Listing 16. 서버 응답 처리

    function updatePage() {
    if (request.readyState == 4) {
    if (request.status == 200) {
    var response = request.responseText.split("|");
    document.getElementById("order").value = response[0];
    document.getElementById("address").innerHTML =
    response[1].replace(/\n/g, "");
    } else
    alert("status is " + request.status);
    }
    }

     

    우선 JavaScript split() 메소드를 이용해 파이프 기호 상에서 responseText를 얻고 분할한다. 값은 response의 형태로 배열된다. 고객의 마지막 순서에 관한 첫 번째 값은 response[0] 형태의 배열로 처리되고 "순서" ID와 함께 필드 값으로 설정된다. response[1]에서 두 번째 값은 고객 주소로 처리하는 데 좀 더 오랜 시간이 걸린다. 주소 라인은 정상 라인 분리자("\n" 문자) 로 분리되기 때문에 코드는 정상라인 분리자를 XHTML-형 라인 분리자(< br />)로 바꾸어야 한다. 정규 식 및 replace() 함수의 활용을 통해 분리자를 바꾸는 과정이 이루어진다. 결국 변경 텍스트는 HTML 형태에서 div 의 내부 HTML로 설정된다. 결국 그림 4에도 나오듯이 텍스트 형식은 순식간에 고객정보로 업데이트된다.

    사용자 삽입 이미지

    그림 4. 고객 데이터 검색 후의 Break Neck 형식

     

    이 글을 마치기 전에 XMLHttpRequest 객체의 중요한 속성 중 하나인 responseXML 속성에 대해 언급한다. 이 속성은 서버가 XML과의 응답을 선택한 경우, XML 응답을 포함한다. (상상이 되는가?) XML 응답 처리는 평범한 텍스트 처리과정과 상당히 다르며, 문장분석 및 문서 객체 모델(DOM)을 포함한다. 다음 글에서는 XML에 대해 다루게 된다. responseXML 은 공통적으로 responseText과 관련된 논의에서 나오기 때문에 언급할 가치가 있는 것이다. 많은 단순 Ajax 애플리케이션의 경우, responseText만 있으면 된다. 하지만 Ajax 애플리케이션을 통해 XML을 처리하는 방법에 대해서도 곧 배우게 된다.

     

     

    맺음말

     

    XMLHttpRequest 객체에 대해서는 인제 좀 지루하게 들릴지도 모른다. 필자는 단일 객체, 특히 간단한 객체에 대한 전반적인 글을 거의 읽지 못했다. 하지만 Ajax를 사용하고 작성하는 각 페이지 및 애플리케이션에서 계속 XMLHttpRequest 객체를 사용하게 된다. 아직도 XMLHttpRequest 객체에 대해 언급되지 않은 것들이 많은 건 사실이다. 다음 글에서는 요청에서 GET 및 POST를 사용하고 서버로부터의 응답 및 요청의 컨텐트 헤더를 설정하고 읽어들이는 방법을 배운다. 그러면 요청을 코드화하고 심지어는 요청/응답 모델에서 XML을 다루는 방법을 배우게 될 것이다.

    좀 더 상세하게 나가면 일반적으로 사용하는 Ajax 툴킷에 관해서도 알게 된다. 이 툴킷은 본 글에서 논의된 상세사항의 대부분을 실지로 요약한 것이다. 한편 툴킷을 손쉽게 이용하는 경우, 낮은 레벨의 상세사항을 코드화하는 이유에 대해 궁금해할 수도 있다. 사실은 애플리케이션 상에서 발생하는 현상을 이해하지 못하는 경우, 애플리케이션에서 일어나는 에러를 이해하는 게 어려워진다.

    따라서, 이와 같은 사항을 간과하거나 지나치면 안 된다. 가변성 툴킷에서 에러가 발생할 경우, 머리를 끄적이면서 e-메일을 보내지 않아도 된다. 직접 XMLHttpRequest 사용법을 이해하면 가장 이상한 문제를 디버그하고 수정하는 것도 쉬워진다. 툴킷에 집중하면서 모든 문제를 해결하지 않는 한 툴킷은 그런대로 괜찮다.

    따라서, XMLHttpRequest 객체에 대해 친숙해져라. 사실, 툴킷을 사용하는 Ajax 코드를 실행할 경우 XMLHttpRequest 객체 및 속성, 메소드를 사용해Ajax 코드를 재작성한다. 상당히 좋은 연습이 될 것이며 현재 이 객체에서 벌어지는 현상에 대해 더 잘 이해하게 될 것이다.

    다음 글에서는 XMLHttpRequest에 대해 좀 더 자세하게 들어간다. 이 객체에서 어려운 속성(responseXML등의), POST 요청 사용법 및 몇 가지 다른 포맷에서의 데이터를 전송하는 방법을 조사할 것이다. 한 달 동안 코드화 작업을 시작해 코드를 다시 점검한다.

     

    참고자료

    교육
    - Ajax 마스터, Part 1: Ajax 소개 (developerWorks, December 2005)
    - 자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현 (developerWorks, September 2005)
    - 자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화 (developerWorks, October 2005)
    - Call SOAP Web services with Ajax (developerWorks, October 2005)
    - Google GMail
    - Flickr
    - Ajax: A New Approach to Web Applications
    - Why Ajax Matters Now
    - Microsoft Developer Network's XML Developer Center.
    - online documentation.
    - HTTP status codes
    - developerWorks Web Architecture zone

    제품 및 기술 얻기
    - Head Rush Ajax by Elisabeth Freeman, Eric Freeman, and Brett McLaughlin (February 2006, O'Reilly Media, Inc.)
    - Java and XML, Second Edition by Brett McLaughlin (August 2001, O'Reilly Media, Inc.)
    - JavaScript: The Definitive Guide by David Flanagan (November 2001, O'Reilly Media, Inc.)
    - Head First HTML with CSS & XHTML by Elizabeth and Eric Freeman (December 2005, O'Reilly Media, Inc.)

    토론
    -포럼에 참여하기.
    -developerWorks blogs.

     

     

    사용자 삽입 이미지


    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3054

      Comments,     Trackbacks
    [Ajax] Ajax 마스터하기 - Ajax 소개 [PART 01]

    [Ajax] Ajax 마스터하기 - Ajax 소개 [PART 01]

     

     

    개요
    PART 01/Ajax 소개
    PART 02/JavaScript와 Ajax를 이용한 비동기식 요청
    PART 03/Ajax의 고급 요청 및 응답
    PART 04/웹 응답에 DOM 활용하기
    PART 05/DOM 다루기


     

    HTML, JavaScript™, DHTML, DOM으로 구성된 Ajax는 볼품없는 웹 인터페이스를 인터랙티브 Ajax 애플리케이션으로 변형하는 획기적인 방식이다. Ajax 전문가인 필자는 이러한 기술들이 어떻게 작용하는지 전체적인 개요를 비롯하여 세부사항 까지 설명한다. 또한 XMLHttpRequest 객체 같은 Ajax의 중심적인 개념들을 소개한다.

     

    5년 전, XML에 대해 무지했다면 아무도 얘기할 상대가 없는 미운 오리 새끼 신세가 되었을지도 모르겠다. Ruby 프로그램이 주목을 받았던 8개월 전, Ruby 프로그램 언어 기능에 대해 알지 못했던 프로그래머들은 냉수기 관련 산업세계에서 환영 받지 못했다. 그런 것처럼, 최신 기술단계로 입문하고자 한다면 Ajax에 대해 알아야 한다.

    하지만 Ajax는 일시적으로 유행하는 툴이 아니다. 웹 사이트를 구축하는 강력한 방식이며 완전히 새로운 언어를 배우는 것보다는 그다지 어렵지 않다.

    Ajax에 관해 자세히 들어가기 전에 잠시 Ajax의 기능에 대해 알아보자. 오늘날 애플리케이션을 작성할 시 두 가지 애플리케이션이 있다.

    • 데스크톱 애플리케이션
    • 웹 애플리케이션

    두 애플리케이션은 다 친숙한 것들이다. 일반적으로 데스크톱 애플리케이션은 CD상에 배치된 다음 (또는 웹 사이트에서 다운로드) 컴퓨터에 완전 설치된다. 이 애플리케이션은 인터넷을 이용해 업데이트를 다운로드하기도 하지만 애플리케이션 실행 코드는 데스크톱 상에 상주해 있다. 전혀 새로운 것이 아닌 웹 애플리케이션은 웹 서버 상에서 실행되며 웹 브라우저 상에서 접속된다.

    하지만 두 애플리케이션에 대한 코드 실행 위치보다 애플리케이션 작동방식 및 애플리케이션과 사용자와의 상호작용방식이 중요하다. 일반적으로 데스크톱 애플리케이션은 상당히 빠르고 (컴퓨터 상에서 실행되고 인터넷 상에서 대기 중인 상태가 안 나온다.), 대형 사용자 인터페이스(일반적으로 운영체제와 상호작용)를 갖추며 상당히 동적이다. 거의 대기시간 없이 메뉴 및 하위 메뉴를 클릭, 지시, 입력하고 풀업한다.

    반면 웹 애플리케이션은 가장 최신 것이며 데스크톱에서는 전혀 얻을 수 없는 서비스를 제공한다.(Amazon.com 및 eBay를 생각해 볼 것.) 하지만 웹 애플리케이션 기능으로 인해 서버 응답 대기, 스크린 재생 대기, Request 컴백 및 새 페이지 생성에 관한 대기 기능 등이 부수된다.

    분명 지나친 단순화 과정임에는 틀림없지만 기본 개념은 얻게 된다. 이미 눈치를 챘겠지만 Ajax는 데스크톱 애플리케이션 및 항상 업데이트 되는 웹 애플리케이션의 기능 및 상호작용 간의 차이를 줄여주는 역할을 한다. 여러분은 마치 데스크톱 애플리케이션에서 찾은 것처럼 동적 사용자 인터페이스 및 가상 제어기능을 사용한다. 하지만 웹 애플리케이션 상에서 데스크톱 애플리케이션을 이용할 수 있다. 그러면 대기 중인 것이 무엇인가? Ajax 및 볼품없는 웹 인터페이스가 응답 Ajax 애플리케이션으로 변환되는 과정에 대해 살펴보기로 하자.

    그러면 대기 중인 것이 무엇인가? Ajax 및 볼품없는 웹 인터페이스가 응답 Ajax 애플리케이션으로 변환되는 과정에 대해 살펴보기로 하자.

     

     

    오래된 기술, 새로운 기법

     

    Ajax에 관해 살펴보면 Ajax는 실지로 많은 기술들이 응집되어 있다. Ajax의 기본을 마치고 넘어가려면 몇 가지 다른 기술들(필자는 첫 번째 이 시리즈에서 각각의 기술에 관해 설명할 것이다.)을 면밀히 살펴보아야 한다. 하지만 이들 기술 가운데 어느 정도 알고 있는 것이 많은 건 다행이다. 더군다나 각각의 기술 대부분은 Java/Ruby같은 프로그래밍 언어만큼 어려운 게 아니라서 배우기 쉽다.

    Ajax 애플리케이션에 포함된 기본기술은 다음과 같다.

  • 웹 양식을 구축하고 애플리케이션 완료 때까지 사용되는 필드를 식별하는 데 HTML을 사용한다.
  • 자바 스크립트 코드는 Ajax 애플리케이션을 실행하는 중심 코드며 서버 애플리케이션과의 커뮤니케이션을 용이하게 한다.
  • DHTML(동적 HTML)은 웹 양식을 동적으로 업데이트 한다. div, span및 기타 동적 HTML 요소를 사용해 HTML을 마크업 한다.
  • 서버에서 복귀된 HTML 및 (때로) XML 구조를 다루는 데 있어 DOM, 즉 문서 객체 모델(Document Object Model)을 사용한다.

    이 기술들에 대해 간략히 요약하고 각 기술의 기능에 대해 좀 더 알아보기로 하는데 각 기술에 관한 자세한 사항은 차후 글에서 다룰 것이다. 우선은 Ajax의 구성요소 및 기술에 대해 친숙해 지는 데 초점을 맞추기로 한다. 자바 스크립트에 익숙할수록 Ajax에 담긴 기술에 관한 일반적인 지식 단계에서 각 기술에 관한 자세한 지식으로 넘어가는 게 더 쉬워진다.(또한 이로 인해 웹 애플리케이션 개발에 관한 문이 열리게 된다.)

     

    Ajax 정의
    Ajax는 비동기 JavaScript 및 XML의 약어이다.(DHTML도 마찬가지다.) Adaptive Path사의 Jesse James Garrett이 이 약어를 만들어냈으며(참고자료 참조), Jesse에 따르면 이 약어는 두문자어는 아니라고 한다.

     

     

     

    XMLHttpRequest 객체

     

    알고자 하는 객체 중 첫 번째는 아마도 가장 생소한 것이 아닌가 싶다. 그 객체는 일명 XMLHttpRequest인데 자바 스크립트 객체의 일종이며 Listing 1에 나와 있는 것처럼 단순하게 생성된다

     

    Listing 1. 새로운 XMLHttpRequest 객체 생성


    <script language="javascript" type="text/javascript">
    var xmlHttp = new XMLHttpRequest();
    </script>

     

    필자는 다음 글에서 이 객체에 대해 더 논의할 것이다. 하지만 지금 상태에서는 모든 서버 커뮤니케이션을 다루는 객체라는 사실만 알아둔다. 다음 사항으로 가기 전에 잠깐 생각해 보면 자바 스크립트 객체는 XMLHttpRequest를 통해 서버에 전달하는 자바 스크립트 기술의 일종이다. 이 객체는 애플리케이션 흐름이 정상적이지 않으며 Ajax 기술의 많은 부분을 차지하고 있다.

    정상적인 웹 애플리케이션에서 사용자는 양식 필드를 기입하며 제출 버튼을 클릭한다. 그러면 전 양식을 서버에 보내며 서버는 처리과정을 통해 양식을 스크립트(일반적으로 PHP, 자바 또는 CGI 과정/이와 유사한 과정)에 전송한다. 스크립트를 실행할 때 스트립트를 통해 완전히 새로운 페이지가 전송된다. 그 페이지는 데이터가 작성된 새로운 양식의 HTML/확인 페이지 또는 원 양식에 기입된 데이터에 근거해 선택된 옵션이 포함된 페이지일 수 있다. 물론, 서버 상의 스크립트/프로그램이 처리되면서 새로운 양식을 다시 보내는 동안 사용자는 대기해야 한다. 서버로부터 데이터를 다시 받을 때까지는 스크린 상에 아무 것도 없게 되며 결국 대화성은 낮게 된다. 사용자는 즉각적으로 응답을 받지 못하며 데스크톱 애플리케이션 상에서 작업하는 기분이 들지 않게 된다.

    Ajax는 근본적으로 자바 스크립트 기술 및 웹 양식 및 서버 간의 XMLHttpRequest 객체를 결합한다. 사용자가 웹 양식을 기입할 때 데이터는 직접 서버 스크립트에 전송되지 않고 자바 스크립트 코드에 전달된다. 대신 자바 스크립트 코드는 양식 데이터를 포착해 Request를 서버에 전송한다. 이 과정이 일어나는 동안, 사용자 스크린 상의 양식은 순식간에 나타나거나 깜빡이거나 사라지거나 정지하지 않는다. 즉 자바 스크립트 코드는 몰래 Request를 전송하며 사용자는 Request가 만들어졌는지도 알지 못한다. 게다가 Request를 비동기적으로 전송하기 때문에 더 좋은 상황이 된다. 이는 자바 스크립트에서 서버 응답을 그냥 대기하지 않는다는 것을 의미한다. 따라서, 사용자는 데이터를 계속 기입하고 화면이동하고 애플리케이션을 사용한다.

    그런 다음 서버는 자바 스크립트 코드(웹 양식에 대해 아직도 대기 중임)에 데이터를 다시 전송한다. 자바 스크립트 코드에서는 데이터와의 상호기능을 결정하며 연속적으로 양식 필드를 업데이트 하면서 애플리케이션에 즉각적인 응답을 준다. 결국 사용자는 양식을 제출/재생하는 작업 없이 새로운 데이터를 얻게 된다. 자바 스크립트 코드는 데이터를 얻고 계산도 수행하며 또 다른 Request를 전송하며 이런 모든 과정은 사용자 개입 없이도 된다! 이것이 바로 XMLHttpRequest 객체의 장점이다. XMLHttpRequest 객체는 서버와 같이 커뮤니케이션을 주고받고 사용자는 그 과정에서 벌어지는 과정을 알지 못한다. 이로 인해 데스크톱 애플리케이션과 마찬가지로 동적, 상호 반응적인 고도의 양방향 경험을 얻게 되지만 그 속에 인터넷의 모든 장점이 담겨 있다.

     

     

    자바 스크립트에 대한 부가사항

     

    일단 XMLHttpRequest에 대해 다루게 되면 나머지 자바 스크립트 코드는 상당히 평범한 것들이다. 사실 다음과 같은 기본적인 작업에 자바 스크립트 코드를 이용한다.

  • 양식 데이터 얻기: 자바 스크립트 코드로 HTML 양식에서 데이터를 꺼내 이를 서버에 전송하는 작업이 간단해진다.
  • 양식 상의 값 변환: 필드 값 설정에서 연속적인 이미지 교체작업에 이르는 양식 업데이트 작업 또한 간단하다.
  • HTML 및 XML 구문분석: 자바 스크립트 코드를 이용해 DOM(다음 섹션 참조)을 처리하고 서버에서 다시 전송하는 HTML 양식 및 임의의 XML 데이터에 관한 구조를 다루게 된다.

    첫 번째 두 항목에 대해서 여러분은 Listing 2에 나온 대로 getElementById()에 익숙해지려 할 것이다.

     

    Listing 2. 자바 스크립트 코드에서의 필드 값 포착 및 설정

    // Get the value of the "phone" field and stuff it in a variable called phone
    var phone = document.getElementById("phone").value;

    // Set some values on a form using an array called response
    document.getElementById("order").value = response[0];
    document.getElementById("address").value = response[1];

     

    Ajax 애플리케이션에서 특별히 획기적인 사항은 없고 상기 사항 정도면 충분하다. 이에 대해 상당히 복잡한 건 없다는 사실을 깨달아야 한다. 일단 XMLHttpRequest만 정복하면 Ajax 애플리케이션에서 나머지는 대부분 Listing 2에 나온 바와 같이 상당히 독창적인 HTML과 결합된 단순 자바 스크립트 코드다. 그런 다음 가끔 약간의 DOM 작업이 발생하게 된다. 이에 관해 살펴 보자.

     

     

    DOM으로 종료하기

     

    DOM, 즉 문서 객체 모델이라는 것이 있는데 이는 아주 중요하다. DOM에 대해 듣는 것은 그다지 어렵지 않다고 하는 사람들이 있다. HTML 디자이너에 의해서는 종종 사용되지 않으며 하이-엔드 프로그래밍 작업으로 들어가지 않는 한은 JavaScript 코더에서 흔치 않은 것이 바로 DOM이다. 종종 과중-업무 Java 및 C/C++ 프로그램 상에서 DOM을 종종 많이 활용하게 된다. 사실은 DOM이 배우기 어려운 특성 때문에 명성이 자자해 그 프로그램 상에서 종종 사용하는 것이 아닌가 싶다.

    다행히도 JavaScript 기술에 있어 DOM을 활용하는 일은 쉽고 대부분 직관적이다. 이 시점에서 필자는 DOM 사용법에 관해 보여 주고 적어도 이에 대한 몇 가지 코드 예를 제시하려 하지만 이 글의 의도와는 벗어나는 것 같다. DOM에 관해 대략적으로 다루는 것 없이도 Ajax에 대해 깊이 다룰 수 있다. 필자는 차후의 글에서 다시 DOM에 관해 다루려 한다. 하지만 지금 상황에서는 언급하지 않으려 한다. JavaScript 코드와 서버 사이에 XML을 이리저리 전송하고 HTML 양식을 변화시킬 때 DOM에 대해 자세히 다루게 될 것이다. 지금은 DOM없이 효과적인 Ajax 애플리케이션을 작동하는 게 쉬우므로DOM은 논외로 한다.

     

     

    Request 객체 얻기

     

    Ajax 애플리케이션에 관한 기본적 개념에 대해 배웠으면 몇 가지 특수사항에 대해 살펴 보자. XMLHttpRequest 객체는 Ajax 애플리케이션에서 중요하므로, 아마도 많은 이들에게는 생소한 것일 수도 있다. 거기서 필자는 논의를 시작한다. Listing 1에서 보다시피, XMLHttpRequest 객체를 생성, 사용하는 것은 상당히 쉬워야 한다. 잠깐만 기다려 보시라.

    수년 동안 브라우저에 관한 논란은 끊이지 않았고 동일한 브라우저로는 아무 것도 얻을 수 없다는 사실을 기억하는가? 믿건 말건, 소규모 브라우저에서도 이와 같은 논쟁은 끊이지 않고 있다. 더군다나 놀라운 사실은 XMLHttpRequest가 이 논란의 희생양 중 하나라는 것이다. 따라서 XMLHttpRequest 객체를 작동시키기 위해선 몇 가지 다른 작업을 해야 한다. 단계별로 설명하겠다.

     

     

    Microsoft 브라우저 다루기

     

    Microsoft 브라우저, Internet Explorer는 XML을 다룰 시 MSXML 구문분석계를 사용한다.(참고자료 참조) Internet Explorer 상에서 다뤄야 할 Ajax 애플리케이션을 작성할 시 독특한 방식으로 XMLHttpRequest 객체를 작성해야 한다.

    하지만 그렇게 간단한 작업은 아니다. Internet Explorer에 설치된 JavaScript 기술 버전에 따라 MSXML 버전도 변하게 되며 실지로 2개의 버전이 있다. 따라서 두 경우를 다루는 코드를 작성해야 한다. Microsoft 브라우저 상에서 XMLHttpRequest 객체를 생성하는 데 필요한 코드에 관해선 Listing 3을 보라.

     

    Listing 3. Microsoft 브라우저 상에서 XMLHttpRequest 객체 생성

    var xmlHttp = false;
    try {
    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e2) {
    xmlHttp = false;
    }
    }

     

    모든 작업이 정확히 맞아떨어지는 것은 아니다. 하지만 그래도 상관없다. 이 시리즈가 끝나기 전에 JavaScript 프로그래밍, 에러 취급 및 조건부 번역 및 기타 사항에 관해 자세히 다루게 될 것이다. 지금 현 상태에서는 두 가지 중심 라인만 다루고자 한다.

     

    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    and
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");.

     

    간단히 말해서, 이 코드로 MSXML의 한 버전을 이용해 XMLHttpRequest 객체 생성을 기한다. 하지만 객체가 생성되지 않는 경우 다른 버전을 사용해 XMLHttpRequest 객체를 생성한다. 두 코드 다 작동되지 않는 경우 xmlHttp 변수는 거짓으로 설정되고 작동되지 않는 것이 있다는 것을 코드에 알려 준다. 그럴 경우, 비-Microsoft 브라우저가 있을 가능성이 있다. 따라서 객체 생성을 위해선 다른 코드를 사용해야 한다.

     

     

    Mozilla 및 Microsoft 브라우저 다루기

     

    인터넷 브라우저를 선택하지 않거나 비-Microsoft 브라우저를 작성할 경우 다른 코드가 필요하다. 사실, 이 라인은 Listing 1에서 봤던 단순 코드라인이다.

     

    var xmlHttp = new XMLHttpRequest object;.

     

    이 단순한 라인으로 Mozilla, Firefox, Safari, Opera 및 임의의 양식/형태에서 Ajax애플리케이션을 지원하는 기타 비-Microsoft 브라우저에서 XMLHttpRequest 객체를 생성한다.

     

     

    지원기능 통합

     

    여기서 모든 브라우저를 지원하는 것이 중요하다. Internet Explorer/비-Microsoft 브라우저에서만 작동되는 애플리케이션을 작성하는 사람이 어디 있겠는가? 또한 더 심한 경우, 애플리케이션을 두 번 작성하고자 하는가? 물론 아니라고 믿는다. 따라서 코드에선 Internet Explorer 및 비-Microsoft 브라우저를 지원하는 기능이 포함되어야 한다. Listing 4에서는 다중-브라우저 방식으로 작동하는 코드에 대해 나와 있다.

     

    Listing 4. 다중 브라우저 방식으로 XMLHttpRequest 객체 생성하기

    /* Create a new XMLHttpRequest object to talk to the Web server */
    var xmlHttp = false;
    /*@cc_on @*/
    /*@if (@_jscript_version >= 5)
    try {
    xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
    xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e2) {
    xmlHttp = false;
    }
    }
    @end @*/

    if (!xmlHttp && typeof XMLHttpRequest != 'undefined') {
    xmlHttp = new XMLHttpRequest();
    }

     

    지금 현재로선, 주석 및 @cc_on와 같은 어려운 태그를 무시한다. 이들은 다음 글에서 깊이 다룰 JavaScript 컴파일러 명령으로 오로지 XMLHttpRequest 객체 상에만 초점이 맞추어져 있다. 이 코드에 관한 핵심은 세 가지 과정으로 요약된다.

    1. 변수 xmlHttp를 생성해 앞으로 생성할 XMLHttpRequest 객체를 참조한다.
    2. Microsoft 브라우저에서의 객체를 시도, 생성한다.

    • Msxml2.XMLHTTP 객체를 사용해 XMLHttpRequest 객체를 시도, 생성한다.
    • 과정이 실패할 경우, Microsoft.XMLHTTP 객체를 사용해 XMLHttpRequest 객체를 시도, 생성한다.

    3. xmlHttp가 아직도 설정되지 않은 경우 비-Microsoft 방식으로 XMLHttpRequest 객체를 생성한다.

    위 과정 끝 단계 시 사용자가 실행하는 브라우저 종류에 관계없이 xmlHttp의 경우 유효한 XMLHttpRequest 객체를 인용한다.

     

     

    보안

     

    보안이란 무엇인가? 오늘날 브라우저는 사용자들에게 보안 레벨을 올리고 JavaScript 기술을 생성하며 브라우저 옵션을 해제하는 기능을 제공한다. 이 경우 코드가 작동되지 않는 경우도 있을 수 있다. 그 때 발생하는 문제를 적절하게 다뤄야 한다. 이에 관한 내용은 적어도 기사 한 분량을 차지할 정도라 나중에 다루기로 하겠다.(긴 시리즈가 될 것 같다, 그렇지 않은가? 하지만 걱정 마시라. 과정을 다 배우고 나면 이와 관련된 모든 사항을 숙달할 테니까.) 현재로선 강력하지만 완전하지 않은 코드를 작성하는 중이다. 이 코드는 Ajax 애플리케이션을 관리하는 데 좋다.

     

     

    Ajax 세계에서의 Request/Response

     

    인제 Ajax 애플리케이션에 대해 이해하고 XMLHttpRequest 객체 및 객체 생성에 관한 기본적인 개념을 얻는다. 자세히 읽다 보면 Ajax 애플리케이션은 웹 애플리케이션에 제출되는 HTML 양식보단 서버 상의 임의의 웹 애플리케이션에 대화하는 JavaScript 기술이라는 사실을 알게 된다.

    그러면 빠진 부분은 어떤 것인가? 실질적인 XMLHttpRequest 객체 사용법이다. 이 객체는 작성하는 각각의 Ajax 애플리케이션에서 일정 형태로 사용하는 중요 코드라 Ajax 애플리케이션이 포함된 기본 Request/응답 모델 모양을 통해 객체 사용법을 빨리 익힌다.

     

     

    Request 만들기

     

    새로운 XMLHttpRequest 객체가 있는 경우 이를 시험해 보자. 먼저 웹 페이지에서 호출하는 JavaScript 방법이 필요하다.(사용자가 텍스트에서 입력하거나 메뉴에서 옵션을 선택할 시와 같음.) 그 다음, 거의 모든 Ajax 애플리케이션에서의 동일한 기본 아웃라인을 따른다.

    1. 웹 양식으로부터 필요한 모든 데이터 얻기
    2. 연결할 URL 구축
    3. 서버 연결
    4. 서버 실행 종료 시 서버 실행 기능 설정
    5. Request 전송

    Listing 5는 위의 순서대로 5단계를 진행하는 Ajax 방법의 예에 관해 나와 있다.

     

    Listing 5. Ajax가 포함된 Request 만들기

    function callServer() {
    // Get the city and state from the web form
    var city = document.getElementById("city").value;
    var state = document.getElementById("state").value;
    // Only go on if there are values for both fields
    if ((city == null) || (city == "")) return;
    if ((state == null) || (state == "")) return;

    // Build the URL to connect to
    var url = "/scripts/getZipCode.php?city=" + escape(city) + "&state=" + escape(state);

    // Open a connection to the server
    xmlHttp.open("GET", url, true);

    // Setup a function for the server to run when it's done
    xmlHttp.onreadystatechange = updatePage;

    // Send the request
    xmlHttp.send(null);
    }

     

    Ajax 코드에 관한 많은 것이 명백하다. Ajax 코드의 첫번째 비트는 몇 가지 양식 필드 값을 포착하는 기본 JavaScript 코드를 사용한다. 그런 다음 이 코드에서는 연결 최종 목적지로 PHP 스크립트를 설정한다.

    PHP 스크립트의 URL을 지정한 다음(양식에서 나온) 단순한 GET 매개변수를 이용해 이 URL에 도시 및 국가를 추가한다. 그 다음 연결하면 먼저 XMLHttpRequest 객체가 작동되는 것을 보게 된다. 연결방법은 연결 URL 뿐만 아니라, GET 매개변수에도 나와 있다. 최종 매개변수를 true로 설정한 경우, 이 매개변수에선 비동기식 연결(Ajax를 만든다.)을 요구한다. false로 설정한 경우엔 Request를 만들 시 서버 상에서 Ajax에서의 JavaScript 코드가 대기하고 응답을 받을 때 코드가 지속된다. 사용자는 최종 매개변수를 true로 설정하면서 서버에서 배경에 있는 Request를 처리하는 동안 사용자는 웹 양식(심지어는 기타 JavaScript 방식)을 여전히 사용한다.

    한편 xmlHttp(이것은 XMLHttpRequest 객체의 인스턴스라는 사실을 기억하라.)의 onreadystatechange 속성으로 서버 실행이 종료될 시(5분/5시간 내에 종료될 수 있음) 서버 기능을 명령한다. 이 코드는 서버 상에서 대기하지 않기 때문에 서버가 기능을 인식해 서버에 응답할 수 있도록 하는 게 필요하다. 이 경우 서버에서 Request를 처리하면서 종료 시 이른바 updatePage()라 불리는 특수 방법을 트리거한다.

    최종적으로 send() 코드를 0(null) 값으로 호출한다. 데이터를 추가해 이를 서버에 전송하므로 Request에는 추가해서 보낼 게 없다. 이렇게 되면 Request를 발송하고 서버는 서버에 요구된 기능을 실행한다.

    이 코드에서 나오는 것이 없는 경우, 코드가 상당히 간단하다는 것을 명심하라. 이 코드는 Ajax 애플리케이션의 비동기적 특성을 제외하고는 상당히 단순하다. 이 코드를 통해 복잡한 HTTP Request/응답 코드보다는 근사한 애플리케이션 및 인터페이스에 완전 초점을 맞추도록 한다는 사실을 여러분은 높게 평가할 것이다.

    Listing 5의 코드는 코드를 얻는 방법만큼이나 쉽다. 데이터는 단순 텍스트이고 Request URL의 일부로 포함된다. GET 매개변수는 더 복잡한 POST대신 Request를 전송한다. 여기에 덧붙일 XML/컨텐츠 헤더가 없고 Request 본체에 전송할 데이터도 없다. 이게 바로 Ajax 유토피아다.

    그렇다고 미리 겁먹지 마라. 시리즈가 계속될수록 문제는 더 복잡해진다. 그 때는 POST Request를 전송하는 방법, Request 헤더 및 컨텐츠 형식을 설정하는 방법, 메시지에 XML을 설정하는 방법 및 Request에 보안기능을 추가하는 방법을 배우게 되는데 배우는 목록만 해도 상당히 길다! 지금은 이런 어려운 주제에 대해 신경 쓰지 말자! 그냥 기본만 충실하게 익히면 Ajax 전체 툴을 구축하게 된다

     

     

    응답 취급과정

     

    이제 서버 응답을 실지로 취급해야 한다. 이 시점에서는 정말로 두 가지 사항만 알면 된다.

  • xmlHttp.readyState 속성이 4와 같을 때까지는 어떤 작업도 해선 안 된다.
  • 서버는 xmlHttp.responseText 속성에 응답한다.

    2가지 항목 중 첫번째 항목인 준비 상태에 관해선 다음 글에서 대부분 다룰 것이다. 그 때는 HTTP Request 단계에 대해 알고 싶은 것 이상으로 배우게 된다. 지금 현재로선, xmlHttp.responseText 속성 값 4를 단순 점검하는 경우, 작업이 계속 진행된다.(다음 글에서 기대할 만한 사항이 나오게 된다.) 서버 응답을 얻기 위해 xmlHttp.readyState 속성을 사용하는 과정인 두 번째 항목은 쉽다. Listing 6은 Listing 5에서 전송된 값에 근거해 서버에서 호출하는 방법에 관한 예를 보여준다.

     

    Listing 6. 서버 응답 취급하기

    function updatePage() {
    if (xmlHttp.readyState == 4) {
    var response = xmlHttp.responseText;
    document.getElementById("zipCode").value = response;
    }
    }

     

    다시 보면, xmlHttp.readyState 코드는 그리 어렵거나 복잡하지 않다. 이 코드는 서버에서 해당 준비 상태로의 호출을 대기하고 서버에서 다시 복귀되는 값(이 경우, 사용자 기입 도시 및 국가에 대한 ZIP 코드)을 사용해 또 다른 형태의 양식 필드를 설정한다. 그 결과, zipCode 필드는 ZIP 코드와 함께 갑자기 나타난다. 하지만 사용자는 버튼을 클릭해서는 안 된다! 그게 바로 이전에 말했던 데스크톱 애플리케이션이다. Ajax 코드에는 응답성, 동적 상태 외의 더 많은 것이 있다. 독자들은 zipCode가 정상 텍스트 필드라는 것을 눈치챘을지도 모른다.

    일단 서버에서 zipCode를 복귀시키고 updatePage() 방식으로 도시/국가 ZIP 코드와 함께 zipCode 필드 값을 설정하는 경우 사용자는 값을 무효로 한다. 값을 무효로 하는 데는 두 가지 이유가 있다. 예에서 나오는 상황을 단순화시키고, 때로는 사용자가 서버에서 명령하는 것을 무효로 하기 위해서다. 이 두 가지를 명심하라. 좋은 사용자-인터페이스 설계를 위해 중요하다.

     

     

    웹 양식 다루기

     

    그러면 이 글에서 다룰 게 남아 있는가? 그다지 많지 않다. 양식에 기입할 정보를 포착해 이를 서버에 전송하고 응답에 관해 취급할 또 다른 JavaScript 방법을 제공하면서 심지어는 다시 응답될 때 필드 값을 설정하기까지 하는 JavaScript 방법을 다룬다. 여기서는 첫번째 JavaScript 방법을 호출해 전 과정을 시작하기만 하면 된다. 분명 HTTL 양식에 버튼을 추가하지만 2001년 버전과 거의 동일하다고 생각되지 않는가? Listing 7과 같이 JavaScript 기술을 활용한다.

     

    Listing 7. Ajax 프로세스 시작

    <form>
    <p>City: <input type="text" name="city" id="city" size="25"
    onChange="callServer();" /></p>
    <p>State: <input type="text" name="state" id="state" size="25"
    onChange="callServer();" /></p>
    <p>Zip Code: <input type="text" name="zipCode" id="zipCode" size="5" /></p>
    </form>

     

    이런 단면이 루틴 코드의 한 단면 이상을 보여준다고 생각된다면 맞는 말이다. ? 그렇다! 사용자가 도시/국가 필드에 관한 새로운 값을 입력할 경우 callServer() 방식을 전송한 다음 Ajax 애플리케이션이 시작된다. 이제 여러 상황을 다룰 만하다고 느껴지기 시작하는가? 좋다! 바로 그거다!

     

     

    맺음말

     

    이 시점에서 적어도 리소스 란에서 Ajax 애플리케이션에 관해 깊숙이 알려고 하는 경우, 첫번째 Ajax 애플리케이션을 작성할 준비가 되어 있지 않을 게다. 하지만 이런 애플리케이션이 작동하는 기본 개념 및 XMLHttpRequest 객체의 기본 개념을 이해하기 시작한 경우 이 객체, JavaScript-서버 간 대화 취급방식, HTML 양식 취급 및 심지어 DOM 관리 방식까지 모든 것을 배워야 한다.

    지금 현재로선, Ajax 애플리케이션이 얼마나 강력한 툴인지 생각하는 데 시간을 보낸다. 버튼만 클릭할 뿐만 아니라 필드에 입력하고 콤보 상자에서 옵션을 선택하고 심지어는 마우스를 스크린 주위에 끄는 경우 응답하는 웹 형식을 상상해 본다. 비동기식의 정확한 의미 및 Request 상에서 응답하기 위해 서버 상에서 실행하지만 대기하지 않는 JavaScript 코드에 관해 생각해 본다. 여러분이 부딪치는 문제의 종류는 어떤 것인가? 어떤 영역의 문제에 주의를 기울일 것인가? 프로그래밍에 이 새로운 접근방식을 설명하기 위해 양식 설계를 변환하는 방법은 어떤 것인가?

    이런 문제에 관해 실지로 생각할 시간을 보낸다면 잘라 붙이는 코드를 가지고 이를 잘 이해하지 못하는 애플리케이션에 포함시키는 것보다는 훨씬 더 낫다. 다음 글에서는 이와 같은 개념을 실제 작업에 응용해 본 작업에서처럼 애플리케이션을 만들어야 하는 코드에 관한 자세한 정보를 제공하기로 한다. 그 때까지 Ajax 애플리케이션의 가능성을 마음껏 즐겨라.

     

     

    참고자료

    교육
    - Adaptive Path
    - Jesse James Garrett, Ajax.
    - XMLHttpRequest object.
    - Microsoft Developer Network's XML Developer Center.
    - 자바 개발자를 위한 Ajax: 동적 자바 애플리케이션 구현 (developerWorks, September 2005)
    - 자바 개발자를 위한 Ajax: Ajax용 자바 객체 직렬화 (developerWorks, October 2005)
    - Using Ajax with PHP and Sajax (developerWorks, October 2005)
    - Call SOAP Web services with AJAX, Part 1: Build the Web services client (developerWorks, October 2005)
    - XML Matters: Beyond the DOM (developerWorks, May 2005)
    - Build apps with Asynchronous JavaScript with XML, or AJAX (developerWorks, November 2005)
    - Ajax for Java developers: Ajax with Direct Web Remoting (developerWorks, November 2005)
    - surveys AJAX/JavaScript libraries.
    - XUL Planet's object reference section details XMLHttpRequest
    - strategy white paper
    - Flickr.com.
    - GMail
    - Head Rush Ajax (O'Reilly Media, Inc., February 2006)
    - JavaScript: The Definitive Guide, 4th Edition (O'Reilly Media, Inc., November 2001)
    - developerWorks Web Architecture zone

    토론
    -포럼에 참여하기.
    -Ajax.NET Professional
    -developerWorks blogs.

     

    사용자 삽입 이미지


    Brett McLaughlin, Author and Editor | O'Reilly Media Inc.

     

     

    사용자 삽입 이미지

     

    원문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3052

      Comments,     Trackbacks
    [Ajax] Ajax 마스터하기 - 개요

    [Ajax] Ajax 마스터하기 - 개요

     

    개요

     

    개요
    PART 01/Ajax 소개
    PART 02/JavaScript와 Ajax를 이용한 비동기식 요청
    PART 03/Ajax의 고급 요청 및 응답
    PART 04/웹 응답에 DOM 활용하기
    PART 05/DOM 다루기

     

     

     

    지난 한 해 미국을 중심으로 인터넷 업계를 뜨겁게 달군 키워드 중 하나는 '웹2.0' 이었으며, Google의 Gmail과 Maps 그리고 사진공유 사이트인 Flickr 등을 통해 국내 에서도 이에 관한 관심이 매우 높아졌습니다. '웹2.0 컨퍼런스'를 기획한 ‘오라일리(O’Reilly)’사의 팀 오라일리 회장은 “웹2.0 시대로의 전환은 ‘웹의 플랫폼화(The Web as platform)’에 있다”라고 언급했으며, 여기서의 플랫폼은 MS의 Windows 와 같은 운영체제를 말합니다. 즉 지금까지는 윈도우즈를 부팅시킨 후 할 수 있었던 워드나 엑셀 작업등을 이제는 운영체제에 구애됨이 없이 웹브라우저를 통해서도 할 수 있다는 것입니다.

     

    Ajax가 주목받는 이유는 이러한 웹2.0 시대를 연 많은 사이트 들이 Ajax 기술을 활용하고 있기 때문입니다.

     

    Ajax(Asynchronous Java Script and XML)는 클라이언트 측 스크립팅을 사용하는 웹 애플리케이션 개발 방식으로서 http를 통해 xml 데이터를 웹 서버와 교환합니다. 따라서 웹 페이지는 동적으로 업데이트 될 수 있습니다. 전체 페이지를 리프레시 하여 응답성이 떨어지게 하지도 않습니다. Ajax를 사용하여 보다 풍부하고 동적인 웹 애플리케이션 사용자 인터페이스를 만들 수 있습니다. Ajax는 기술이 아니며, 오히려 여러가지 기술이 복합된 방법론 또는 패턴에 더 가깝습니다.

    본 특집은 Ajax에서 사용되고 있는 XMLHttpRequest를 이용한 비동기 자료검색, DOM을 이용한 상호작용, 모든 것을 결합시켜 정리해 주는 자바스크립트 등에 관하여 자세하게 예를 들어 설명하고 있습니다.

    이 시리즈는 모두 5회로 나누어 설명합니다.

     

     

    Part 1: Ajax 소개

     

    Ajax 애플리케이션에 관한 서론 및 이 애플리케이션에 필요한 몇 가지 기본개념들을 설명합니다.

     

     

    Part 2: JavaScript와 Ajax를 이용한 비동기식 요청

     

    XMLHttpRequest 객체에 대해 구체적으로 소개합니다. 이 객체는 서버측 애플리케이션이나 스크립트에 대한 요청을 핸들하고, 서버측 컴포넌트에서 리턴 데이터를 처리하는 Ajax 애플리케이션의 핵심 입니다. 모든 Ajax 애플리케이션은 XMLHttpRequest 객체를 사용하기 때문에 Ajax 애플리케이션의 작동은 여기에 얼마나 익숙해지냐에 달려있습니다.

     

     

    Part 3: Ajax의 고급 요청 및 응답

     

    지난 글에서 다루었던 기초를 넘어서 요청 객체의 세 가지 핵심 부분들-HTTP 준비 상태,HTTP 상태 코드, 요청 유형들-에 대해 자세히 설명합니다. 애플리케이션에 무언가 문제가 있을 때 준비 상태, HEAD 요청을 하는 방법, 또는 400 상태 코드가 의미하는 것이 무엇인지를 이해하면 간단한 디버깅으로 끝낼 수 있기 때문입니다.

     

     

    Part 4: 웹 응답에 DOM 활용하기

     

    웹 페이지를 정의하는 문서 객체 모델(Document Object Model)을 소개합니다.

     

     

    Part 5 : DOM 다루기

     

    이번 글에서는 돔을 보다 자세히 연구합니다. 웹 페이지에 대한 특정 모델은 그 페이지의DOM 트리라고 하는데, 이러한 돔 트리의 부분들을 생성, 제거, 변경하는 방법을 설명하고 그 다음 단계인 웹 페이지를 업데이트 하는 방법을 설명합니다. 여러분은 DOM을 통해서 사용자 인터페이스를 변경할 수 있고 인터랙팅 할 수 있습니다. 이것은 실로 엄청난 프로그래밍의 힘과 유연성을 제공해 주는데, 일단 DOM 트리로 작업하는 방법을 배우면 풍부하고 동적인 인터랙티브 웹 사이트를 마스터하는 단계로 넘어갈 수 있다.

    이상에서 Ajax 애플리케이션에 필요한 기본개념들에 대해 살펴보았습니다. Ajax라는 용어는 새롭지만, 이를 구현하는 기술요소들은 전혀 새로운 것이 아닙니다. 하지만 이를 이용할 경우 사용자는 원하는 응답을 빠른 시간에 받을 수 있고 이에따라 서버의 부담이 줄어들며, 개발자는 페이지 화면구성을 다이나믹하게 할 수 있고, 플래시나 액티브엑스(ActiveX) 의존도를 상당부분 대체 할 수 있다는 장점이 있습니다. 이 시리즈 이외에도 한국 developerWorks 사이트에 Ajax 에 관련된 글들이 많이 번역되어 게시되고 있으며, developerWorks 사이트에는 최신 기술자료들이 올라와 있으니 즐겨찾아 주시기 바랍니다.

    여러분에게 많은 도움이 되기를 바랍니다.
    감사합니다.

     

     

    작성자 : 이선민, Technical Consultant, IBM Innovation Center (IIC), IBM Korea

     

    사용자 삽입 이미지

     

    원   문 :http://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=14&divcateno_=14&pg=1&idx=3051

      Comments,     Trackbacks
    스마트한 웹2.0 사이트 26선

    스마트한 웹2.0 사이트 26선

     

    웹2.0의 분위기와 함께 주목할만한 스마트한 웹사이트 26개 정도를 정리해보았다. 이들 사이트를 통해 보다 편리하고 유용한 인터넷 서비스 사용을 할 수 있기를...

     

     

    사용자 삽입 이미지

     

     

    1. 끄적거린 메모도 일상의 정보이다.


    포스트잇을 대처하는 PC용 메모 관리툴로는 컴퓨터에 설치해서 사용하는 포스트잇 유티리티가 있었다. 이 유틸리티를 이용하면 실제 포스트잇처럼 다양한 색상의 메모지를 바탕화면 어디든 가져다 붙일 수 있다. 또한 이 같은 프로그램은 알림 기능도 제공되어 간단한 약속을 기록하고 시간이 가까워지면 이를 알려주기도 한다. 하지만, 이 같은 포스트잇은 2대 이상의 PC에서는 사용하기가 불편하다. 포스트잇을 설치하지 않은 다른 PC에서는 메모 내용을 확인하지 못하고 한 곳에 기록된 포스트잇 내용은 쉽게 다른 PC와 공유하기 어렵기 때문이다.

     

    이 같은 불편함을 해소해주는 WWW 메모지가 각광을 받고 있다. 프로토페이지라는 사이트는 웹브라우저 내에 여러 개의 메모지를 자유자재로 배치하여 브라우저를 포스트잇으로 구성할 수 있도록 해준다. 마치 바탕화면에 여러 개의 포스트잇을 부착하는 것처럼 브라우저 내에 메모지를 부착할 수 있다. 게다가 프로토페이지는 메모지 외에도 날씨, RSS 뉴스, 전자우편, 북마크 등의 다양한 위젯을 추가할 수 있도록 해준다. 


     ☞메모 기록과 RSS 뉴스와 메일을 관리해주는 프로토페이지:
    http://protopage.com

     

     

    또한, 웹노트는 다른 사용자와 메모 내용을 함께 공유하며 내용을 업데이트할 수 있는 협업 기능을 제공한다. 단, 웹노트는 별도의 로그인 기능이 제공되지 않으며 생성된 페이지는 암호 등으로 보호되지 않으므로 누구나에게 공개될 수 있다. 이렇게 만들어진 메모 페이지는 쉬운 URL로 구성되므로 다른 사용자에게 이 URL만 알려주면 바로 쉽게 메모 내용을 공유할 수 있다.


     ☞메모를 공유하고 협업으로 기록할 수 있는 웹노트:
    http://www.aypwip.org/webnote

     

     

     

    2.  동영상 시대를 위한 동영상 공유 서비스


    2005년부터 국내 포탈에서는 UCC 열풍이 불어닥치고 있다. UCC란 User Created Contents라는 뜻으로 사용자가 직접 만든 콘텐츠를 말한다. 기존 언론이나 미디어에서 만드는 콘텐츠보다 더 방대하고 다양한 주제를 가진 UCC는 포탈의 볼거리를 풍성하게 해주고 있다. 특히 디카의 보급이 급속히 진행되면서 2004~2005년에는 사진이 UCC의 주요한 포맷이 되었다. 하지만, 2006년에는 동영상이 UCC의 주요 포맷으로 급부상하고 있다.


    그렇다보니 사용자가 제작한 동영상을 업로드하고 공유할 수 있는 서비스가 인기리에 소개되고 있다. Youtube는 사용자가 업로드한 동영상 파일을 플래시 형태로 변환해줌으로써 빠르고 직관적인 UI의 구성이 가능하다. 물론 업로드한 동영상은 태그를 이용해 분류할 수 있으며 다른 웹사이트에서도 쉽게 가져다 사용할 수 있도록 지원해준다. 최근 국내의 포탈 사이트에서도 이러한 동영상 서비스를 지원하고 있다.


     ☞플래시로 빠르고 직관적인 동영상 공유 사이트 :
    http://www.youtube.com
     ☞RSS와 동영상 클립을 flickr에 보낼 수 있는 서비스 :http://www.vimeo.com

     

     

     

    3.  여러 메신저를 한 번에 사용하는 웹메신저


    웹통계 정보를 제공하는 코리안클릭의 자료에 따르면 한국 사용자의 경우 평균적으로 약 2개 정도 되는 인스턴트 메신저를 사용하고 있다. 나의 경우만 해도 간혹 사용하는 ICQ와 자주 사용하는 MSN 메신저, 가끔 사용하는 구글토크와 네이트온, 야후 메신저 등 4개 정도의 메신저를 사용하고 있다. 그렇다보니 이들 메신저를 한꺼번에 실행하면 시스템 리소스도 많이 사용할 뿐 아니라 정신이 없다.

     

    하지만, 통합 메신저 서비스인 meebo를 사용하면 이러한 번거로움이 해결된다. Meebo는 웹메신저이면서 5개의 메신저(AIM, ICQ, 야후메신저, 구글토크, MSN 메신저)를 지원한다. 이들 5개의 메신저를 Meebo 메신저 하나로 통합해서 사용할 수 있다. 웹메신저인만큼 시스템 리소스도 적게 차지할 뿐 아니라 가벼우며 5개의 메신저를 하나의 메신저에서 통합해서 사용할 수 있어 편리하다.

     

     ☞여러 메신저를 통합해서 관리해주는 웹메신저 :http://www.meebo.com

     

     

     

    4.  팟캐스팅을 위한 음성 녹음 사이트


    팟캐스팅은 자신만의 라디오쇼를 제작하는 1인 미디어 서비스이다. 국내에서는 널리 사용되고 있지 않지만 미국, 유럽에서는 아이팟을 이용해서 팟캐스팅을 청취하는 사용자가 늘어가고 있다. 팟캐스팅은 일종의 오디오 블로그로써 글 대신에 음성과 음악 등으로 블로깅을 하는 것을 일컫는다. 이렇게 팟캐스팅이 인기이다보니 음성을 녹음해서 저장하고 이것을 RSS로 피딩하고 전자우편으로 발송하거나 다른 사용자와 공유할 수 있는 서비스가 등장하고 있다.

     

    Slawesome은 플래시로 구현된 녹음툴을 이용해서 음성을 녹음하고 이렇게 녹음된 데이터를 RSS로 피딩하고 쉽게 다른 곳(블로그나 기타 게시판)에 쉽게 붙일 수 있도록 해준다다. 이곳에서 녹음한 데이터는 저장해두고 필요로 하는 다른 인터넷 사이트에서 불러다 사용할 수 있는 것이다. 또한 전자우편으로 녹음된 소리를 전송할 수도 있다.

     ☞플래시로 구현된 음성 녹음기와 공유 서비스 :http://www.slawesome.com

     

     

     

    5.  함께 공동으로 문서를 작성하기 위한 협업 서비스


    우리가 컴퓨터로 생산적인 일을 할 때는 대개 문서를 작성할 때이다. 특히 회사원인 경우에는 컴퓨터를 이용해서 각종 보고서와 제안서를 작성한다. 우리는 이렇게 문서를 작성할 때 MS워드, 파워포인트, 엑셀 등의 오피스 프로그램을 이용한다. 하지만, 이 같은 어플리케이션의 가장 최대 단점은 공동으로 다른 사용자가 협업을 하며 문서를 완성하기 어렵다는 점이다. 현대 사회에서는 과거와 달리 협업, 공동작업이 보편화되어 문서도 공동으로 작업하는 경우가 비일비재하다. 하지만, 기존 어플리케이션은 이러한 공동 작업에 제한이 있다.

     

    그런 이유로 협업을 도와주는 웹서비스가 큰 관심을 받고 있다. Writely는 2006년 3월구글에 인수된 사이트로 WWW에서 공동으로 문서를 공유하고 함께 작업할 수 있도록 해준다. 특히, MS워드에서 사용하는 DOC 파일을 지원하며 공유 문서에 이미지 파일의 삽입도 가능하다. 게다가 이렇게 만들어진 문서는 PDF로 저장할 수도 있다. 버전별로 문서를 관리할 수 있어 공동으로 문서를 수정한 내역에 대해 한 눈에 확인하고 과거의 버전으로 되돌릴 수도 있어 편리하다.


     ☞공동 문서 작업에 적합한 Writely :
    http://www.writely.com
     ☞공동 문서를 쉽게 생성, 공유할 수 있는 Writeboard :http://www.writeboard.com
     ☞다양한 사람들과 함께 협업하며 문서를 완성하는 webcollaborator :http://webcollaborator.com

     

     

     

    6. 일정관리, 시간관리마저 WWW으로 옮겨온 웹캘린더


    캘린더 서비스는 이메일에 이어 개인 대상의 킬러 어플리케이션으로 자리 잡을 것이라는 전문가들의 예측이 쏟아져 나오고 있다. 시간관리를 위한 툴로서 일정관리 SW는 다이어리와 달력, 메모지를 대처하리라 생각된다. (마치 메일이 우편을 대체한 것처럼...) 하지만 기존 전자 일정 관리 SW는 단지 기존 오프라인 일정을 온라인으로 옮겨왔을 뿐, 인터넷의 장점인 공유와 커뮤니케이션, 디지털 연계 등의 특성을 제대로 활용하지 못했다.

     

    하지만, 전자 캘린더가 WWW에서 제공되기 시작하면서 캘린더의 모습이 많이 달라지고 있다. 캘린더의 내용을 다른 사용자와 공유하고, 다양한 서비스(메일, 지도, RSS 등)와 연계하여 활용되기 시작하고 있는 것이다. 구글에서 발표한 웹캘린더는 바로 이러한 특징을 가지고 있다.

     

    ① 텍스트만으로 한 번에 일정을 입력하는 Quick Add
    ② 드래그앤 드랍으로 쉽게 일정을 수정할 수 있는 손쉬운 UI
    ③ 하나 이상의 다양한 스케줄표를 추가할 수 있다.
    ④ 등록된 일정을 다른 사용자와 쉽게 공유하고 일정에 코멘트를 추가할 수 있다.
    ⑤ RSS를 지원해 일정을 RSS 리더기 등을 통해 구독할 수 있다.


     ☞뛰어난 공유 기능을 제공하는 구글 캘린더 :
    http://calendar.google.com
     ☞다른 사용자와 커뮤니티 일정 관리를 지원하는 planzo :http://www.planzo.com
     ☞Ajax로 구현된 일정관리 :http://www.calendarhub.com

     

     

     

    7.  할 일 관리를 위한 To Do List 정리


    컴퓨터는 정확하다. 그렇기 때문에 사람처럼 깜빡 잊거나 혼란스러워하지 않는다. 그런 이유로 컴퓨터로 할 수 있는 유용한 기능 중 하나가 바로 일정과 할일을 관리하는 기능이다. 언제까지 무엇을 해야 하는지를 상기시켜주고 관리해주는 TO DO List는 아웃룩이나 각종 개인 정보 관리기(PDA 또는 PIMS 유틸리티)에서 빠지지 않고 등장하는 기능이다.

     

    Remember the milk 사이트는 할일을 목록별로 리스트업하여 관리해주는 서비스를 제공한다. 언제까지 무엇을 해야 하고 중요도는 얼마나 되는지 그리고 할 일에 간단한 메모를 기록해 넣을 수 있도록 해준다. 특히 할 일의 마감 시간이 가까워오면 메신저로 할 일에 대한 내용을 보내주기도 하고, 다른 사용자와 공유할 수도 있다.
     ☞할 일을 다른 사용자와 공유하고 메신저로 보내주는 사이트 :

    http://www.rememberthemilk.com

     

     

     

    8.  PC를 디지털 멀티미디어 허브, 서버로 탈바꿈하자.


    컴퓨터가 업무와 생활의 중심이 되면서 컴퓨터에는 방대한 데이터가 쌓여가고 있다. 각종 오피스 문서는 물론 이거니와 음악, 동영상, 사진 등의 멀티미디어 데이터가 쌓인다. 이러한 멀티미디어 데이터는 디카와 캠코더로 생산되며 디지털 음악도 MP3 파일로 구매하면서 점점 더 많은 파일이 컴퓨터에 쌓여가고 있는 것이다. 아무리 WWW에서 사진과 동영상, 오디오를 저장해주는 공간을 제공하고 이를 공유해주는 서비스를 제공한다고 하지만 이것은 한계가 있다. 돈을 벌려는 WWW 사이트가 개인에게 무제한으로 그러한 공간을 제공할리는 없기 때문이다.

     

    ORB는 PC에 저장된 동영상, 이미지, 오디오 등을 인터넷을 이용해서 스트리밍으로 공유하고 재생할 수 있는 서비스를 제공한다. 굳이 WWW에 파일을 업로드하지 않아도 내 PC를 서버로 만들어 PC에 저장된 파일을 인터넷의 다른 사용자들이 공유하고 확인할 수 있는 서비스를 제공하는 것이다. 이 서비스를 사용하기 위해서는 ORB 프로그램을 PC에 설치하고 ORB에 가입하면 된다. 물론 서비스 사용은 무료이며, PC에 ORM를 실행해두면 인터넷을 이용해 어디서든 ORB가 설치된 PC에 연결해서 각종 멀티미디어 파일을 재생해서 볼 수 있다.

     ☞PC에 저장된 멀티미디어 파일을 스트리밍으로 재생해주는 ORB :http://www.orb.com

     

     

     

    9. 개인화 포탈에서 모든 것을 해결한다.


    우리는 뉴스를 보고 검색을 하기 위해 포탈에 들른다. 또한, 전자우편을 확인하기 위해 웹메일 사이트를 들르고, 블로그에 게재된 글을 보기 위해 각각의 블로그 사이트를 방문한다. 하지만, 개인화 포탈을 이용하면 여러 개의 웹사이트에서 제공되는 서비스를 하나의 페이지에서 해결할 수 있다. 내가 보고 싶은 것을 한 곳에서 볼 수 있는 철저히 나만을 위한 포탈 서비스를 만들 수 있는 개인화 포탈이 각광을 받고 있다.

     

    넷바이브는 각종 RSS 기사와 검색, 노트, 플리커의 이미지, 날씨 등의 인터넷 서비스를 하나의 페이지에 설정해서 볼 수 있는 개인화 서비스를 제공한다. 넷바이브를 이용하면 단지 뉴스 정보만을 배치하는 것이 아니라 Web 2.0 기반의 플리커, Writely, 딜리셔스 등의 다양한 웹서비스를 사용할 수 있다. 내가 보고 싶은 콘텐츠와 자주 사용하는 웹서비스를 한 곳에서 사용할 수 있는 것이다.


     ☞개인화 포탈 서비스 넷바이브 :
    http://www.netvibes.com

     

     

     

    10. 사진에 자동으로 태깅을 기록해준다.


    디카로 촬영된 사진에는 추억이 기록되어 있다. 예를 들어, 사진 한 장에는 언제, 어디서, 누구에 대한 정보가 기록되어 있다. 하지만, 우리는 촬영된 사진에 대해 일일히 이러한 정보를 기록하는 것에 번거로워하고 귀찮아 한다. 촬영한 사진 파일을 PC에 저장해서 각 사진의 파일 이름을 변경하는 것조차 버거운데 어떻게 각 파일에 대한 정보까지 일일히 기록하겠는가.

     

    하지만, Riya의 서비스는 이러한 것을 자동으로 기록할 수 있도록 해준다. Riya는 자동으로 사진 속에 포함된 얼굴과 건물을 인식해서 이것을 기반으로 사진을 분류해준다. 또한 사진 파일의 메타정보를 활용해서 촬영한 시간과 디카 정보를 기반으로 자동 태깅을 입력해준다. 이를 기반으로 보다 쉽게 사진을 분류할 수 있도록 도와준다.


     ☞사진을 자동으로 태깅을 해주는 Riya  :
    http://www.riya.com
     ☞한국의 자동 얼굴 인식 사진 관리기 :http://www.olalog.com

     

     

    11.  기타 사이트


    그룹끼리 공동의 프로젝트를 관리하고 협업을 위한 툴로 MS의 TeamX나 네이버의 플랜후드를 WWW에서 구현한 서비스이다. 특히 Wiki-Style을 적용해서 상당히 서비스가 유연하고 여러 사용자가 공동으로 관리하기에 편리하다.


     ☞
    http://www.centraldesktop.com/tour_overview

     


    나를 중심으로 회사, 친구, 각종 동호회, 단체의 복잡한 스케줄 관리를 편안하게 할 수 있도록 해주는 일정 관리 툴이다. 기존 툴과는 달리 다른 사람들과 일정을 쉽게 공유하도록 했다. 아웃룩의 일정관리를 WWW(Ajax 기반)으로 구현하고 그것을 다른 사용자와 쉽게 공유할 수 있는 서비스이다.


     ☞
    http://www.airset.com

     


    Wiki 시스템을 기반으로 구성된 노트이다. 여러 사용자들이 하나의 노트(WWW Page)를 공동의 작업창으로 활용한 서비스로 기존의 Application으로 수행하기에 한계가 있던 공유, 협업의 문서 작성을 보다 쉽게 해준다.


     ☞
    http://jotlive.com/about/screenshots

     


    북마크 정보를 공유하는 사이트로서 구글과 같이 간편한 UI가 특징이다. 유용한 정보를 담은 인터넷 페이지를 간단한 코멘트 그리고 태그와 함께 저장해둘 수 있다. 이렇게 저장된 페이지 정보는 다른 사용자들과 공유할 수 있도록 해준다. 특정한 태그에 대해 북마킹된 페이지들 정보를 확인할 수 있어 특정 주제에 대한 인터넷 상의 웹페이지들을 쉽게 검색할 수 있도록 해준다.


     ☞
    http://Del.icio.us

     


    Flickr는 대표적인 Web2.0 사이트로서 사진을 효과적으로 관리하는 서비스를 제공한다. Flickr에 저장한 사진은 다른 웹사이트에서 쉽게 가져다 쓸 수 있도록 해준다. 또한, 사진에 태그를 붙이고 태그를 이용해서 사진을 쉽게 분류하고 관리할 수 있도록 해준다. 딜리셔스와 마찬가지로 태그를 기반으로 해서 사용자들이 등록한 사진을 쉽게 공유하고 검색할 수 있다.

     

     ☞http://www.flickr.com

     


    자바를 기반으로 구축한 웹 오피스 프로그램으로 무료로 엑셀, 파워포인트, 워드 등의 문서를 편집하고 생성할 수 있는 기능을 제공한다. WWW에서 구현된 서비스이기 때문에 별도의 프로그램을 설치하지 않아도 되며 인터넷 사용이 가능한 곳에서는 어디든 사용이 가능하다. 특히, 다른 사용자와 문서를 공동으로 편집하고 웹브라우저 내에 오피스 문서를 삽입하고 쉽게 볼 수 있도록 해준다.


     ☞
    http://www.thinkfree.com

     


    블로그에 기록하는 코멘트를 한 곳에서 쉽게 관리할 수 있도록 해준다. 수 많은 블로그에 기록한 코멘트를 한 곳에서 확인할 수 있어 내가 기록한 코멘트에 대한 블로그의 포스팅 기사 목록을 관리하기 용이하다.


     ☞
    http://www.cocomment.com

     


    Roll Your Own Search Engine의 줄임말로 말 그대로 나를 위한 검색엔진을 만들어준다. 구글에서 정보를 검색하면 수억개의 인터넷 페이지를 대상으로 정보를 찾아준다. 그렇다보니 너무 많은 검색 결과로 인해 정작 꼭 필요한 정보를 쉽게 찾을 수 없게 된다. Rollyo는 특정한 사이트들만을 대상으로 검색을 하도록 검색의 범주를 정해주는 서비스이다. 예를 들어, 중앙일보와 조선일보 그리고 미디어다음 3곳의 사이트에서만 정보를 검색하고자 한다면 Rollyo에서 이들 3개의 사이트를 하나의 그룹으로 만들어두면 이들 3곳만을 대상으로 정보를 검색할 수 있다. 또 이렇게 구성한 나만의 검색엔진은 딜리셔스처럼 다른 사용자들과 공유할 수 있다. 다른 사용자의 경험으로 유용하다고 판단해 만든 전문분야의 검색엔진을 공유해서 사용할 수 있는 것이다.

     


     ☞http://www.Rollyo.com

     


    이전의 WWW Page들에 대한 HTML 데이터를 모두 저장해두는 인터넷 아카이브 사이트이다.www.daum.net의 5년 전 모습이나www.naver.com의 1년전 모습이 궁금하다면 아카이브 사이트를 통해 과거의 웹 사이트 모습을 살펴볼 수 있다.


     ☞
    http://www.archive.org

     

     

    작성자 :  김지현

    작성일 : 2006-05-27 13:21:50

     

    사용자 삽입 이미지

     

    원   문 :http://www.betanews.net/article/337101

      Comments,     Trackbacks
    웹2.0 Startup들

    웹2.0 Startup들

     

     

     

    웹2.0기반의 툴과 서비스가 벗꽃피어나듯 피어나는군요. YouTube는 신제품블로그에서 가끔 이용합니다. 아래 볼드의 업체명을 눌러서 어떤 식으로 피어나는지 감상해보세요. 모든 서비스는 무료입니다.


    social calendar atEventfulorUpcoming,

    organize your to-do items atGootodo,

    store a gigabyte's worth of documents atBox.net,

    read the news (or write your own) atNewsvine,

    find hours of video entertainment atYouTubeorJumpCut,

    create and share Web bookmarks atDiigo,

    create podcasts and audio memos atOdeo,

    publish blogs atWordpressorXanga, and

    share your photos atFlickrorBuzznet-- orRiyaorBubbleshareorZooomr.

    All for free. And that's just the beginning of the list.

     

     [관련링크]Web 2.0s Startup Fever

     

     

    사용자 삽입 이미지

     

    작성일 : 2006.04.14

    출   처 :http://www.skyventure.co.kr/innovation2005/new_product/list.asp?Category=9

      Comments,     Trackbacks
    [웹 2.0은 없다] 오래된 미래 이야기

    [웹 2.0은 없다] 오래된 미래 이야기

     

    웹 2.0 열기가 뜨겁다. 닷컴이 지나온 긴 터널을 생각하면 모처럼의 활기가 나쁠리 없다.미국뿐 아니라우리나라에도 앵콜을 하는 컨퍼런스가 있는 가하면일반 언론들까지 웹 2.0을다루는데 가세했다. 아직은 미국 이야기지만 관련 업체에 대한 투자나 인수합병 열기도 뜨겁다. 하지만 다른 한쪽에서는 '컨퍼런스'가 최고의 수익 모델인‘거품 2.0(Bubble 2.0)’이라거나, 업체들이 자신을 포장하는데 써먹는 마케팅 용어일 뿐이라는 비판도 만만치 않다.

    이런 갑론을박 속에서 사람들을 혼란스럽게 하는 것은 사실 아주 근본적인 질문이다.


    “도대체 웹 2.0이란 무엇인가?”


    대답이 길어지는 것은 언제나 분명한 답이 없기 때문이다. 하지만 언제까지 남의 용어를 빌려서 길잡이를 삼고, 그 다음이 어떻게 펼쳐질지 말해주기만 기다리면서 여행을 떠날 수는 없다. 누구나 자신만의 대답을 가져야 한다. 그래서 필자는 부족하지만 지난 2월 15, 16일웹 2.0 컨퍼런스에서나름의 대답을 시도했다. 그리고 그 내용을 기반으로 다시 글을 쓰려고 한다. 물론 이것만이 정답이라고 주장할 수는 없다. 하지만 필요한 분들이 좋은 답을 찾아가는 데 작은 디딤돌이 될 수 있기를 바란다.

    웹 2.0 혹은 오래된 미래

    사용자 삽입 이미지
    웹 2.0에 대한 여러가지 정의를 듣다 보면, 노자가 도덕경 첫머리에서 말했던 "도가도비상도, 명가명비상명 (道可道非常道, 名可名非常名)"이라는 말이 생각난다. 월드 와이드 웹이라는 것도 정의 내리기 어려운데 ‘2.0’이라는 말까지 붙었으니 뭔가 그럴듯해 보이는 것은 분명하다. 하지만 막상 사업이나 서비스에 적용하려고 하면 손에 잡히지 않는다. 사실 이런 '화두'식의 접근은 말을 잘 고르면 수많은 후발 논쟁을 불러일으키면서 처음 말한 사람(들)을 구름위에 올려놓는 경향이 있다.

    웹 2.0은 누가뭐래도 용어 선택의 승리다. 차세대 웹이나
    시멘틱 웹같은 말이었다면 이런 반향을 일으키지 못했을 것이다. 또한팀 오라일리의 생각과 달리 분명히 마케팅적이기도 하다. 사람들을 움직이는 힘이 있기 때문이다. 의식적이든 무의식적이든 '참여', '공유', '사람' 같은 광고 캠페인 용어들까지 전면에 배치되어 있다. 모호한 희망이 짙게 배어있다. 이렇다보니 "어떻게 적용하나?"나 "수익모델은?" 같은 질문에 곧바로 대답이 나오기 어려울 수 밖에 없다.

    하지만 그럼에도 불구하고 웹 2.0은 잠깐 지나갈 유행으로 넘기기에는 의미가 너무 크다. 어떤 분들의 말처럼 차세대 웹이라서가 아니다. 오히려 웹의 본질을 짚어내고 있기 때문이다. 우선 웹 2.0이라는 말이 등장하게 된 배경부터 그렇다.

    사용자 삽입 이미지
    이 개념은 2004년 미국의 한 컨퍼런스에서 브레인스토밍을 하면서 시작되었다. 닷컴 거품이 붕괴된 후에도 살아남아서 발전하고 있는 구글이나 아마존 같은 기업들의 공통점을 찾던 것이 출발이었다. 마치 스티븐 코비가 200년 간의 성공 관련 문헌을 조사해서
    '성공하는 사람들의 7가지 습관'을 정리한 것과 같은 방식이다. 따라서 웹 2.0은 '살아남은 닷컴 기업들의 7가지 원칙'이라고도 할 수 있다. 우연히도오라일리 역시 7가지를 정리했다.

    1. 웹은 플랫폼이다. (The Web As Platform)
    2. 집단지성을 활용한다. (Harnessing Collective Intelligence)
    3. 데이터가 차별화의 열쇠다. (Data is the Next Intel Inside)
    4. 소프트웨어 배포 주기란 없다. (End of the Software Release Cycle)
    5. 가볍고 단순하게 프로그래밍한다. (Lightweight Programming Models)
    6. 소프트웨어는 PC에 얽매이지 않는다.
    (Software Above the Level of a Single Device)
    7. 사용자들에게 더 많은 편리함을 제공한다. (Rich User Experiences)

    몇몇 선구자들이 웹의 기초를 설계했지만 사실 그것이 어떤 파장을 일으킬지는 완전히 알지 못했다.(각주 1)사람들은 웹에 자신들이 참여한 지 10년이 지난 후에야 비로소 웹이 어떻게 작동하는 세상인지 알게되었다.(각주 2)웹 2.0이란 웹의 업그레이드가 아니라 '웹(과 사람에 대한 이해) 2.0'이다. 웹 2.0이 중요한 것은 새로워서가 아니라 '웹은 이렇게 돌아가고 이렇게 활용한다'는 원칙과 깊은 관계가 있기 때문이다. 자주 언급되는
    RSS나 꼬리표(tag)같은 기술 역시 실상은 그 본질을 담고 연결하는 도구라고 할 수 있다.

    각주
    (1) 철학이 기술을 만들고 기술은 문화를 만든다. 철학이 없다면 창조할 수 없다. 메뉴얼만 읽으며 허둥거릴 뿐이다.

    (2) 월드와이드웹이 세상에 공개된 것은 1991년이다. 하지만 대중에게 알려지기 시작한 것은 1993년 모자이크 브라우저가 등장하고 1994년 검색엔진 서비스가 등장하면서 부터였다. 웹 2.0 논의가 시작된 해(2004년)는 사람들이 웹에 참여하고서 10년을 보낸 후였다.

    그 뿐 아니다. 웹 2.0이 지향하는 '열린 네트워크를 통한 거대한 협력 시스템'은 어느 날 갑자기 등장한 것이 아니다. 1997년에 나온 에릭 레이몬드의 '성당과 시장(The Cathedral and the Bazaar)'에서도 발견할 수 있다. 리눅스와 오픈 소스 프로젝트의 원칙을 정리한 이 기념비적인 문서는 너무나 웹 2.0스럽다!


    "일찍 발표하고 자주 발표하며, 할 수 있는 모든 것을 위임하고, 뒤범벅이 된 부분까지 공개하는, 리누스 토발즈의 개발 스타일은 놀라울 뿐이었다."


    양쪽의 차이는 생각보다 많지 않다. 성당과 시장이 프로그래머라는 특정 집단이 서로 협력하면서 응용 프로그램을 개발하는 방식이라면, 웹 2.0은 더 넓게 확장되어 일반 사용자들이 웹 서비스 위에서 다양하게 협력하는 것이다. 영역은 다르지만 근본 마인드는 같다. 성당과 시장의 주장 몇가지를 웹 2.0의 눈으로 살펴보자.

    사용자 삽입 이미지
     
    사용자 삽입 이미지
     
    사용자 삽입 이미지
    성당과 시장웹 2.0
    "사용자는 공동 개발자다."플리커,위키피디어등에서 사용자는 공동 편집자다.
    "일찍 발표하고 자주 발표한다."끊없는 베타(Perpetual Beta) 서비스가 되어야 한다.
    "자료 구조를 훌륭하게 만든다."참여와 공유를 뒷받침하는 아키텍쳐가 필요하다.
    "완벽함은 더 이상 버릴 게 없는 상태를 말한다."단순하고 모듈화 된 프로그래밍을 한다.
    "기존 것을 재사용한다."에이잭스(AJAX)는 신기술이 아니라 신조합이다.
    사용자 삽입 이미지
    사용자 삽입 이미지


    사용자 삽입 이미지


    웹 2.0은 오래된 미래다. 역사에서 찾은 미래이며, 본질에서 찾은 성공 전략이다.(각주 3)피터 드러커는 인터넷 혁명을 전망하기 위해 철도 혁명을 되돌아 보았다.(각주 4)마케팅 전문가인 알 리스는 "미래를 예측하는 유일한 방법은 과거를 연구하는 것"이라고 했다. 웹 2.0을 신기술이나 새로운 혁명으로만 포장한다면 결국 또 한번의 실망으로 끝날 것이다.

    각주
    (3) 웹 2.0이 궁긍적으로 건드리는 영역은 너무나 사회적이고 철학적이다. 꼬리에 꼬리를 문다면
    알렉산드리아 도서관이나가인과 아벨이야기까지 거슬러 올라가야 할지도 모른다.

    (4) 인간의 활동 영역이 확장되었다는 점에서 인터넷 혁명과 철도 혁명은 같은 맥락에 있다.


    웹의 미래를 보기 위해 본질로 눈을 돌려야 한다. 그 본질의 물꼬를 터주는 기술과 서비스를 지향해야 한다. 또한 웹 2.0이란 단어에 묶여 있을 필요도 없다. 그 단어는 불 붙이는 일로 생을 다하는 점화용 화두에 불과하다. 언덕 너머 세상은 팀 오라일리와 친구들 역시 알지 못한다.

    부디 웹 2.0 논의가 짧은 욕심에 파묻히지 않고 웹다운 웹이 발전하는 전기가 되기를 바란다.

     

     

    작성자 :전병국 (검색엔진마스터 대표)

    작성일 :2006/03/08

     

    사용자 삽입 이미지

     

    출   처 :http://www.zdnet.co.kr/builder/dev/web/0,39031700,39145256,00.htm

      Comments,     Trackbacks
    Ajax와 웹 기반 매쉬업,「빛 좋은 개살구?」

    Ajax와 웹 기반 매쉬업,「빛 좋은 개살구?」

     

    이제 갓 1년이 넘은 Ajax 브라우저 프로그래밍 기술은 지난 몇 개월 동안 언론의 많은 조명과 산업계의 주목을 받았다. 그러나 아직 풀리지 않는 AJAX의 의문점들은 남아있다.

    이 기술로 개발되고 있는 매력적인 소프트웨어들 때문이 아니다. 여전히 의구심이 남아 있다면 마이클 애링턴의 테크크런치(TechCrunch)를 살펴보기 바란다.

    제시 제임스 가렛은 '이제 웹 개발의 다음 단계로 나아갈 기초를 다져야 할 때다'라고 말했다.

    Ajax는 웹에서의 서비스라는 개념의 소프트웨어 모델로써 또 다른 가능성을 보여주고 있으며, MS와 같은 거물급의 소프트웨어 회사들은 곧 출시될 MS의 아틀라스(Atlas)와 같은 정교한 Ajax 개발 프레임워크와 Ajax 데스크톱, 온라인 비즈니스 소프트웨어 등에 상당한 투자를 하고 있다. 심지어 보다 보수적인 회사인 IBM과 오라클은 최근 서로 손을 잡고 Ajax가 어떻게 될 것인지 이해하고, 올바른 방향으로 나아가게 하기 위해 오픈 Ajax 연합(Open Ajax coalition)을 결성했다.

    뜨는 Ajax 애플리케이션 모델
    뉴욕에서 열린 리얼월드 Ajax(Real-World Ajax) 세미나에는 Ajax 선각자들인 제시 제임스 가렛, 데이브 크레인, 데이비드 헤인미어 핸슨, 스캇 딧슨, 빌 스캇 그리고 다른 많은 사람들이 Ajax의 최근 개발 현황에 관한 이야기를 하기 위해 모였다.

    행사가 진행되면서 청중으로부터 나오는 관심과 질문을 지켜보는 것은 매우 흥미로웠다. 비록 회의론자조차도 Ajax를 지원하는 웹 사이트가 늘어날 것이라는데 동의하기는 하였지만, 그들의 큰 관심사는 비즈니스 애플리케이션과 중요한 개인용 소프트웨어 개발에 있어 Ajax 모델이 얼마나 적당한지에 대한 것이었다.

    Ajax 애플리케이션 모델이 정말 대부분의 소프트웨어에도 좋은 것인가?

    로컬 클라이언트의 하드 디스크를 쉽게 이용하는 것도 불가능하고 혹은 인터넷을 사용할 수 없다면 소프트웨어 접근도 불가능한 이 애플리케이션 모델이 정말 고려할 만한 모델일까?

    위에서 언급한 문제와 일반적인 엔터프라이즈 기술과의 호환성 같은 다른 중요한 문제는 많은 사람에게 중요한 관심거리였다. 이 세미나에는 큰 회사의 개발자들 혹은 인터넷 회사의 프로그래머들이 거의 비슷한 비율로 참석했지만, 놀랍게도 대부분의 사람은 이 문제에 낙관적이었다. 참가자들은 Ajax에 대한 감을 얻기 위해 Ajax 전문가들이 10시간에 걸쳐 진행한 세션까지도 참을성있게 참석했다.

    일 년 혹은 그 이상 복잡한 Ajax 소프트웨어를 개발해 온 Ajax 전문 업체들 또한 자신들이 배운 흥미로운 내용을 발표했다. 짐브라(Zimbra)의 CTO인 스캇 딧슨은 특히 그동안 SOA 프로젝트 관리자을 괴롭혔던 성능 최적화 문제와 Ajax 소프트웨어 테스트 방법을 소개했다.

    Ajax라는 용어가 정립되기도 전에 이 분야에 진출한 팁코(TIBCO)와 벡베이스(Backbase)같은 Ajax 개발 툴 선두 회사들은 꽤 잘 만들어진 Ajax 툴을 가지고 강한 인상을 주었다. 흥미롭게도 그 회사들의 개발 툴은 순수 웹 소프트웨어 개발자들보다는 회사 소프트웨어 개발자에 초점을 맞추져있다. 또한 많은 발표 세션에서 매우 새로운 Ajax 기반 SOA/클라이언트 모델도 여러번 소개됐다. 플러그인이나 ActiveX를 없애고 관리도 필요없고 웹에서 서비스 되는 리치 애플리케이션에 대한 비전은 많은 사람들에게 희망의 메시지가 된 것처럼 보였다.

    아직 검증되지 않은 호환성
    비전은 밝다. 하지만 툴과 문제들도 그러한가?

    대중들에게 "웹 개발을 위한 다음 단계를 위해서 기반을 다질 시간"이라고 이야기를 하고 Ajax란 용어를 만들어낸 발표자 제시 제임스 가렛이 Ajax의 기본 비전을 설명했고, 청중들은 그들이 듣고 있는 것이 얼마나 중요한지 평가하기 위해 노력했다. 분명히, 항상 비관주의자들은 있어왔다. 하지만 심지어 실용주의자들 역시 이 새로운 온라인 소프트웨어 모델이 실제로 큰 조직 및 소프트웨어와 호환성을 가질지에 대해서는 여론이 분분하다. Ajax와 Ajax 관련 소프트웨어들이 너무 다르고 또 모델의 요구조건이 기존의 검증받은 엔터프라이즈 모델 및 소프트웨어와 너무 동떨어져서 개발자 툴이 쓸모없어지게 될지도 모른다.

    하지만, 만약 진정한 실용주의자를 찾는다면, 어제 오후 Ajax 레일(Rails) 프리젠테이션에서 루비 온 레일(Ruby on Rails) 프레임워크의 인기로 인한 여러 가지 장점들을 설명하며 가장 명확한 비전을 제시한 데이비드 헤인미어 핸슨이다. 나는 그에게 직접적으로 레일의 확장성과 개발 진척도를 물어보았다. 그는 37시그널(37signals)은 약 18대가 안되는 서버들로 거의 40만 명의 사용자를 서비스하고 있다고 말했다. 또한 루비에 기반을 둔 레일은 개발을 새로하는 것이 아닌 유지보수가 대부분인 기업 시장에선 거의 강제적 조건인 소프트웨어 유지 관리를 기존의 어떤 것보다 보다 쉽고 간단하게 해준다고 한다.

    비록 레일과 엔터프라이즈가 오늘 토론의 주제였지만, 레일 커뮤니티가 주장하고 레일 프레임웍에서 구체화되었던것처럼 소프트웨어 개발의 실용적 접근은 어느 사업가가 '가젤' 이라는 별명을 붙인 것 처럼 적어도 작고 빠르게 변화하는 현대 조직에서는 매우 호환성이 클 것이다.

    더 큰 성공으로 가는 도약? 실패?
    나는 Ajax, SOA/클라이언트 그리고 애자일(agile) 개발론을 신뢰하는 사람이다. 왜냐하면, 요새 웹에서 쏟아지듯 나오는 꽤 높은 질에 낮은 가격의 혁신적인 소프트웨어들을 볼 수 있기 때문이다. 하지만, 우리가 큰 작업을 쉽게 할 수 있도록 도와주는 툴들이 반대로 큰 디자인과 구현, 그리고 확장을 쉽게 하는 프로그램을 개발하도록 우리를 내모는 것 역시 자명하다. 이는 결국 적어도 경험 곡선이 따라잡기 전까지는 결과가 성공을 하건 실패를 하건 이런 기술들을 사용한 단기 결과는 매우 다양할 것이다.

    그리고 나는 이것이 다음과 같은 케이스는 되지 않을 것이라고 확신하지만, Ajax와 웹 기반 매쉬업(mashup)은 '빛 좋은 개살구'와 동의어가 될 수도 있다.

    다이내믹 소프트웨어 언어는 확실히 고민해야 할 부분이 있다. 새로운 소프트웨어를 이 언어로 만들 것인가?@
     
     
    작성자 :Dion Hinchcliffe ( ZDNet )
    작성일 :2006/03/16
     
     
      Comments,     Trackbacks
    웹의 혁신, 웹 2.0 시장 동향

    웹의 혁신, 웹 2.0 시장 동향

     

    웹 2.0이 화두이기는 화두인 듯 하다.

     

    어느 세미나 업체는 내용은 부실했다는 평가를 받지만, 팬시한 주제를 선점함에 따라 예상치 못한 엄청난 매출을 올렸다고 할 정도이니 말이다.

     

    스카이벤처에서도 몇번 다룬 주제이기는 하나, 소프트웨어인사이트에 올라온 정리가 관련지식은 없는 분들이 보기에 잘 정리가 되어 있어 공유하고자 한다.

    웹2.0과 구글사례

    http://www.skyventure.co.kr/club/seminar/view.asp?Num=52

    Web2.0 컨퍼런스

    http://www.skyventure.co.kr/innovation2005/new_product/list.asp?Num=2004&NSLT=Y&Atc 

     

     

    Web 2.0의 개념 및 정의

     

    웹 2.0의 개념은 O''Reilly와 MediaLive International의 컨퍼런스 브레인스토밍 세션에서 Dale Dougherty에 의해 시작되었다. 기존의 클라이언트-서버 모델에 기반을 둔 정적인 웹, 그리고 주류미디어에 의해 잠식되며 매스커뮤니케이션과 매스광고에 의해 지배되던 웹이 근본적으로 변화하고 진화한 차세대 웹을 뜻한다.

      

    이 개념을 주장한 사람들은 궁극적으로 웹 2.0 서비스가 데스크톱컴퓨터의 응용 프로그램마저 대체할 것으로 전망하고 있다. 웹 2.0의 정의는 현재까지 많은 논의가 있고, 학자나 관계자들 간의 여러 가지 정의가 있지만 보통은 “최종사용자에게 웹 애플리케이션을 제공하는 컴퓨팅 플랫폼”으로 정의하고 있다. 즉, 인터넷 서비스 업체가 블로그, 검색, 지도, 꼬리표달기(Tagging)등 다양한 기능을 제공하고 고객이 이를 직접 활용하는 ‘사용자 지향적인’ 웹 플랫폼을 의미하고 있다.

      

    표 1. 웹 1.0과 웹 2.0의 비교

    사용자 삽입 이미지

     

    <자료: 한국전산원 IT신기술사업팀>

     

     

    Web 2.0의 특징 ? ‘참여''와 ''개방’

     

    웹 2.0의 가장 큰 특징은 사회적 상호작용과 개인 참여가 핵심이라고 할 수 있다. 웹2.0에서는 웹에 존재하는 정보가 개인의 참여를 통하여 생성되기 때문에 개인의 참여가 가장 핵심적인 역할을 한다. 웹2.0의 대표적 사례인 블로그는 개인의 참여를 기초로 하고, 사용자간에는 누구나 RSS를 통해 다양한 콘텐츠를 요약하고, 상호 공유하고 주고받을 수 있도록 할 수 있다. 또한 정보의 위치와 내용을 알 수 있으며 의견을 교환하는 것 또한 가능하다.

    웹2.0은 아무도 데이터를 소유하지 않고 어떤 프로그래밍 또는 인터넷 환경에서도 모든 사람이 데이터를 사용할 수 있는 플랫폼을 의미한다. 그 동안 웹사이트는 일방적으로 TV나 라디오처럼 정보와 서비스를 제공하기만 해왔는데 이를 미디어라고 표현하기도 했다. 지금까지는 웹사이트에 올린 데이터 또는 서비스되는 데이터를 이동시키거나 활용할 수 없었다.

      

    그러나 웹 2.0 환경이 구축되면 자유롭게 데이터를 이동시킬 수 있게 된다. 이러한 ‘웹의 플랫폼화‘ 영향으로 예전보다 웹에 있는 정보를 이용하기가 더 용이해졌으며 그런 정보는 거의 공개되고, 수정이 가능하므로 이를 개인 사용자가 자신의 편의에 따라 수정, 보완할 수 있는 환경으로의 변화를 가져다 줄 것이라고 예상된다.


     

    웹 2.0 기술로 주목 받고 있는 AJAX

     

    웹 2.0에 대한 관심이 증대하면서, 관련 기술에 대한 기업들의 관심도 증가하고 있는 추세이다. 웹 2.0 인프라 기술은 복잡하고 진화 중에 있으며, 대표적 기술은 AJAX, Java Web start(Flex, Laszlo, Flash), XUL, RSS, Atom, REST, XMLWebserviceAPIs, 태깅(Folksonomies), Wikis, LAMP 등이 있다. 이러한 웹 기술들은 일부 개발자 중심으로 스터디가 진행되었지만, 선도기업을 중심으로 서서히 주목 받기 시작한 것이다.

     

     

    표 2. 웹 2.0의 주요 기술

     

     

    사용자 삽입 이미지

     


    특히 구글 맵스와 gmail에 AJAX기술이 채용되면서, 개발자들 사이에서 AJAX에 대한 관심은 점점 증가하고 있다. AJAX는 자바스크립트 언어와 기타 웹 표준을 사용하는 기술로 지난 1990년대에 MS에서 개발됐으나, 최근까지 다수의 개발자와 기업들은 AJAX가 제공하는 새로운 기회에 주목하지 않았다. 그러나 인터넷 대표기업인 구글에서 구글 맵스라는 지도서비스 개발에 AJAX를 사용하면서 기존 데스크톱 애플리케이션의 외관 및 느낌을 보여줄 수 있음을 입증했다.

     

     

    특히 몇몇 업체들이 웹 브라우저 웹 표준을 폭넓게 도입함으로써 개발자들에게 AJAX 애플리케이션이 대부분의 PC에서 가동될 수 있다는 확신을 심어줬다. 기존의 개발전문가들은 수년 동안 매크로미디어의 플래시나 플렉스 등 멀티미디어 툴이 인터랙티브 웹 페이지 구축에 많이 이용해 왔다. 세심한 업무를 위해 이 툴들이 계속 쓰이겠지만 기존 웹 사이트에 상호작용성을 추가하는 것 같은 단순 업무에는 AJAX의 활용이 넓어질 것이라는 전문가 의견이 다수를 이루고 있다.

     

     

    데스크톱 SW 시장의 지배적 사업자인 MS는 비록 늦은 감이 있지만 웹 기반 애플리케이션 서비스를 향해 공격적으로 움직이고 있다. MS가 지난해 말부터 선보인 라이브닷컴(Live.com)도 많은 부분을 AJAX로 만든 웹 애플리케이션에 의존하고 있다.

     

     

    또한, IBM, 오라클, 야후, 구글, BEA시스템스, 레드햇, 볼랜드 등은 Ajax 기술을 기존 또는 신형 소프트웨어에 쉽게 적용할 수 있도록 ''오픈Ajax'' 프로젝트를 출범시켰다. 이를 위해 IBM은 자사 SW 소스코드를 오픈소스 개발툴 프로젝트인 이클립스 재단에 기증했다. SW 개발자들이 이클립스 개발툴을 사용, Ajax 기반 웹 애플리케이션을 쉽게 개발할 수 있도록 하기 위해서다. 또한, AJAX개발 기업들이 속속 등장하고 있으며, 현재 AJAX를 웹 기반 커뮤니케이션 서비스의 필수적인 부분으로 만들어 가는데 일조할 것으로 전망하고 있다.

     

     

    그림 1. 웹 애플리케이션 모델 비교

    사용자 삽입 이미지

     

     

    국내외 업계 동향- 서비스, 애플리케이션 업체의 인수합병은 진행 중

     

    최근 웹 2.0이 각광을 받으면서 웹 2.0 기업에 대한 관심이 급증하고 있다. 이들 기업들 대부분은 생존을 걸고 구글과 야후, MS 같은 대기업에 인수되는 것을 목표로 성공사례를 만들기 위해서 노력하고 있다. 구글은 웹 기반의 워드 프로세서 라이틀리를 개발하는 업스타틀을 인수했다.

     

    업스타틀은 소수의 직원을 보유해 인수 규모가 크지 않다. 그러나 구글의 이런 움직임 뒤에는 웹 기반의 상용 애플리케이션에 대한 관심이 더욱 두드러지게 하는 중요한 의미가 있다. 이런 온라인 애플리케이션에는 압도적인 시장 점유율을 자랑하는 MS오피스에 대항할 가능성까지 엿보인다. 이전에 구글은 블로거나 사진 공유 서비스인 피카사, 지도 서비스인 키홀을 포함한 몇 개의 기업을 인수했다.

      

    구글이 외에 인수합병에 적극적인 회사는 야후이다. 야후는 사진 공유 사이트인 플리커나 위제트로 불리는 데스크톱 애플리케이션을 개발하는 콘파뷸레이터(Konfabulator)를 인수했다. 웹 2.0서비스에서는 구글에 밀리지 않겠다는 전략이다. 구글, 야후, 아메리칸 온라인, MS의 MSN 사업부 등의 대표적인 포탈사이트들은 제품/서비스 보완을 위해서 규모가 작은 니치 기업이나 제품을 계속 인수합병하기 위해서 지속적으로 노력할 것이라는 전망이 지배적이다.

      

    최근 국내에서는 탄탄한 마니아층을 확보하고 있는 온네트(대표 홍성주)의 정통 블로그사이트 이글루스를 SK커뮤니케이션즈가 조건부 영업양수도 계약을 체결하였다. 이로써, 국내에서도 웹 2.0관련 기업들에 대한 기업들의 관심이 증가하고 있다라는 것을 단적으로 보여준 예라고 할 수 있다. 해외 에서의 움직임과 마찬가지로 관련 서비스와 기술확보를 국내에서도 인수합병이나 전략적 제휴가 빈번하게 일어날 것으로 예상된다.

      

    최근 열린 웹 2.0 관련 세미나에서는 닷컴 기업들의 웹 2.0 동향과 전략이 발표되는 자리였다. 다음커뮤니케이션은 ‘미디어 2.0’의 개념을 기반으로 하여 ‘사용자의 관심은 원하는 정보를 정확하게 찾고, 자신이 만든 정보를 공유하는 것’ 이라는 인식아래, 사용자들이 1인 미디어로서 많은 이들에게 노출되고 상호작용할 수 있는 플랫폼을 제공할 것을 전략적 지향점으로 밝히고 있다.

     

    SK커뮤니케이션즈는 상반기에 네이트닷컴을 통해 지리적으로 근접한 이용자 간의 정보를 연결해주는 신개념 미디어 ‘오픈맵’을 선보이면서 웹2.0 서비스를 강화한다는 전략이다.

    한국마이크로소프트(대표 유재성) MSN사업부는 조만간 국내에서 신개념 개인 맞춤형 포털 서비스인 ‘윈도라이브’에 대한 마케팅에 돌입한다. 윈도라이브에서는 개인이 관심 있는 항목만을 선택해 홈페이지를 제작할 수 있으며 마우스 끌기만으로 사이드바에 위치한 분류항목을 추가할 수 있다.

     

    ‘야후 허브’, ‘flickr’를 새롭게 선보인 야후코리아는 사용자들의 정보 공유가 활발한 사이트들을 추가적으로 인수할 방침이라고 밝혔다. 야후코리아의 웹 2.0 전략은 ‘검색에 있어, 기술 중심의 찾기 서비스로부터 FUSE로의 진화를 지향’하고 있다고 밝히고, 자사의 서비스 전략비전을 이같이 요약했다. FUSE는 단순히 찾기 서비스가 아닌 Find(찾고), Use(사용하고), Share(공유하고), Expand(확장하는) F-U-S-E를 의미한다는 것이다.

      

    향후 전망 및 결론

     

    아직까지 국내에서는 `시맨틱웹'' 이나 `웹2.0''이라는 낱말조차 생소하다. 치열하게 웹2.0 기업이 성장 인수 합병되는 해외 상황과 비교하면 크게 차이 난다.하지만, 이용자 참여와 개방성을 표방하는 ‘웹2.0’의 개념을 구체적으로 적용한 차세대 인터넷 서비스가 올 상반기에 봇물처럼 쏟아질 전망이다.

      

    이에 따라NAVER, DAUM, EMPAS, PARAN, MSN과 네이트닷컴 등 주요 포털과 특정 분야 서비스 전문업체들이 웹2.0 지원 서비스 구현에 박차를 가하면서 인터넷 시장의 지형 변화가 예고되고 있다.

      

    하지만 해결해야 할 문제점들도 있다. 국내 포털들은 폐쇄적인 체제를 갖추고 각 포털의 방문자수를 집계해 서로 우열을 가리는 배타적인 태도 또한 `개방''과 `공유''라는 웹의 기본정신과 많이 동떨어져 있는 게 사실이다.

      

    이런 상황에서 `웹2.0''이라는 이슈를 통해 웹의 기술적 진보뿐만 아니라 그 이면의 웹 기본 정신의 부활이라는 반향을 시장에 일으켜 주길 기대하는 것은 아직까지 시기상조일 수 있다.

      

    하지만 `웹2.0''이 가지는 여러 긍정적인 가치가 제대로 시장에 접목되기 위해서 웹2.0의 성공전략과 구체적인 수익모델에 대한 고민이 수반된다면, 웹 2.0 시대가 도래하는 것도 멀지 않은 미래가 될 것이다.

     

     

    작성자 :다니엘  

    작성일 :2006.03.23 

     

    사용자 삽입 이미지

     

    출   처 :http://www.skyventure.co.kr/club/xpert/osub/view.asp?Num=979&XPTLKNum=79&xptid=5&NSLT=Y

      Comments,     Trackbacks
    <img src="http://blogimgs.naver.com/nblog/ico_scrap01.gif" class="i_scrap" width="50" height="15" alt="본문스크랩" /> 콘텐츠 新분류법 '꼬리표 달기'

    콘텐츠 新분류법 '꼬리표 달기'
     


    "두뇌에서 시냅스가 많이 형성될수록 연상작용은 반복 또는 강화에 의해 더 강력해지는 것처럼, 모든 웹 사용자의 집단 행동의 결과로 웹의 연결은 유기적으로 성장한다.

    ..(중략)...태깅을 사용하면 경직된 카테고리와 달리 태그를 사용하는 두뇌들의 연관관계들이 중첩되는 것을 허용한다.

    " -팀 오라일리의 웹2.0 정의에서 집단 지능(collective intelligence)에 대한 설명

    "폭소노미(folksonomy)는 전혀 새로운 것이 아니다.

    HTML문서에 존재하는 '메타태그(metatag)'를 생각해보라. 아니라고? 다른 것이라고? 흠.. 좀더 생각해보자. 맞는데 뭘." -존 드보락의 PC매거진 '태그를 달 것이냐 말 것이냐, 그것이 문제로다'에서

    블로그들 사이에 차세대 인터넷을 설명하는 단어로 '웹2.0'과 '시만틱 웹'에 대한 논란과 더불어 '폭소노미(folksonomy)', 또는 '태깅(tagging)'에 대한 개념과 이를 통한 새로운 분류법에 대한 연구가 활발하다.

     

    흔히 '사람들에 의한 분류법(Folk+order+nomos)’으로 알려진 폭소노미는 키워드로 분류하기, 태그 붙이기(tagging), 또는 꼬리표 붙이기 정도의 의미를 갖고 있다.

    예를 들어 어떤 블로거가 인터넷과 관련된 글을 써 놓고 '인터넷', '웹' 등의 태그를 붙이면 이 태그만으로 새로운 카테고리가 생성되는 방식이다.

     

    인간 뇌의 연상법에 기초한 꼬리표 붙이기
    이 꼬리표 붙이기는 전통적인 분류법인 위에서 아래로 피라미드 구조를 갖춘 카테고리 분류 방식보다 훨씬 '인터넷 답다'는 평가를 듣고 있다.

    각 키워드들은 한 콘텐츠에서 새롭게 생성되기도 하고 함께 묶인 꼬리표들이 서로 연결과 연결을 형성하면서 각 콘텐츠를 유기적으로 연결한다.

    이런 모습이 마치 사람의 두뇌가 생각하는 과정인 시냅스의 연결과 비슷하다는 점에서 좀더 인간적인 접근법이라는 말도 나온다.

     

    서비스형 블로그도 오픈돼 있는 미국에서 서로의 관심사를 서로 엮어 내려는 시도로 이러한 태그를 사용하기도 하며 각 콘텐츠의 비어있는 부분을 새로운 콘텐츠로 보강하려는 의도로도 사용된다.

     


    해외에서 북마크 공유 사이트 델리셔스(del.icio.us/tag)와 포토 블로그 플릭알(flickr.com/photos/tags)과 메타 사이트 테크노라티(technorati.com) 등에서 구현된 모습에 네티즌은 열광적으로 서로의 DB를 연결하려는 모습을 보이고 있다.

    최근 플릭알을 인수한 야후!는 오늘 델리셔스까지 인수하면서 웹2.0의 주도권을 쥐려는 의지를 나타냈다.

     

     

    국내에서도 이러한 꼬리표붙이기가 본격적인 활성화에 들어서고 있다.

    최근 블로그 기자 뉴스를 시작한 다음 블로그에서는 일찍부터 태그(tag)를 이용한 블로그 서비스(blog.daum.net/help/1170817)를 실시하고 있으며 야후!코리아도 최근 태그를 활용한 허브(kr.hub.yahoo.com)라는 서비스를 베타 운영중이다.

    전문 블로그 사이트인 이글루스의 경우 태그를 활용해 같은 주제로 글쓰기 기능을 활용한 느슨한 커뮤니티 형태인 '가든(valley.egloos.com/gd_valley.asp)'을 운영중이다.

    국내 설치형 블로그로 이름을 날리고 있는 태터툴스(www.tattertools.com)로 만든 블로그들도 이러한 태그 방식을 사용해 임의적인 키워드 사전을 구축해 나가고 있다.

    블로그 메타사이트인 올블로그(www.allblog.net)는 기존 키워드들과 '주제어'를 함께 활용한 검색을 도입했으며 싸이월드는 '미니링(cyworld.nate.com)'이란 이름으로 태그 서비스를 실시하고 있다.

     

     

     

    650만명의 회원을 확보한 국내 최대 서비스형 블로그인 네이버 블로그(blog.naver.com)도 최근 태그 기술을 적용하기 위한 검토에 나섰다고 관계자가 밝힌 바 있다.

    최근 새로 등장한 IT 전문 미디어인 스팟뉴스(www.SpotNews.com)은 뉴스 관리자가 태그를 통제하고 관리하는 형태인 '이슈팟'이란 서비스를 도입하기도 했다.

     

    이들 태그의 특징은 어디가 시작이고 끝인지를 알 수 없는 구조라는 점이다.

    각 키워드들을 논리에 의해 연결하기 보다 콘텐츠의 내용과 성격 등을 사용자 스스로 판단해 키워드들을 나열해 놓으면 서로 중복되는 키워드들이 각각의 카테고리를 형성하기 때문에 마치 뫼비우스 처럼 서로 연결하다 보면 시작은 했지만 끝을 알 수 없는 구조로 빠져들게 된다.

    이른바 인터넷 콘텐츠 읽기 마니아들이 하는 '태깅놀이'는 지식을 좀더 심화시킬 수 있다는 매력을 갖고 있다.

     

    이는 웹2.0을 주창한 팀 오라일리를 비롯한 인터넷 선구자들이 말하는 '집단 지식 진화'의 개념으로도 설명할 수 있는 부분이다.

    또한 이러한 태그가 이미 표제어 규모나 내용면에서 브리태니커를 능가했다는 평가를 받는 자발적 인터넷 백과사전인 '위키피디아(www.wikipedia.org)'와 연결될 때의 모습은 기존 콘텐츠 주도권을 갖고 있던 권위자들의 지식에 도전할 수 있는 체제를 마련하게 된다는 것이 인터넷 전문가들의 생각이다.

     

    내용 불일치, 태그 스팸 등 우려
    하지만 태그 기술이 어떻게 발전할 것이냐를 놓고 앞에서 브로락이 말했던 바를 생각해볼 필요는 있다.

    기본적으로 한 콘텐츠가 담으려 하는 내용이 '관련되거나 연상되는 단어나 문장'이라면 HTML 코드 앞 단에 등장하는 '메타태그(metatag)'와 다를 바가 없다는 지적이 그것이다.

     

    예전에 검색기술이 일천했을 당시 기본적으로 웹 페이지의 모든 내용을 검색하려 하지 않고 자동화된 웹검색로봇(스스로 웹을 돌아다니며 필요 정보를 수집해 인덱싱하는 기술)들이 메타태그 분석에만 매달렸던 때가 있었다.

     

    그런데 문제는 이 메타태그 기술을 역 이용하면 자신의 콘텐츠에 더 많은 접속을 하도록 유도하기 위한 이른바 '낚시질' 키워드를 무작위로 넣는 경우가 생겼던 것이다.

    초기 검색엔진들이 관련성 없는 웹페이지들을 무순으로 나열했을 때의 문제가 지금 태그 방식의 기술이 발전하고 태그 하나하나를 따로 카테고리로 분류할 수 있는 기술이 실현됐지만 이마저도 콘텐츠 생산자에게 태그 붙이는 방식을 스스로 결정하게 함으로써 생기는 문제를 드보락은 우려하고 있는 것이다.

     

    예를 들어 최근 이슈의 중심으로 떠 오른 '황우석'이나 '줄기세포' 등의 키워드를 자신의 일기나 홍보하려는 내용, 또는 정 반대의 역 정보를 흘리는 수단을 위해 무차별적으로 태그로 활용한다면 이른바 '태그 스팸' 현상이 발생하게 될 가능성도 높다.

    또한 그 반대의 경우도 있을 수 있다.

    자발적이란 점에서 자신의 콘텐츠가 제아무리 여러 태그를 붙일 수 있는 내용이라도 스스로 붙이지 않으면 그 콘텐츠는 태그들 사이에서 동떨어진 외톨이 신세가 될 수 있다.

    예전의 태그를 붙일 수 없던 시절에 생산된 콘텐츠의 분류는 또한 어떻게 한단 말인가. 그리고 인터넷 하나만으로 무수하게 만들어지는 오탈자, 외계어, 외래어, 띄어쓰기 불일치 등의 문제는 누가 정리해줄 것인가.

    웹2.0 개념이 단지 시만틱 웹을 비즈니스형으로 변형시킨 마케팅 용어쯤으로 폄하하고 있는 이들은 폭소노미 조차 새로운 개념이라기 보다 씽크맵(연상되는 단어를 무작위로 연결시켜 그림으로 표현하는 방식)이나 기존의 메타태그의 변형을 듣기 좋게 새로운 단어를 만든 것에 불과하다는 비판을 가하고 있다.

     

    이렇듯 여러 문제를 내재하고 있지만 인터넷의 극단적인 민주주의적 운영방식으로도 성공을 거둔 오픈소스, 위키위키 등의 사례로 봤을 때 많은 전문가들은 어떤 식으로든 자발적인 콘텐츠 생산자로서의 누리꾼의 역할이 차세대 인터넷을 이끌 것이란 기대를 갖고 있다.

     

    [명승은 기자]

    ⓒ SpotNews.com&매경인터넷. 무단전재 및 재배포 금지

    <매경인터넷은 한국온라인신문협회(www.kona.or.kr)의 디지털뉴스이용규칙에 따른 저작권을 행사합니다>

     

    2005.12.10 22:20 입력

     

    http://inews.mk.co.kr/CMS/economy/all/dist/dist1/7104692_2992.php

      Comments,     Trackbacks
    <img src="http://blogimgs.naver.com/nblog/ico_scrap01.gif" class="i_scrap" width="50" height="15" alt="본문스크랩" /> [펌]사용자 참여적인 인터넷의 '태그' 기능
    '태깅(tagging)'이라는 단어가 인터넷 업계에서는 요즘 뜨겁다. 사진 공유 서비스인 플리커(Flickr, http://flickr.com/)가 대표적인 예이다. 누구든 직접 찍은 사진을 올리고 공유하는 플리커는 디지털 카메라의 보급과 함께 5천만 명이 넘는 사용자를 확보했다.

    플리커에서 중요한 기능 중 하나가 사진을 올릴 때 '태그'를 달 수 있다는 것이다. 주제와 관련 있는 키워드를 선택해 붙이면 다른 사용자가 쉽게 관련 사진을 검색해서 볼 수 있다. 현재 플리커에 올라오는 사진 중에서는 3분의 2에 해당하는 사진에 태그가 달려 있다.

    플리커의 '태그' 개념은 이제 인터넷에서 흔히 찾아볼 수 있는 기능이다. 여러 사람이 관심 있는 웹 페이지 링크를 공유하는 공유 북마크(social bookmark)나 블로그, 음악 서비스, 온라인 서점 등에서도 응용되고 있다. 사용자가 정의하는 체계라는 점에서 한동안 학계 등에서는 '폭소노미(folksonomy)'라고도 불렸으나 최근에는 '태깅'으로 더 많이 사용된다.

    태그의 본질은 참여적, 자발적이자 '사회적'이라는 것으로, 콘텐츠를 다중 사용자가 공유하기 위한 열쇠가 된다는 특징이 있다. 어떻게 생각하면 매우 간단한 개념이지만, 그 효과는 증폭되어 중구난방이던 웹에 체계적인 의미를 부여할 수 있는 기회가 되고 있다. 자발적이고 분산적인 색인이 동시다발적으로 생겨나 여러 가닥으로 흩어진 웹을 찾아 보기 쉽도록 정리해주는 결과를 낳기 때문이다.

    플리커와 비슷한 태깅 서비스가 활발히 쓰이고 있는 사이트로는 공유 북마크 사이트로서 많은 사용자를 보유하고 있는 딜리셔스(http://del.icio.us/), 블로그 사이트인 테크노라티(http://www.technorati.com/) 가 있다. 딜리셔스 사용자들은 각자가 모은 북마크에 적당한 태그를 붙여둔다. 예를 들어 "리눅스", "윈도우즈", "오픈소스" 등의 주제로 태그가 달린 북마크들은 다른 사용자들이 쉽게 찾아서 공유할 수 있다. 관련 태그를 타고 옮겨가면서 관심 분야의 웹페이지들을 매우 편리하게 수집할 수 있다는 것도 큰 장점이다.

    전문가들은 태깅 서비스가 앞으로 어떤 형태로든 기존 검색 엔진 기능에 흡수될 것이라고 예측하고 있다. 구글에 뒤이어 검색 엔진 시장 점유율 2위인 야후사가 플리커를 인수한 것만 봐도 이러한 예측이 근거 없지 않다는 점을 알 수 있다.
      Comments,     Trackbacks
    <img src="http://blogimgs.naver.com/nblog/ico_scrap01.gif" class="i_scrap" width="50" height="15" alt="본문스크랩" /> 폭소노미(folksonomy)
    ● 폭소노미(folksonomy)란? / 2005. 9. 12.

     

    http://ciroo.com/fantazic/index.php?pl=153&setdate=200509&PHPSESSID=9e3c821ab68e416dee40516eb426fe24


    Folksonomyis a neologism for a practice of collaborative categorization using freely chosen keywords. - from WIKIPEDIA(폭소노미자유롭게 선택된 키워드를 사용해 구성원이 함께 정보를 체계화하는 방식의미하는 신조어이다.)

     

    (Rojo에 사용된 Folksonomy)


    최근 Flickr나 Rojo 등에서 많이 사용되고 있는 폭소노미가 기존의 분류체계와 다른 점은 구성원들이 자발적으로 개별정보에 의미를 부여함으로써 단위정보를 체계화한다는 것이다.

    주요 구성원과 상호작용하면서 정보가 나열되기 때문에 보다 정확하게 의미있는 정보를 전달할 수 있는 장점을 지니고 있다.

    폭소노미에서 사용자가 정보에 의미를 부여하기 위해서 그 이면에 태깅(Tagging) 기술이 사용되고 있다. 태터의 global keyword와 비슷한 개념인 태그는 Flickr의 개별 사진이나 del.icio.us 의 즐겨찾기와 같이 하나하나의 원소에 복수개의 단어로 의미를 결합시키는 방식을 의미한다. 즉, 카트리나로 피해를 입은 건물 사진에 '카트리나', '재해' 등의 단어를 연결하는 것과 같다.

    이렇게 부여된 태그들에 가중치를 부여해서 위의 Rojo와 같이 정보를 체계화해서 보여줄 수 있다.

    최근 오픈한 싸이월드 미니링 서비스에서도 폭소노미가 사용되고 있고, 팀플에서도 폭소노미와 Ajax를 연동한 서비스가 오픈되었다.


    (팀플에 사용된 Folksonomy)


    물론 태깅이 사용되지 않고 팀플 참여도로 가중치를 부여했지만 폭소노미의 본래 의미에서 크게 벗어나지는 않는다고 생각된다.

    아마 앞으로는 정보를 표시할 때 사용자와 상호작용해서 정보의 중요성에 우선순위를 부여하는 폭소노미 방식이 폭넓게 사용될 것 같다. 이런 변화 하나하나가 Web2.0으로 가는 길목에서 우리가 새롭게 경험할 변화들이 아닐까 예상해본다.


      Comments,     Trackbacks
    <img src="http://blogimgs.naver.com/nblog/ico_scrap01.gif" class="i_scrap" width="50" height="15" alt="본문스크랩" /> 폭소노미
     

    새로운 웹 기술의 대표적인 상징 '폭소노미(Folksonomy)'에 대한 관심이

    점점 뜨거워지고 있다. 폭소노미란 웹페이지에 올라와 있는 정보나 관련

    주제를 고전적인 분류학(taxonomy) 기반인 '디렉토리'로 나누는 것이 아니라

    '꼬리표'(Tags. 또는 키워드)에 따라 구분하는 새로운 분류 체계를 말한다.

     

    예컨대 '청계천'이란 꼬리표가 붙은 정보는 '청계천'이란 본문 검색어와는 별개로

    관련 정보가 꼬리표 아래에 실시간으로 일목요연하게 모이는 구조다.

    꼬리표는 사람들이 직접 만들 수도 있고, 특정 알고리즘이나 인공지능 엔진이

    자동으로 생성할 수도 있다. 폭소노미란 합성어 역시 한글로 풀어쓰면

    '사람들에 의한 분류법'(Folk+order+nomos)이란 뜻이다.

    꼬리표가 붙으면 웹이 어떻게 달라질까.

    전통적인 디렉토리 분류는 주어진 틀에 맞춰져 있기 때문에 과거에 누적된

    자료를 재활용하기 쉽지 않다. 전문가들은 자료 검색을 '검색어'에만 의존하는

    원초적인 방식에서 벗어나 꼬리표로 재구성되는 과정이 필요하다고 지적한다.

     

    이 때문에 꼬리표는 웹 2.0이 추구하는 '네트워크 지향' 웹 형성에

    가장 기본적인 역할을 수행하게 된다.

     

    이하 중략...

     

    원문 기사 : [서명덕의 IT리뷰]"폭소노미" 네티즌 큰 관심- 세계일보

     

     

    IT 전문 기자 서명덕 기자가 쓴 기사를 아침에 본 후.

     

    뒤늦게 Amsterdam에서 진행된 Playing FLICKR 행사에 대해서 알게 되었다.

    참가자들이 자신을 몇 개의 메타데이터로 소개한다는 아이디어. 

     

    사용자 삽입 이미지

     

    더 많은 이미지는 여기로 -> Playing FLICKR 

    WEB 2.0 에 대한 가장 최신 자료는 여기로 ->What is Web 2.0 

     

    진리는 간단하다. 꼬리표가 되었든 WEB 2.O이 되었든 무엇이 되었든 사용자의

    필요에 의해(서만) 기술 혹은 네트웍은 새로이 개발되거나 구축된(되어야 한)다.

     

    WEB으로 인해 커뮤니케이션의 방식이 Person to Person에서 Person to Machine.

    이제 Machine to Machine(Software to Software)으로 진화되어 왔다는 사실.

    이제는 그 기술과 네트웍에 사람이 생명력을 불어 넣기 시작한다는 사실.

     

    폭소노미의 뜻이 '사람들에 의한 분류법'(Folk+order+nomos)이라 하지만.

    이건 사람이 쌓는 '노가다'와는 180도 다른 문제의식 이다.

     

    그런 의미에서 같은 링크 중심의 사고 임에도 불구하고

    한때 일던 Social Network 붐 때보다는 비교할 수 없을 만큼

    실용적이기에 혁신적인 변화를 가져올 수 있지 않나 생각한다.

     

    WEB이 혁명적(민주적)일 수 있는 단 한가지 이유는

    기술 종속적이면서도 가장 개방적인 커뮤니케이션 방식이기 때문이다.

     

    바로 가장 개방적이기 때문에 

    더 나은. 더 많은 커뮤니케이션을 하고 싶다는 욕망을 불러 일으키며

    그 욕망은 스스로 거대한 생명력을 갖고 기술의 진화를 이끈다.

     

     

      Comments,     Trackbacks
    [웹2.0] 리치 유저의 경험들
    [웹2.0] 리치 유저의 경험들
     

    연재순서

    1회.
    [웹2.0] 플랫폼으로서의 웹

    2회.[웹2.0] 집단 지능이 결집되다

    3회.[웹2.0] 데이터는 차세대의「인텔 인사이드」

    4회.[웹2.0] 소프트웨어 발표 주기의 종말

    5회.[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

    6회.[웹2.0] 단일 디바이스를 넘는 소프트웨어

    7회.[웹2.0] 리치 유저의 경험들

     

    페이 위의 비올라(Viola) 브라우저는 이미 1992년에는 웹을 이용하고 애플릿이나 그 외의 동적인 콘텐츠를 브라우저에 표시하고 있었다. 1995년에는 이런 애플릿을 전달하는 수단으로서 자바가 등장했다.

    게다가 클라이언트의 프로그래밍과 리치한 유저 경험을 실현하기 위한 가벼운 프로그래밍을 위해 우선은 자바 스크립트, 이어 DHTML가 등장했다. 매크로미디어는 몇년 전 플래시가 멀티미디어 콘텐츠 뿐 아니라, GUI 스타일의 애플리케이션 경험도 제공할 수 있는 것을 어필하기 위해서, ‘리치 인터넷 애플리케이션’이라는 말을 만들어 냈다(이 말은 오픈 소스의 플래시 클라이언트의 개발원이며, 매크로미디어와 경쟁하는 라스즐로 시스템(Laszlo Systems)도 이용하고 있다).

    그러나 웹에서 전면적인 애플리케이션을 제공할 수 있다고 하는 생각이 확산되기까지는 구글의 지메일과 구글 맵스의 등장이 큰 계기가 됐다. 이 두 가지 서비스는 웹 기반의 애플리케이션이지만 리치한 유저 인터페이스와 PC에 필적하는 양방향성을 갖추고 있다. 웹 디자인 회사인 어댑티브 패스(Adaptive Path)의 제시 제임스 가레트(Jesse James Garrett)는 그의 에세이에서 이런 애플리케이션을 개발하기 위해서 구글이 이용한 기술을 ‘AJAX’라고 명명했다.

    가레트는 “Ajax는 하나의 기술이 아니고, 복수가 뛰어난 기술을 새로운 강력한 방법으로 조합한 것”이라고 표현했다. Ajax에는 다음과 같은 것이 포함된다.

    • XHTML와 CSS를 이용한 표준에 준거한 프리젠테이션
    • DOM(Document Object Model)을 이용한 동적인 표시와 인터액션
    • XML와 XSLT를 이용한 데이터 교환과 데이터 조작
    • XMLHttpRequest를 이용한 비동기의 데이터 검색
    • 그 모든 것을 통합하는 자바 스크립트

    AJAX는 수많은 웹 2.0 애플리케이션, 예를 들어 플릭커(Flickr, 현재는 야후 그룹의 일부), 37 시그널의 베이스캠프와 백팩, 그리고 지메일, Orkut라고 하는 구글 애플리케이션에서도 중요한 역할을 한다. 지금 유저 인터페이스의 분야에서는 전대미문의 혁신이 시작되고 있다. 웹 개발자는 마침내 로컬의 PC 애플리케이션과 동등의 기능을 갖춘 리치한 웹 애플리케이션을 개발할 수 있게 될 것이다.

    흥미로운 것은 현재 개발이 진행되고 있는 기능의 상당수는 몇 년 전부터 아이디어로서는 존재했다는 점이다. 지금 간신히 실현되고 있는 이런 기능을 MS와 넷스케이프는 1990년대 말 벌써 구상하고 있었다. 그러나 양사는 표준을 둘러싸고 대립했기 때문에, 브라우저를 넘은 애플리케이션을 개발하는 것은 어려웠다. MS가 브라우저 전쟁에 결정적인 승리를 거두어 브라우저의 사실상 표준이 됐고, 이런 종류의 애플리케이션이 등장하는 여지가 생겼다.

    파이어폭스의 등장으로 브라우저 시장에 다시 경쟁이 시작됐지만, 적어도 현재는 1990년대에 진보의 족쇄가 된 것 같은 웹 표준을 둘러싼 파괴적인 경쟁은 일어나지 않고 있다.

    앞으로도 많은 웹 애플리케이션이 등장할 것이다. 그것은 아무도 본 적이 없는 애플리케이션으로, PC 애플리케이션에 필적하는 리치한 기능을 웹에서 실현할 것이다.

    전자 메일의 분야에서는 벌써 지메일이 흥미로운 혁신을 가져오고 있다. 지메일은 웹의 강점인 어디에서라도 액세스 할 수 있고 데이터베이스와의 제휴, 검색 기능 등이 가능한 유저 인터페이스를 조합하는 것으로, PC와 동등의 유용성을 실현하고 있다. 한편 PC 기반의 메일 클라이언트는 IM나 존재 기능을 추가해, 다른 방면에서의 사용의 편리를 추구하고 있다. 이메일, IM, 그리고 휴대 전화의 이점을 갖추어 VoIP를 이용하고, 웹 애플리케이션의 풍부한 기능에 한층 더 음성 기능을 탑재한, 통합 커뮤니케이션 클라이언트는 언제 등장하는 것일까. 개발 경쟁은 벌써 시작됐다.

    웹 2.0은 주소장을 재구성하고 있다. 웹 2.0 스타일의 주소장은 PC 또는 전화에 보존되고 있는 로컬의 주소장을 유저가 의식적으로 시스템에 기억시킨 연락처 정보의 단순한 캐시로서 취급한다. 이것에 대해서, 웹과 동기를 취하는 주소장, 즉 지메일 스타일의 주소장은 송수신된 모든 메시지, 모든 메일 주소, 이용된 모든 전화번호를 기억해 로컬 캐시에 대답이 발견되지 않는 경우는, 소셜 네트워킹의 수법을 사용하고 그 중에서 대체가 되는 선택사항을 찾아낸다. 거기에도 대답이 발견되지 않는 경우는 소셜 네트워크 전체를 검색한다.

    웹 2.0의 워드 프로세서에는 통상의 문서 편집 기능 뿐 아니라, 위키 스타일의 협업적인 편집 기능이나, PC용 워드 프로세서와 동등의 리치한 포맷 기능도 탑재될 것이다. Writely는 이런 애플리케이션이 좋은 예이지만, 아직 광범위하게 채용되지는 않고 있다.

    웹 2.0 혁명의 영향을 받는 것은 PC 애플리케이션만이 아니다. 세일즈포스닷컴(Salesforce.com)은 CRM과 같은 엔터프라이즈 규모의 애플리케이션에서도 웹을 이용하고, 소프트웨어를 서비스로서 제공할 수 있는 것을 증명하고 있다.

    신규 참가 기업이 경쟁 우위를 획득하기 위해서는 웹 2.0의 가능성을 충분히 살리는 것이 열쇠가 된다. 웹 2.0 시대에는 사용자로부터 배워 참가의 아키텍처를 사용하고, 소프트웨어 인터페이스 뿐 아니라, 공유 데이터의 충실도의 면에서도 경쟁사를 능가하는 애플리케이션을 구축할 수 있는 기업이 성공을 거두게 될 것이다.

    웹 2.0 기업의 핵심 역량
    7개의 원칙을 검토하면서 웹 2.0의 주된 특징을 분명히 했다. 각 항에서 다룬 사례는 이런 중요한 원칙들을 보여줬지만, 반드시 모든 원칙을 맞춘 것은 아니다. 마지막으로 우리가 웹 2.0 기업의 핵심 역량이라고 생각하고 있는 것을 살펴보자.

    • 패키지 소프트웨어가 아니고, 비용 효율이 높고, 확장성이 있는 서비스를 제공한다.
    • 독자성으로 인해 같은 것을 만드는 것이 어려운 데이터 소스를 컨트롤 한다. 이 데이터 소스는 이용자가 증가하는 만큼, 충실하지 않으면 안된다.
    • 유저를 신뢰해, 공동 개발자로서 여긴다.
    • 집합지를 이용한다.
    • 고객 셀프서비스를 통하고, 롱 테일을 수중에 넣는다.
    • 단일 디바이스의 테두리를 넘은 소프트웨어를 제공한다.
    • 경량인 유저 인터페이스, 경량인 개발 모델, 그리고 경량인 비즈니스 모델을 채용한다.

    웹 2.0을 수용하는 기업이 있다면, 그 기업이 상기의 항목을 채워 있는지 어떤지를 관찰해 보면 좋을 것이다. 들어맞는 것이 많은 만큼, 그 기업은 웹 2.0 기업이라고 부르기에 어울릴 것이다. @


    이 기사는 2005년 9월 30일에O'Reilly Network로 공개된 것이다.
     
     
      Comments,     Trackbacks
    [웹2.0] 단일 디바이스를 넘는 소프트웨어
    [웹2.0] 단일 디바이스를 넘는 소프트웨어
     
    웹 2.0에 주목해야할 특징의 하나는 “PC 플랫폼으로 한정되지 않는다”고 하는 것이다. MS의 베테랑 개발자였던 데이브 스투즈(Dave Stutz)는 MS를 떠날 때에 "향후 긴 세월에 흐르면, 실용성이 높고 단일 디바이스의 테두리를 넘은 소프트웨어가 큰 이익을 가져올 것”이라고 말했다.

    무엇보다 모든 웹 애플리케이션은 ‘단일 디바이스의 테두리를 넘은 소프트웨어’라고 부를 수 있다. 극히 단순한 웹 애플리케이션도 적어도 2대의 컴퓨터를 필요로 하기 때문이다. 하나는 웹 서버 역할을 하는 컴퓨터, 또 하나는 브라우저가 인스톨되는 컴퓨터다. 이미 설명한 대로 플랫폼으로서의 웹이 발전하면 복수의 컴퓨터가 제공하는 서비스를 완만하게 통합해 새로운 애플리케이션을 낳는 것이 가능하게 된다.

    그러나 웹 2.0은 단지 새로운 것을 만드는 것은 아니고, 웹 플랫폼의 가능성을 최대한으로만든다는 것을 의미한다.

    현재 이 원칙을 가장 잘 보여주는 것이 바로 아이튠즈다. 아이튠즈는 사용자가 휴대 단말을 사용하고, 웹의 방대한 정보로 액세스하는 것을 가능하게 했다. PC는 로컬 캐시나 컨트롤 스테이션으로서 기능한다. 웹의 정보를 휴대 단말에 전달하는 시도는 지금까지도 많이 행해져 왔지만, 아이팟과 아이튠즈의 편성은 복수의 기기로 이용되는 것을 전제로 설계된, 최초의 애플리케이션의 하나라고 할 수 있을 것이다. 티보(TiVo)도 그 좋은 예다.

    아이튠즈와 티보는 그 이외의 웹 2.0이 가지는 중요한 원칙도 입증하고 있다. 예를 들어, 아이튠즈와 티보는 웹 애플리케이션은 아니지만, 둘 다 웹 플랫폼의 힘을 이용하고 인프라와 일체화하고 있다. 여기에서는 데이터 관리가 극히 중요한 역할을 한다. 또 어느 쪽이나 서비스이며, 패키지 애플리케이션은 아니다. 다만 아이튠즈는 사용자의 로컬 데이터를 관리하기 위한 패키지 애플리케이션이라고 해도 이용할 수 있다.

    이 분야는 웹 2.0에서나, 새로운 플랫폼에 접속되는 기기가 증가하는 것에 따라, 큰 변화가 일어날 가능성이 높다고 생각된다. 전화나 자동차가 데이터를 받을 뿐만 아니라, 발신하게 되면 어떤 애플리케이션이 가능하게 될까. 실시간 트래픽 모니터링, 후랏슈모브(인터넷을 이용해 호소하는 집회), 시민 저널리즘 등은, 새로운 플랫폼의 가능성을 나타내는 최초의 징후에 지나지 않는다. @

    사용자 삽입 이미지
     웹 2.0의 디자인 패턴
    사용자 삽입 이미지
     
    사용자 삽입 이미지
    크리스토퍼 알렉산더는 저서 ‘패턴 랭귀지(A Pattern Language)’에서 건축에 관련되는 문제와 그 해법을 정리한 포맷을 정의했다. 알렉산더는 “각각의 패턴에는 어떤 환경하에서 반복해 일어나는 문제와 그 문제에 대한 해법의 핵이 기술되어 있다. 그렇게 해 같은 방식을 반복하는 일 없이 이 해법을 몇 번이라도 적용할 수 있다”라고 적고 있다. 이것을 웹 2.0에 적용한 것이 아래와 같은 8가지 패턴이다.

    1. 롱 테일
    인터넷의 과반수를 차지하고 있는 것은 소규모의 사이트다. 작은 니치가 인터넷으로 실현 가능한 애플리케이션의 대부분을 차지하고 있다. 따라서 유저 셀프서비스와 알고리즘에 의한 데이터 관리를 도입해, 웹 전체에 서비스를 제공하자.

    2. 데이터는 차세대의 인텔 인사이드
    데이터 지향의 애플리케이션이 증가하고 있다. 따라서 독자성이 높고, 같은 것을 만드는 것이 어려운 데이터 소스를 소유하는 것으로, 경쟁 우위를 획득하자.

    3. 유저에 의한 부가가치 창조
    경쟁력이 있는 인터넷 애플리케이션을 구축할 수 있을지는 기업이 제공하는 데이터에 유저가 어느 정도 데이터를 더할 수 있을까에 의해서 정해진다. 따라서 아키텍처를 소프트웨어 개발로 한정하는 것은 그만두자. 유저가 무의식 중에 또는 의식적으로 애플리케이션에 가치를 더할 수 있도록 하자.

    4. 네트워크 효과를 재촉하는 초기설정
    자신의 시간을 할애해서까지 기업의 애플리케이션 가치를 높여 주려는 유저는 적다. 따라서 유저가 애플리케이션을 사용하는 것에 의해서 부차적으로 유저의 데이터도 모이는 구조를 만들자.

    5. 일부 권리 보유
    지적 재산의 보호는 재이용을 제한해 실험적인 시도를 방해한다. 따라서 광범위하게 채용되는 것으로 메리트가 생기는 것은 이용을 제한하지 않고, 채용 장벽을 낮추자. 기존의 표준에 준거해, 제한 사항을 최소한으로 억제한 라이선스를 제공하자.

    6. 영구 베타판
    디바이스와 프로그램이 인터넷에 접속되고 있는 오늘날 애플리케이션은 물건이 아니라 간단히 제공되는 서비스이다. 따라서 새로운 기능은 릴리스라는 형태로 정리해 제공하는 것이 아니라, 통상의 유저 경험의 일부로서 일상적으로 제공해 나가자. 서비스를 제공할 때는 유저를 실시간 테스터라고 생각하고 신기능이 어떻게 사용되고 있는지를 관찰하자.

    7. 컨트롤이 아니라 협력
    웹 2.0 애플리케이션은 복수의 데이터 서비스의 협동 네트워크에 의해서 실현된다. 따라서 웹 서비스의 인터페이스를 통해 콘텐츠를 전달해, 다른 사람의 데이터 서비스를 재이용하자. 경량인 프로그래밍 모델을 채용해 시스템을 완만하게 통합할 수 있도록 하자.

    8. 단일 디바이스의 테두리를 넘은 소프트웨어
    인터넷 애플리케이션에 액세스할 수 있는 디바이스는 PC만이 아니다. 특정의 디바이스로 밖에 이용할 수 없는 애플리케이션은 디바이스의 테두리를 넘어 이용할 수 있는 애플리케이션보다 가치가 없다. 따라서 애플리케이션을 설계할 때는 처음부터 휴대 단말, PC, 인터넷 서버 등을 포괄한 시각을 갖고 통합적인 서비스를 제공하자.

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

    이 기사는 2005년 9월 30일에O'Reilly Network로 공개된 것이다.
     
     
      Comments,     Trackbacks
    [웹2.0] 가벼운(Lightweight) 프로그래밍 모델

    [웹2.0] 가벼운(Lightweight) 프로그래밍 모델

     

    연재순서

    1회.
    [웹2.0] 플랫폼으로서의 웹

    2회.[웹2.0] 집단 지능이 결집되다

    3회.[웹2.0] 데이터는 차세대의「인텔 인사이드」

    4회.[웹2.0] 소프트웨어 발표 주기의 종말

    5회.[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

    6회.[웹2.0] 단일 디바이스를 넘는 소프트웨어

    7회.[웹2.0] 리치 유저의 경험들

     

     

    ‘웹 서비스’가 최신 기술로 각광 받을 때 대기업은 먼저 복잡한 웹 서비스 스택을 구축해, 분산 애플리케이션을 실현하기 위한 안정된 프로그래밍 환경을 제공하려고 했다.

    그러나 웹이 하이퍼 텍스트(hyper text) 이론의 많은 부분을 무시하고 단순한 실용주의를 존중했기 때문에 성공한 것처럼 RSS는 그 단순함에 때문에 어쩌면 가장 광범위하게 배포된 웹 서비스가 되었다. 이에 비해 기업이 구축한 복잡한 웹 서비스 스택은 아직 한정적으로 이용되고 있다.

    비슷하게 아마존의 웹 서비스도 2가지 방법으로 제공되고 있다. 하나는 SOAP(Simple Object Access Protocol)를 채용한 엄밀한 구성을 가지는 웹 서비스 스택, 또 하나는 HTTP 경유로 HTML 데이터를 제공하는 단순하고 가벼운 접근이다. 후자의 방법은 REST(Representational State Transfer)이라고 한다. 아마존과 ToysRUs등의 소매 파트너를 묶는 복잡한 B2B 연결에는 SOAP 스택이 이용되고 있다. 하지만 아마존 웹 서비스의 95%는 단순한 REST 인터페이스를 통해 이용되고 있다고 한다.

    단순함을 추구하는 경향은 그 외의 ‘유기적인’ 웹 서비스에서도 보여진다. 최근 발표된 구글맵이 적절한 예다. 구글맵은 AJAX(Javascript와 XML)를 이용한 단순한 인터페이스를 채용하고 있기 때문에 해커들은 곧 바로 그것을 해독하고 데이터와 혼합해 새로운 서비스를 만들어냈다.

    지도 관련의 웹 서비스는 이미 맵퀘스트(MapQuest), MS의 맵포인트(MapPoint), 그리고 ESRI등의 GIS 벤더로부터도 제공되고 있었다. 그런데 구글맵이 열광적인 인기를 누리고 있는 것은 이것이 매우 단순한 서비스이기 때문이다. 벤더가 제공하는 웹 서비스를 이용하고 새로운 시도를 하기 위해서는 그 벤더와 정식 계약을 맺어야 하는데 비해 구글맵은 유저가 데이터를 자유롭게 이용할 수 있도록 했다. 이 때문에 해커들은 구글맵의 데이터를 재이용하고, 곧바로 창조적인 시도를 실시할 수 있었다. 이 사례는, 다음과 같은 중요한 교훈을 나타내고 있다.

    1. 가벼운 프로그래밍 모델을 채용해, 시스템을 완만하게 통합할 수 있도록 한다.
    기업이 제공하는 복잡한 웹 서비스 스택은 시스템을 견고하게 묶도록 설계되었다. 이러한 방법이 요구되는 것도 많지만 흥미로운 애플리케이션의 상당수는 시스템을 완만하게 통합하는 것만으로도 실현될 수 있다. 2.0의 사고 방식은 전통적인 IT 사고 방식과는 완전히 다르다!

    2. 조정(coordination)보다는 신디케이션(syndication)한다.
    RSS나 REST 서비스와 같이 단순한 웹 서비스는 내부의 데이터와 외부의 데이터의 전달에 충실해 외부에서 데이터가 어떻게 이용될지에 대해서는 통제하지 않는다. 엔드투엔드(end-to-end)의 원칙으로서 알려진 이 아이디어는 인터넷 그 자체의 기본 원칙이기도 하다.

    3. 개조(hackability)와 재조합(remixability)이 가능하도록 설계한다.
    오리지널 웹, RSS, AJAX와 같은 시스템은 모두 재사용의 장벽이 극히 낮다는 공통점이 있다. 실제로 유익한 소프트웨어의 상당수는 오픈 소스이며, 그렇지 않은 경우도 지적 재산 보호를 목적으로 한 장벽은 거의 설치되지 않았다. 웹 브라우저의 ‘소스 보기’ 기능을 사용하면, 누구라도 다른 유저의 웹페이지를 카피할 수 있다. RSS는 정보 제공자가 아닌 유저가 자신이 갖고 싶은 정보를 원할 때 볼 수 있도록 고안되었다. 가장 성공한 웹 서비스는 개발자가 상상도 하지 않았던 방향으로 서비스를 용이하게 전환할 수 있는 것들이었다. ‘모든 권리의 인정(all rights reserved)’이 아닌 Creative Commons가 제안해 널리 보급된 ‘일부 권리 인정(some rights reserved)’ 문구가 이 원칙을 실천하는데 있어서의 유익한 지침이 될 것이다.

    어셈블리에서의 혁신(innovation in assembly)
    가벼운 비즈니스 모델에는 가벼운 프로그래밍과 가벼운 연결이 수반되기 마련이다. 웹 2.0의 사고 방식은 재상용에 있다. 예를 들어 housingmaps.com와 같은 새로운 서비스는 단지 기존의 서비스를 조합하는 것으로 실현된 것이다. Housingmaps.com는 아직 비즈니스 모델을 가지고 있지 않지만, 구글 애드센스(또는 아마존 광고 제휴)처럼 이 서비스에 맞는 수익 모델을 갖게 될 것이다.

    이러한 사례는 웹 2.0의 또 하나의 중요한 원칙인 ‘어셈블리에서의 혁신(innovation in assembly)’를 이해하는데 도움이 될 것이다. 유용한 컴포넌트가 대량으로 존재할 때는 이러한 컴포넌트를 새로운 방법, 또는 효과적인 방법으로 조합하는 것으로 새로운 가치를 창출할 수 있다. PC혁명은 하드웨어 결합의 혁신을 가능하게 했다. 델은 조립 사업으로 제품 개발에 혁신이 필요한 비즈니스 모델을 가지는 기업들을 물리쳤다. 마찬가지로 웹 2.0은 타사의 서비스를 이용해 그것을 통합하는 것으로 경쟁자를 물리칠 기회를 기업에 제공한다.

    사용자 삽입 이미지
    웹 2.0 투자 이론
    사용자 삽입 이미지
     
    사용자 삽입 이미지
    벤처 자본가인 폴 케드로스키(Kedrosky)는 “중요한 것은 자신이 세상의 공통 인식에 위화감을 가지고 있는 부분에서 실행 가능한 투자를 찾아내는 것이다”라고 썼다. 웹 2.0을 실천하고 있는 기업이 다양한 측면에서 세상의 공통 인식에 반한 전략을 취하고 있다는 것은 흥미로운 일이다. 예를 들어, 누구나가 데이터 보호를 중요시 할 때 플릭커(Flickr)와 냅스터(Napster)는 데이터를 공개하는 것을 선택했다. 이러한 사이트는 단지 기존의 개념에 반대하고 있는 것은 아니다(예를 들어, 버블적인 비즈니스 모델의 비판 등). 세상의 공통 인식과 스스로의 인식의 어긋나는 것에서부터 새로운 것을 만들어 낸 것이다. 그것은 플릭커의 경우는 커뮤니티이며, 냅스터의 경우는 방대한 음악 콜렉션이다.

    이를 바라보는 또 방법은 성공한 기업들은 거액의 투자가 필요한 것들을 포기했을 뿐만 아니라 고가의 가치 있는 것들을 무료로 가질 수 있는 것에 비판적이었다는 사실이다. 예를 들어 위키피디어( Wikipedia)는 신속성과 폭넓은 확대를 위해 편집 제어권을 단념했다. 냅스터는 업체가 판매하는 모든 음악을 담은 ‘카탈로그’를 포기한 대신 광범위한 네트워크를 얻었다. 아마존은 실제 상점을 포기하자 전세계에 책을 판매할 수 있게 되었다. 구글은 대기업을 고객으로 하는 것을 단념한 대신, 나머지 80%의 중소기업을 얻었다. 이는 적의 힘을 이용해 적을 넘어뜨리는 합기도(aikido)와 유사하다. “전세계에 있는 누구나 이 글을 업데이트할 수 있다. 일부의 사람에게 있어서는 이것은 매우 귀찮은 일일 것이다”(냇 토킹톤)
    사용자 삽입 이미지
    사용자 삽입 이미지

    이 기사는 2005년 9월 30일에 O'Reilly Network로 공개된 것이다.
     
     
      Comments,     Trackbacks
    [웹2.0] 소프트웨어 발표 주기의 종말

    [웹2.0] 소프트웨어 발표 주기의 종말

     

    연재순서

    1회.
    [웹2.0] 플랫폼으로서의 웹

    2회.[웹2.0] 집단 지능이 결집되다

    3회.[웹2.0] 데이터는 차세대의「인텔 인사이드」

    4회.[웹2.0] 소프트웨어 발표 주기의 종말

    5회.[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

    6회.[웹2.0] 단일 디바이스를 넘는 소프트웨어

    7회.[웹2.0] 리치 유저의 경험들

     

    ‘구글 대 넷스케이프’ 논의에서 언급했던 대로 인터넷 시대 소프트웨어의 중요한 특징 중의 하나는 그것이 물건이 아니라 서비스로서 제공된다는 점이다. 이 사실은 기업의 비즈니스 모델에 근본적인 변화를 일으키고 있다.


    오퍼레이션은 그 자체가 핵심 경쟁력이 된다


    구글이나 야후의 제품 개발 능력은 각 사의 오퍼레이션(Operation) 능력에 비례한다. 물건으로서의 소프트웨어와 서비스로서의 소프트웨어는 완전히 다르다. 서비스로 제공되는 소프트웨어는 일일 단위로 유지보수 되지 않으면 올바르게 기능하지 않는다. 구글은 서비스를 올바르게 유지하기 위해 끊임 없이 웹을 돌아다니면서 인덱스를 업데이트한다. 또한 검색 결과에 악영향을 미치는 링크 스팸을 비롯한 모든 시도를 걸러내야 하며, 수억 건의 검색 행위에 쉼 없이 응답해야 한다. 더욱이 문맥에 맞는 광고까지 찾아내야 한다.

    구글은 시스템 관리, 네트워크, 로드 밸런싱에 관한 기술을 어쩌면 검색 알고리즘 그 자체보다 더 중요하게 다루고 있다. 경쟁사와 비교해 구글이 가격 우위의 입장에 서 있는 것은 이러한 프로세스 자동화에 성공했기 때문이다.

    웹 2.0 기업에서는 펄, 파이썬, PHP, 그리고 최근에는 루비(Ruby)라는 스크립트 언어가 매우 큰 역할을 하고 있다. 여기에는 그만한 이유가 있다. 잘 알려져 있는 대로 썬의 첫 번째 웹 마스터였던 하산 슈뢰더(Hassan Schroeder)는 펄을 ‘인터넷의 덕 테이프(duct tape)-어느 가정에나 하나씩 있는 점착 테이프’라고 불렀다. 소프트웨어가 물건이었던 시대의 기술자들에게 스크립트 언어로 불려 업신여겨졌던 동적인 언어는 지금은 시스템 관리 책임자, 네트워크 관리자, 그리고 끊임없는 변경을 필요로 하는 동적인 시스템을 구축하고 있는 애플리케이션 개발자로부터도 지지를 받고 있다.

    오픈 소스의 개발 관행에 따라 사용자를 공동 개발자로 취급해야 한다(오픈 소스 라이선스에 근거해 릴리스 될 가능성이 낮은 소프트웨어도 마찬가지이다)

    “빨리 출시하고 자주 출시한다’라는 오픈 소스의 격언은 ‘영원한 베타 버전’을 의미한다. 게다가 진보적인 개념으로 모습을 바꾸었다. 소프트웨어는 개방적인 환경에서 개발되어 월간, 주간, 심지어 일일 단위로 새로운 기능이 추가된다. G메일, 구글 맵, 플릭커(Flickr), 델리셔스(del.icio.us)라는 서비스의 로고가 몇 년간이나 ‘베타’ 로고를 갖고 있는 것은 놀랄만한 일이 아니다.

    따라서 유저의 행동을 실시간 감시해 어떤 신기능이 어떻게 이용되고 있는지를 관찰하는 일도 웹 2.0 기업의 중요한 핵심 경쟁력이 될 것이다. 대규모 온라인 서비스의 한 웹 개발자는 다음과 같이 말하고 있다. “우리는 매일 2~3가지의 새로운 기능을 사이트 어딘가에 추가하고 있다. 유저가 사용하지 않으면 그 기능은 삭제되고, 유저의 반응이 좋으면 그 기능을 사이트 전체로 확대한다”

    최근 플릭커의 수석 개발자인 칼 헨더슨(Cal Henderson)은 플릭커가 30분 마다 새로운 빌드를 인스톨하고 있다고 밝혔다. 이것은 기존과는 완전히 다른 개발 모델이다. 모든 웹 애플리케이션이 플릭커와 같이 극단적인 방법으로 개발되고 있는 것은 아니지만 대부분의 웹 애플리케이션은 PC 시대나 클라이언트 서버 시대와는 완전히 다른 개발 주기를 갖고 있다. 얼마 전에 ‘MS는 구글을 이길 수 없다”라는 기사가 ZDNet에 게재된 바 있다. 그 이유는 바로 이것이다. “MS 의 비즈니스 모델은 모든 유저가 2~3년마다 컴퓨팅 환경을 업그레이드 하는 것을 전제로 하고 있다. 그에 비해 구글의 비즈니스 모델은 모든 유저가 매일 자신의 컴퓨팅 환경을 사용하고, 새로운 정보를 찾는 것을 전제로 하고 있다”

    그동안 MS는 경쟁 상대에게서 배워 결과적으로 경쟁에서 최고가 되었다는 것을 증명해왔으며, 여기에는 의문의 여지가 없다. 하지만 이번 경쟁에 이기기 위해서 MS(나아가서는 기존의 모든 소프트웨어 기업)는 지금까지와는 본질적으로 다른 기업이 될 필요가 있다. 한편 순수한 웹 2.0 기업은 벗어 던져야 할 낡은 패턴(그리고 그에 상응하는 비즈니스 모델과 수익원)을 가지지 않기 때문에 기존의 기업보다 유리한 출발선상에 서있다. @

    이 기사는 2005년 9월 30일에 O'Reilly Network로 공개된 것이다.

     

     

    저자 :Tim O'Reilly   2006/01/10
     
    사용자 삽입 이미지
     
     
      Comments,     Trackbacks