한빛출판네트워크

제공 : 한빛 네트워크
저자 : Bill Lubanovic
역자 : 유일호
원문 : Migrating Web-Based PHP Applications to Ajax

웹 개발은 난잡하다. 지난 수년 동안, 우리가 가진 도구들은 이상한 것들로 가득 채워졌고, 사용하기도 어려울 뿐만 아니라 서로 잘 어울리지도 않는다. 웹 코드(code)는 유산 문제가(legacy problem) 되었다. 전형적인 웹 페이지의 형태는 HTML, JavaScript, 그리고 서버측 스크립트(server-side scripts)가 서로 얽힌 것이다. 사용자 인터페이스 로직(logic)은 비즈니스 룰과 클라이언트-서버 통신으로 뒤섞여 있다. 대부분의 프로그래밍 환경에서는, 우리는 문서화된 API를 사용하기 때문에 우리는 그저 인자를 함수에 넘겨주고 그 결과값을 돌려받으면 된다. 웹 개발 환경에서는, 일반적으로 폼 안에 히든(hidden) 필드를 만들고, 조그만 변화가 있을 때 조차도 전체 페이지를 재생성 하는 것과 같은 잡다한 기술이 요구된다. 그러한 과정을 좀더 합리적으로 만들 수 있을까?

이 기사는 데이터베이스에 기반한 전형적인 웹을 개선하는 것에 대해 설명한다. 우리는 약간의 오래된(old) 코드를 볼 것이고, – HTML ,JavaScript, 그리고 PHP가 뒤섞인 – Ajax와 같은 최근의 웹 기술과, jQuery와 같은 최근의 도구들로 재구성할 것이다. 다음과 같은 이득이 생길 것이다:

• 정적인 내용으로부터 동적인 내용을 분리한다.
• 내용과 스타일, 그리고 처리 부분을 분리한다.
• 함수 호출을 통한 클라이언트-서버 통신.
• 단순 무식한 페이지 리로드(reloads)대신에 부분적인 페이지 업데이트
• 빠른 개발 과 유지하기 쉬운 코드
• 빠른 로드 타임과 향상된 캐슁(caching)

오래되고 빛 바랜 웹

시작은 HTML이었고, 이윽고 폼(form)이나, 클라이언트측(client-side) JavaScript, 그리고 서버측(server-side) CGI 스크립트와 같은 것들이 뒤를 이었다. 폼(form) 값들을 채우고 CGI스크립트로 전송하거나 자바스크립트 안에서 GET 방식의 URL을 만들 수 있었다. JavaScript는 디버그 하기가 어려웠다. window 와 같이 중요한 값은 언어의 일부분이 아니었고 마이크로소프트와 네스케이프와의 브라우저 전쟁은 계속해서 우리를 괴롭히는 불필요한 차이점들을 만들어 냈다. 시간이 지날수록 상황은 조금씩 좋아졌으며, W3C는 DOM 을 정의하였고, 개발자들은 크로스 플랫폼 DHTML 라이브러리를 만들어 냈다.

어떤 동적인 페이지들은 만들기가 쉽다. 단지 데이터베이스에 쿼리를 날리고, HTML로 정리해서 보기 좋게 보여주면 된다. 하지만 대부분은 쉬운 것 보다 어려운 것이 더 많다. 데이터베이스 값들을 풀다운(pull-down) 메뉴와(HTML select 와 option 태그를 이용해서) 선택할 수 있게 해주는 것들에(radio 와 checkbox 태그) 집어넣는다. 어떤 폼들은 여러 페이지들을 다루고, 전체적인 상태를 유지하기 위한 로직(logic)은 점점 꼬여간다. 모든 폼 서브미션(submission)은 전체적으로 새로 만들어진 페이지를 리턴 하며, 이전 서브미션(submission)의 모든 상태를 유지한다. 어떻게 애플리케이션을 구성해야 하는지에 대한 전통적인 방법들이다.:

• 모든 것을 스크립트 하나에 구현한다. 첫 번째 동작으로 데이터베이스에 쿼리를 날리고 HTML과 폼 엘리먼트들을 생성한다. 다음 동작으로 폼은 명령(add, change 나 delete)과 인자들을 넘긴다(예를 들면 사람의 ID, 만약에 change 나 delete 라면). 스크립트는 데이터베이스를 수정하고 페이지의 내용을 새로 고친다. 폼 엘리먼트들은 반드시 바뀐 데이터베이스의 내용을 반영해야 한다.
• 두 개의 스크립트를 사용한다. 첫 번째는 데이터베이스로 쿼리를 날리고 HTML을 생성하며 이전 예와는 달리 두 가지 차이점이 있다.
  • 폼은 동적인 내용을 보여 주기 위해 아이프레임(iframe)을 가진다.
  • 폼의 action 은 두 번째 스크립트가 지정된다
  • 폼의 target 은 iframe의 이름이 지정된다.
  폼이 생성되고, 엘리먼트들은 폼을 서브미션(submission) 하더라도 그 값들을 유지한다. 두 번째 스크립트의 결과물은 아이프레임(iframe)에 보여진다.

두 번째 옵션이 좋아 보이지만 여전히 문제가 있다: action이 페이지 안의 폼 엘리먼트의 data를 바꾸면 전체페이지는 다시 만들어 져야 할 필요가 있다. 우리는 세 번째 옵션이 필요하다.

새로운 도구들

공통적인 제약 조건은 전체 페이지 디자인이다. 무엇을 하든, 변화가 있든 없든, 서버로 서브밋(submit) 하고, 새롭게 만들어진 페이지를 돌려 받아야 한다(아이프레임(iframe)은 작은 페이지와 같고, 그 크기는 변형될 수 없다.). 여러 가지 JavaScript 원격 기술들이 웹 클라이언트-서버 커넥션을 좀더 프로시져 호출과 같이 동작할 수 있도록 만들기 위해 시도 되었다. 내가 생각 하기에 가장 유용하게 기여하는 것들은:

• innerHTML
• XMLHttpRequest
• Ajax
• JSON
• 새로운 JavaScript 라이브러리들

innerHTML

이 DOM 어트리뷰트는 마이크로 소프트의 IE4에서 소개되었으며, 현존하는(W3C는 공식적으로 정의하진 않지만) 요즘 브라우저들은 기본적으로 이것을 지원한다. 이것으로, 리프레쉬(refresh) 없이(without refresh) HTML 시작태그와 종료태그 사이의 내용을 구하거나, 집어넣을 수가 있다. 이런 HTML이 있다면:

Now you see it.

다음과 같은 JavaScript로 내용을 바꿀 수 있다:

var obj = document.getElementById("changeme");
obj.innerHTML = "Now you don"t";

이런 결과를 만들어 낸다:

Now you don"t

비록 DOM이 페이지 엘리먼트를 동적으로 바꾸는 함수를 가지고 있지만, innerHTML은 더 간단하고 더 빠르다. 불행히도, innerHTML은 IE의 많은 테이블(table) 엘리먼트들에 대해 읽기전용 어트리뷰트이므로, 그것에 대한 대안들을 사용 해야 한다.

XMLHttpRequest

이 API는 클라이언트 요청을 서버로 보내고 서버로부터 응답을 받는다. 마이크로 소프트는 Outlook Web Access 을 좀더 데스크톱 애플리케이션처럼 동작하도록 만들기 위해 이것을 고안해 냈다. 이것은 IE5을 포함해서 요즘의 모든 브라우저들이 이 API를 포함한다. innerHTML 과 함께 사용하면, 서버측 스크립트를 호출할 수 있고 반환된 데이터를 페이지상의 어떤 엘리먼트에 업데이트 할 수 있다. JavaScript의 한 부분 임에도 불구하고, 이 함수는 평면적으론 몇 년 동안 숨겨져 있었다(JavaScript나 DHTML 책에서도 찾을 수가 없었을 것이다.). Google Mail, Maps와 Suggest가 그것의 응답성을 입증했을 때 모든 것이 바뀌었고, 새로운 웹 애플리케이션 모델로 소개되었다.

Ajax

Jesse James Garrett이 XMLHttpRequest 과 DOM, 그리고 다른 테크닉들을 포함하는 Ajax (Asynchronous JavaScript and XML)라고 명명된 새로운 모델을 소개한 2005년에 터질 것이 터졌다. 그것의 타이밍은 완벽했다. 웹 개발에 활력을 넘치게 했고, JavaScript의 명예를 되찾았다.

JSON

오래된 원격 프레임웍들은 클라이언트와 서버간에 데이터를 주고 받기 위해 여러 가지 포맷을 사용했고, XMLHttpRequest 는 이름이 말해주듯이 XML을 사용했다. Doug Crockford 는 가볍고 간단한 JSON (JavaScript Object Notation) 포맷을 디자인했다. JSON을 JavaScript 데이터 구조로 파싱 하는 것은 하찮을 정도로 쉽다.(그저 eval(json_string) 에 불과하다), 그리고 XML을 분석하는 것(deconstructing)보다 훨씬 빠르다.

JavaScript libraries

새로운 모델의 웹 개발을 단순하게 하고 고질적인 크로스 브라우저 이슈들의 돌파구를 만들기 위해서 고수준의 JavaScript 라이브러리들이 개발되었다. 나는 여러가지 이유로 Prototype, Dojo, 또는 YUI 와 같이 뛰어난 경쟁자들을 대신에 John Resig의 jQuery 를 선택했다.

• 작다: 압축시 약 19kB 정도이다
• 연계성: 호출들은 좀더 작은 코드로 연계될 수 있다.
• 지원: 좋은 문서와 개발 커뮤니티가 있다.
• 유연성: 셀렉터 구문은 페이지 엘리먼트들을 선택하기 위한 CSS 1-3과 XPath 문구들을 포함 한다.
• 아키텍쳐: 애드온과 플러그인들을 통해 쉽게 확장할 수 있다.

---

역자 유일호님은 현재 어느 중소기업의 소프트웨어 엔지니어로 근무하고 있으며, 잡다한 스킬덕에 여러 가지 개발관련 일을 맡아서 하고 있습니다. 이 기사를 번역하는 시점에는 Ajax를 이용한 프로젝트를 맡아서 진행하고 있습니다.