박종명의 아름다운 개발 since 2010.06

멀티미디어 지원
HTML 5 를 지원하는 브라우저는 비디오, 오디오와 같은 멀티미디어 형식을 자체적으로 지원한다
HTML 5 는 이러한 멀티미디어 파일을 웹 페이지에 삽입할 수 있는 태그를 정의하고 있으며 
재생과 관련한 각종 제어를 수행할 수 있는 스크립트 API가 제공된다
 
이전의 브라우저 환경
HTML 5가 등장하기 전, 브라우저 환경에서는 멀티미디어 재생을 자체적으로 할 수 없었다
대신 외부 기술, 즉 브라우저에 별도로 설치되는 플러그인(Plug in)의 힘을 빌어 멀티미디어를 표현할 수 있었다. 멀티미디어 재생을 위한 플로그인 기술로는 다음과 같은 것들이 있다
- 윈도우 미디어 플레이어
- 어도비 플래시 플레이어
- 애플 퀵타임 플레이어
- 마이크로소프트 실버라이트

이러한 플러그인이 브라우저에 따로 설치되어야만 멀티미디어 재생이 가능하였으며 이는 곧 표준과는 거리가 먼 개념이 되어 버렸다

웹 응용환경의 일관되고 표준적인 플랫폼을 지향하는 HTML5가 멀티미디어 재생을 위한 스펙이 마련된 것은 어찌보면 당연한 순리라 하겠다. 그 만큼 현재의 웹은 멀티미디어를 빼고 논할 수는 없는 것이다


브라우저 지원 현황
다른 HTML5 스펙과는 달리 비디오,오디오는 브라우저 별로 지원되는 코덱이 상이하다
즉 HTML 5 의 멀티미디어 구현은 지원하더라도 각기 다른 코덱을 지원하는 것이다
Video, Audio 스펙은 표준으로 정해졌지만 코덱은 아직 표준으로 정해진 것이 없기 때문이다

따라서 브라우저가 Video,Audio 를 지원하다고 해도 어떤 코덱을 지원하는 것인지 추가 확인이 필요하다. 우선 Video,Audio 를 지원하는 브라우저 현황을 살펴보자

Video, Audio 지원 현황
- Video 지원 현황

이제 브라우저별로 각기 달리 지원되는 코덱에 대해 살펴보자

코덱 지원 현황
멀티미디어 형식에 대한 표준이 HTML5 사양에는 포함되지 않았다.
따라서 멀티미디어 재생을 위한 코덱의 비 표준화로 현재 브라우저 마다 동영상 재생 형식이 서로 다르다비디오 코덱으로는 H.264와 Theora 가 있으며 오디오 코덱으로는 AAC,MP3 와 Vorbis 형식이 HTML5 용으로 사용되고 있다

모질라와 오페라는 라이선스가 없는 오픈 소스 Theora를 선호하며 애플과 구글은 H.264 코덱을 선호한다. 또한 마이크로소프트의 IE.9 에서는 H.264코덱만 지원한다고 발표한 바 있다

오디오 코덱 역시 라이선스가 없는 Vorbis형식과 특허로 제한되어 있는 MP3, ACC 형식으로 이분화 되어 있다. 그리고 또 하나의 변수로 최근 구글이 동영상 코덱 개발사인 On2를 인수해 VP8 코덱을 오픈 하기로 하였다. 이에 모질라 및 오페라 등이 동참하기로 하였지만 애플의 참여는 알 수 없는 상황이다.

따라서 표준이 정립되기 전까지는 두 형식에 대한 브라우저 호환성을 유지해야 하는 부담이 있다
아래 표는 브라우저 별 지원되는 비디오/오디오 코덱 정보이다

위 코드를 MS IE 8.0 이하 버전에서 실행해 보면 대체 텍스트가 표시될 것이다
 

Video & Audio 제어하기
HTML5 에는 비디오, 오디오의 재생과 관련한 다양한 스크립트 API를 정의하고 있다

재생과 관련된 제어라 함은 시작, 중지, 일시정지, 재생위치파악, 재생길이, 재생속도, 볼륨크기, 음소거 등이 있으며 재생 간 발생하는 각종 이벤트 처리를 일컫는다

스크립트 API를 통해 제어를 하기 위해서는 Video(Audio)의 DOM 객체를 대상으로 수행하면 된다

Video, Audio 를 위한 다양하고 많은 속성과 함수 그리고 이벤트들이 제공된다
다음이 url에서 멀티미디어 관련 API 들을 확인해 보기 바란다

브라우저에 데이타베이스?
HTML5 의 로컬 저장소는 이전에 알아본 Web Storage 이외에도 관계형 데이타베이스가 추가로
제공된다. 일명 Web SQL Database 가 그것이다
(Web SQL Database 를 지원하는 브라우저는 자체적으로 경량의 관계형 DB를 내장하고 있다)

Web Storage 의 경우 비교적 적은양의 간단한 데이터를 저장하기에 적합한 로컬 저장소인 반면
Web SQL Database 는 보다 구조적이고 체계화된 관계형 데이터를 대랑으로 저장하기에 적합하다
이것은 마치 파일이라는 저장소와 MS SQL 이나 Oracle 과 같은 관계형 데이타베이스의 차이라 하겠다

물론 Web SQL Database가 Oracle 와 같이 서버급, 대용량 DBMS의 면모를 모두 갖추지는 않았지만,
안정적이고 경량의 관계형 자료구조를 지원하고 표준 SQL 질의를 통해 데이터를 보다 유연하게 다룰 수 있다는 점과 클라이언트(브라우저)에 직접 내장되어 있다는 점에서 매우 유용한 기능이라 할 수 있다

Web SQL Database 는 아이폰과 같은 모바일 환경에 많이 채용된 경량의 무료 DB엔진인 SQLite를
기반으로 하고 있다


브라우저 지원 현황
아래 표는 http://caniuse.com/ 에서 제공하는 브라우저(버전)별 Web SQL Database 지원 표이다
(데스크탑 용 브라우저 기준이다)

Indexed Database
Indexed Database는 새로 등장한 또다른 로컬 저장소 스펙이다
2009년 말까지 사양 책정이 진행중이던 Web SQL Database 의 대안으로 탄생했다
즉 현재 Web SQL Database 는 사양 책정이 중지된 상태이며, IndexedDB 라는 새로운 스펙이
대안으로 떠오르고 있는 것이다

Indexed Database 는 자바스크립트 객체 단위의 데이터 저장이 용이하고 그 객체를 대상으로
인덱스를 걸 수 있어 간단한 구현과 효율적인 검색을 수행할 수 있다

관계형 데이타베이스의 경우 저장되는 데이터의 스키마의 유연성이 떨어질 수 있고 SQL 이라는 별도의 독립된 언어를 기반으로 하기 때문에 브라우저간 표준화및 호환성에 문제될 소지가 있다
(MS SQL과 오라클이 자체 비표준 SQL을 지원하는 것처럼 변형된 SQL이 발생할 수 있다는 것이다)

반면 Indexed Database 는 SQL 언어와는 무관하며 단순한 저장구조(Key-Value Storage)를 갖추고 있으며 간단한 자바스크립트 API 만으로도 데이터베이스 조작이 가능하여 보다 브라우저 친화적이고 표준화 작업을 쉽게 이끌 수 있다는 장점이 있다

결국 고가용성 환경이 아닌, 모바일 환경에서의 가벼운 로컬DB 컨셉은 관계형DB보다는
Indexed Database와 같은 객체기반의 비관계형 DB가 더 어울린다고 할 수 있겠다

앞서 파이어폭스와 IE9 브라우저가 Web SQL Database 를 지원하지 않는다고 하였는데,
그 이유가 바로 이들 브라우저에서는 Indexed Database 를 지원하는 것으로 방향을 잡았기 때문이다


데모 만들어 보기
Indexed Database 가 Web SQL Database 의 대안으로 그 사양 책정이 진행중이지만
Web SQL Database 역시 아직은 유효하고 효과적인 로컬 DB 이다

아이폰 및 데스크탑의 사파리 및 크롬에서 이를 지원하고 있기 때문에 무용지물은 아니다
간단한 데모를 만들어 봄으로써 사용법을 숙지하도록 하자

아래와 같이 코드를 작성하는 간략히 설명하자면,
myDB 라는 데이타베이스를 생성(오픈)하고 Test 라는 테이블을 만든다
Test 테이블에 id,name 이라는 두개의 컬럼을 가지도록 한다
이후 Test 테이블에 값을 저장하고 전체를 조회하는 데모이다

데모 실행 화면
구글 크롬 브라우저에서 데모를 실행한 모습이다
개발자 도구를 통해 로컬 DB의 정보를 확인 할 수 있다

인터넷 연결 없이 웹 사이트를 사용한다?
인터넷에 연결이 되어 있지 않은 상황에서 웹 사이트를 이용하는 것을 상상해 본 적이 있는가?
웹 사이트는 인터넷 연결을 기반으로 하는 WWW 서비스이다
따라서 네트워크 저 넘어에 있는 웹 사이트에 접속하기 위해서는 인터넷 연결이 필수이다

그러나 HTML 5 는 이러한 웹의 룰(rule)을 깨(?) 버렸다

HTML 5 에서는 인터넷 연결 없이 웹 사이트 이용이 가능한 스펙들을 포함하고 있다
오프라인 웹 실현의 중심이 되는 스펙이 바로 어플리케이션 캐시(Application Cache) 이다

구글의 캘린더 서비스를 사용해 본 적이 있는가?
오프라인 웹 어플리케이션의 전형적인 예이기도 한 구글 캘린더는,
일정 관리를 제공해 주는 서비스인데 인터넷 연결 없는 오프라인 환경에서도 사용이 가능하다
(물론 읽기 전용으로만 사용이 가능하다)

캐시 매니페스트(Cache Manifest) 파일
어플리케이션 캐시의 동작에 핵심이 되는 파일이다
이 파일의 특성과 작성 방식을 아는 것이 곧 어플리케이션 캐시를 아는 것과 다름이 없다

캐시 매니페스트는 실제로 캐시될 웹 리소스에 대한 정의를 포함하는 일종의 설정파일이다
브라우저는 이 파일에 명시된 리소스를 기반으로 로컬 캐시 항목을 결정한다

또한 캐시된 리소스가 서버에서 업데이트 되었다면 이를 다시 새 버전으로 캐시해야 하는데
이 역시 캐시 매니페스트 파일의 업데이트 여부가 기준이 된다

 그럼 가장 간단한 형태의 매니페스트 파일 예를 보자

매니페스트 파일의 확장자는 .manifest 로 하고, 첫줄은 CACHE MANIFEST 라고 정의해야 한다
그리고 그 아래로 캐시될 웹 리소스들을 정의한다(각 항목은 줄바꿈으로 구분됨)
(#... 은 파일의 주석이다)

그리고 메인페이지(혹은 어떤 페이지)에서 매니페스트 파일을 지정해 주면 된다
이후 이 페이지가 호출 되면 캐시는 동작하게된다

캐시 매니페스트파일과 MIME 타입
클라이언트의 웹 브라우저는 매니페스트 파일을 기준으로 캐시 여부를 판단한다
따라서 매니페스트 파일은 클라이언트가 접근할 수 있어야 하며 파일의 MIMIE 타입을 
알맞게 설정해 줘야 한다

마이크로 소프트의 웹 서버인 IIS 의 경우 인터넷서비스 관리자 화면에서 MIME 타입 설정이 가능하다
.manifest 확장자에 대한 MIME 타입을 text/cache-manifest 로 설정한다


캐시 매니페스트 파일의 3가시 섹션
캐시 매니페스트 파일에는 캐시될 리소스 지정 이외에도
대체 리소스 및 반드시 온라인 액세스를 해야 하는 리소스의 지정도 가능하다

CACHE 섹션
가장 핵심이 되는 섹션이다. 클라이언트에 캐시되어야 할 항목을 지정한다
Cache 섹션으로 지정된 웹 리소스는 오프라인에서도 접근이 가능하게 된다
섹션의 기본값이다. 즉 섹션을 직접 명시하지 않으면 기본적으로 CACHE 섹션이 된다

그리고 CACHE 섹션에 명시하지 않아도 자동으로 캐시되는 파일이 있는데,
바로 manifest  속성을 지정한 html 파일이다

NETWORK 섹션
CACHE 섹션과 반대 되는 개념이다. 반드시 온라인 상태에서만 접근 가능한 항목을 지정한다
업데이트가 매우 잦거나 동적으로 변화하는 웹 리소스를 지정할 때 유용하다

FALLBACK 섹션
대체 리소스를 지정하는 섹션이다
요청한 URL에 해당하는 리소스가 존재하지 않을 때 이를 대신해서 표시할 리소스를 지정한다
다른 요소와는 달리 (공백 혹은 탭을 기준으로) 좌/우 쌍으로 지정한다

예) 다음은 home 폴더에 요청한 리소스가 없을 경우 fallback.html 이 대체리소스로 사용되는 예이다

섹션의 기본 값은 CACHE 섹션이며, '섹션이름 :(콜론)' 으로 시작한다


데모 만들어 보기
이제 간단한 어플리캐이션 캐시 데모를 제작해 보자. 파일 구성은 다음과 같다

클라이언트에 데이터를 저장하다
HTML 5 에는 웹 사이트의 데이터를 클라이언트에 저장할 수 있는 새로운 자료구조인
Web Storage(웹 스토로지) 스펙이 포함되었다

Web Storage 의 개념은 심플하다
'키/ 값' 쌍으로 데이터를 저장하고 키를 기반으로 데이터를 조회하는 패턴이다

그리고 영구저장소(localStorage) 와 임시저장소(sessionStorage)를 따로 두어
데이터의 지속성을 구분할 수 있어 응용 환경에 맞는 선택이 가능하다

Web Storage 는 기존 웹 환경의 쿠키(Cookie)와 매우 유사한 개념이다
사실 거의 차이가 없어 보이기도 하다. 다만 몇 가지 쿠키의 단점를 극복하는 개선점이 도입되었다

그럼 쿠키(Cookie)는?
쿠키는 여전히 유효하고 꽤 적절한 클라이언트 저장도구 이다
HTML 5 에서 Web Storage 스펙을 새로 추가했지만 쿠키를 배제하는 것은 아니다
HTML 5 환경에서도 여전히 쿠키를 이용할 수 있다
다만 어떤 것을 사용할 지는 사용자 선택의 몫이라 하겠다

Web Storage 차이점 (쿠키의 단점?)

- 쿠키는 매번 서버로 전송 된다
웹 사이트에서 쿠키를 설정하면 이후 모든 웹 요청은 쿠키정보를 포함하여 서버로 전송된다
Web Storage 는 저장된 데이터가 클라이언트에 존재할 뿐 서버로 전송은 이루어지지 않는다
이것은 네트워크 트래픽 비용을 줄여 준다는 주요한 장점이 되겠다

- 단순 문자열을 넘어 (스크립트) 객체정보를 저장할 수 있다
문자열 기반 데이터 이외에 체계적으로 구조화된 객체를 저장할 수 있다는 것은 개발 편의성을
제공해 주는 주요한 장점이 된다. 브라우저의 지원 여부를 확인해 봐야 하는 항목이다

- 용량의 제한이 없다
쿠키는 개수와 용량에 있어 제한을 걸어 두고 있다
하나의 사이트에서 저장할 수 있는 최대 쿠키 수는 20 개이다. 그리고 하나의 사이트에서 저장할 수 있는 최대 쿠키 크기는 4KB 로 제한되어 있다. Web Storage 는 이러한 제한이 없다
(그러나 쿠키도 하위키를 이용하면 이러한 제한을 일부 해소할 수 있다.
 그리고 대부분의 시나리오에서 쿠키의 제한으로 까지 데이터를 저장할 일이 없다)

- 영구 데이터 저장이 가능하다
쿠키는 만료일자를 지정하게 되어 있어 언젠가 제거된다.
만료일자로 지정된 날짜에 쿠키는 제거되는 것이다.(만료일자를 지정하지 않으면 세션 쿠키가 된다)
만일 영구 쿠키를 원한다면 만료일자를 굉장히 멀게 설정하여 해결하기도 하였다
(그러나 과연 수 년이 지나도록  쿠키가 유지되어야 할 필요가 있을까?)

WebStorage 는 만료기간의 설정이 없다. 즉 한번 저장한 데이터는 영구적으로 존재하는 것이다
이것이 특별히 장점이 되는지는 잘 모르겠지만 쿠키와의 차이점이라는 것은 분명하다
-----

쿠키와 WebStorage 의 차이점과 개선사항에 대해 알아 보았는데 개인적으로,
Web Storage 가 쿠키보다 훨씬 좋은 이유는 없다고 본다.
다만 한가지 매번 서버로 전송되지 않는다는 특징은 꽤나 유용해 보인다
(특히 경량 환경인 모바일에서는 더욱 더)

그리고 쿠키는 더 상세한 설정이 가능해 어떤 환경에서는 더 적합해 보이기 까지 한다
쿠키에 대한 자세한 내용은 다음의 글을 참고하도록 하자
=> Cookie 제대로 알고 사용하자


로컬 스토로지(localStorage)와 세션 스토로지(SessionStorage)
Web Storgae 는 데이터의 지속성과 관련하여 두 가지 용도의 저장소를 제공한다

우선 기본적으로 Web Storage 는 쿠키와 마찬가지로 사이트의 도메인 단위로 접근이 제한된다
다시말해, A 도메인에서 저장한 데이터는 B 도메인에서 조회할 수 없다는 것이다
이것은 데이터의 보안적 측면에서 당연한 원칙이라 하겠다

- 로컬 스토로지
로컬 스토로지 저장한 데이터를 (명시적으로) 지우지 않는 이상 영구적으로 보관한다
앞서 말한대로, 도메인마다 별도로 로컬 스토로지가 생성된다
windows 전역 객체의 localStorage 라는 컬렉션을 통해 저장/조회가 이루어진다

- 세션 스토로지
세션스토로지는 데이터의 지속성과 액세스 범위에 특수한 제한이 존재한다
세션스토로지는 windows 전역 객체의 sessionStorage 라는 컬렉션을 통해 저장/조회가 이루어진다

데이터 유지 측면:
세션 스토로지는 데이터가 지속적으로 보관되지 않는다
이는 마치 브라우저 기반 세션 쿠키와 그 성질이 비슷한데, 현재 페이지가 브라우징 되고 있는
브라우저 컨텍스트 내에서만 데이터가 유지된다

로컬 스토로지는 브라우저를 종료해도 데이터는 보관되어 다음번 접속에도 그 데이터를
사용할 수 있는 반면, 세션 스토로지는 브라우저가 종료되면 데이터도 같이 지워진다.
즉 브라우저가 종료되면 세션 스토로지도 삭제된다는 것이다

데이터 범위 측면:
세션 스토로지 역시 Web Storage 의 기본 보안 처럼 도메인별로 별도로 생성된다
여기에 더불어 세션 스토로지는 같은 사이트의 같은 도메인이라 할지라도 브라우저가 다르면
서로 다른 영역이 된다(즉 브라우저 컨텍스트가 다르다)

탭 브라우징이나 브라우저를 하나 더 실행해서 같은 페이지를 실행했을 때,
이 두 페이지의 세션 스토로지는 각각 별개의 영역으로 서로 침범하지 못한다는 의미이다
(도메인만 같으면 전역적으로 공유 가능한 로컬스토로지와 구분되는 특징이라 하겠다)


브라우저 지원 현황
아래 표는 http://caniuse.com/ 에서 제공하는 브라우저(버전)별 Web Storage 지원 표이다
(데스크탑 용 브라우저 기준이다)

끌어다 놓기(드래그 앤 드롭, Drag & Drop)
끌어다 놓기는 사용자 편의성을 고려한 편리한 UI 기능이라 할 수 있는데,
아래 그림에서 보는 바와 같이 영역 A -> 영역 B로 특정 콘텐트를 마우스로 이동하는 것을 말한다

소스코드의 주석에 상세히 설명을 달았지만 간단히 전체적인 흐름을 설명하자면,
드래그 대상(Source)은 왼쪽 select 박스의 option 항목들이며,
드롭 대상(Target)은 오른쪽 select 박스이다

드래그 대상인 option 요소에 draggable="true" 속성을 부여해 드래그 가능한 상태로 설정하였다
그리고 dragstart 이벤트를 구현하여 드래그 액션이 시작될 때 dataTransfer 객체에
드래그 데이터(여기서는 option 의 ID)를 저장하고 있다

드롭 대상인 오른쪽 select 박스에는 dragenter, dragover, drop 이벤트를 구현하여
preventDefault 함수 호출로 select 박스가 드롭이 가능하도록 설정하였으며
dataTransfer 객체에서 드래그 데이터(여기서는 option 의 ID)를 꺼내온다
이렇게 꺼내온 드래그 데이터를  문서객체에서 조회하여 드래그 대상에서는 제거하고 드롭 대상에
추가하는 로직으로 구성되어 있다

그리고 추가로 드래그 관련 이벤트의 호출 순서를 보기 위한 코드가 각 이벤트에 추가되어 있다

아래는 데모의 실행 화면이다. 먼저 드래그가 중에 캡쳐한 화면이며,

모바일 환경에서의 결제, 정산, 회계 등 통합 빌링은 프로젝트의 주요한 시스템 중 하나이다
얼마전 회사의 다른 팀(기존 빌링 관련 팀)에서 모바일 환경에서의 결제 서비스에 대한
프로젝트 기안서를 올렸다. 그리고 검토를 마치고 본격적으로 구축에 들어갈 것 같다

내용을 보니, 시스템은 평범하다. 하지만 기본과 핵심을 잘 녹여 놓았다.
많은 것을 고려한 고밀도의 모델이라기 보다는 기본에 충실하는 심플한 모델이다

시스템을 판단하기 이전에 든 생각은,
최고 보다는 선점, 즉 최속(가장 빨리), 최선(가장 먼저) 이 때론 더 중요하다는 것이다

많은 이슈와 변수에 기인해 일을 제대로 시작해 보기도 전에, 선점의 기회를 놓친 느낌이다

비단 이 사안 만이 아니다.
상황적 변수로 프로젝트가 답보 상태에 머무르는 동안, 프로젝트 초기 구상했던 몇몇 주요한
시스템들이 이미 내/외부 적으로 런칭 또는 준비되고 있는 상황이다

생각은 실천으로 옮겨야 결과가 나온다
그리고 그 실천은 프로젝트 멤버 개인들에게 주요한 포트폴리오가 될 것이다.
그것이 성공이든 실패이든.

시기적으로 먼저 출발하는 최선(最先)의 효과를 놓치는 것이 너무 아쉽다

HTML 5 는 위치 정보와 관련한 Geolocation 스펙을 포함하고 있다
(엄밀히 말하자면 이 스펙은 HTML Working Group 과 분리되어 있는  Geolocation Working Group
에 의해 표준화가 진행되고 있다고 한다)

Geolocatoin API를 이용하면
현재 웹 페이지가 실행되는 단말의 위도, 경도와 같은 위치 정보를 얻어 올 수 있다

Geolocation 지원 브라우저 현황
현재 IE를 제외한 대부분의 최신 웹브라우저에서 Geolocation을 지원하고 있다
아래 표는 http://caniuse.com/ 에서 제공하는 브라우저(버전)별 Geolocation 지원 표이다
(데스크탑 용 브라우저 기준이다)

MS IE 9 가 unknown 이라고 되어 있지만 아마 지원하게 될 것이다.
MS 가 HTML 5 지원을 강력히 표명하고 있기 때문이다

그리고 이 코드를 파이어폭스에서 실행한 결과 화면이다
(데스크탑 브라우저에서 테스트 해 봤는데, 구글 크롬과 사파리의 경우 지원은 되는데 위도,경도
 정보가 불러와 지지가 않는다. 파이어폭스와 오페라, 아이폰 사파리에서 정상 동작 확인 함 )

ASP.NET MVC 모델에서는 (Views 폴더의) 모든 웹 리소스에 대한 직접 요청을 막아 두었다

사용자 화면(뷰)에 해당하는 Views 폴더에 있는 모든 aspx 파일에 대한 다음과 같은 요청은
모두 404 Not Found 로 처리된다
http://yourdomain.com/Views/Index.aspx

이것은 기존 웹폼 모델과 대조되는 면으로,
ASP.NET MVC에서의 사용자 화면(뷰)은 모두 컨트롤러에 의해 선택되고 랜더 되게 하기 위함이다
따라서 리소스에 대한 직접 요청은 의도적으로 막고 있는 것이다

Views 폴더의 Web.config 에 정의된 HttpNotFoundHandler
Visual Studio 에서 ASP.NET MVC 프로젝트를 생성하면 총 두개의 Web.config 가 생성된다
루트에 있는 Web.config 는 기존과 같이 응용프로그램 전역적인 설정 파일이며
Views 폴더의 Web.config 는 Views 폴더에만 적용되는 설정 파일인데, 이 파일에 정의된
HttpNotFoundHandler 가 리소스 직접 요청에 대한 Not Found 처리를 하는 HttpHandler 이다

앞서 ASP.NET MVC 에서 요청 매개변수 넘기기 에서는 URL 질의 방식에 ASP.NET MVC이
어떻게 반응하는지 알아 보았다. URL에 매개변수를 전달하는 방식은 GET 요청에 해당한다

이번에는 ASP.NET MVC이  POST 요청을 어떻게 처리하는지 알아 보도록 하자

POST 요청의 보편적인 모습은, HTML 입력 양식을 이용한 폼 데이타 제출이다
이 글에서는 간단한 회원가입 폼을 POST 로 전송하고 이를 처리하는 방법을 다룬다

ASP.NET MVC 프로젝트를 하나 생성하고 컨트롤러에 엑션 메서드를 하나 추가한다

- HomeController.cs 에 액션 메서드 추가하기
public ActionResult RegisterForm()
{            
    return View();
}

- 회원 가입 페이지 (뷰)  생성하기
그리고 이 액션 메서드에 해당하는 뷰를 생성한다
생성된 RegisterForm.aspx 뷰 페이지는 회원가입 입력 양식을 아래와 같이 정의한다
<body>
    <h1>회원가입</h1>    
    <form action="/Home/RegisterForm" method="post">        
        <p>아이디: <input type="text" name="MemberID" /></p>
        <p>비밀번호: <input type="password" name="Password" /></p>
        <p>닉네임: <input type="text" name="NickName" /></p>
        <p>이메일: <input type="text" name="Email" /></p>
        <input type="submit" value="가입하기" />           
    </form>
</body>

전형적인 폼 양식이다. 이제 프로젝트를 빌드하고 페이지를 호출해 보자
http://localhost:11102/Home/RegisterForm

모바일 웹 응용프로그램 개발을 위해 적절한 기술들이 유기적으로 잘 조합되어야 한다

클라이언트 즉 웹 브라우저 단 응용 개발을 위해,
기존 HTML, JavaScript, CSS 는 물론이거니와 HTML5, JQuery 를 이용한다
그리고 모바일 환경이다. JQTouch, iUI, PhoneGap 이 추가로 이용될 수도 있다 

그리고 클라이언트-서버 즉 통신 단 응용 개발을 위해,
Ajax , 데이터 포맷인 JSON, XML 등을 이용한다

(그런데 Ajax 라는거 말이지... 원리는 단 하나인데, 응용 환경은 몇 가지가 된다
ASP.NET MVC Ajax 환경, JQuery Ajax 환경, Atlas(Ajax.NET) 환경,
그리고 기존 생짜(XMLHttpRequest) 환경 등등)

참 유명하다. Ajax! 대부분의 웹 개발 플랫폼들이 서로 지원하기에 아낌이 없구나!

그리고 웹 서버 측 응용 개발을 위해,
ASP.NET MVC 를 이용한다. 어쩌면 WCF, WebService 가 추가로 이용될 수도 있다

문제는, 최적의 조합이다
최적의 조합을 찾기 위해 고민 좀 해야 한다. 그리고 개념도 파악해 둬야 한다
그리고 몇 가지는 최적의 코드가 나올 수 있도록 훈련해야 한다

최적의 조합! 최적의 코드!

웹 클라이언트 개발자의 필요성을 느낀다

HTML 5 의 많은 기능 중 웹 페이지가 단순 문서 표현을 넘어 응용프로그램과 같이 동작할 수 있도록
하는 주요한 기능 중 하나가 바로 Web Workders 이다

요즘 웬만한 응용프로그램들은 멀티 프로세스, 멀티 쓰레드를 구현하고 있다
웹 페이지도 이러한 멀티 쓰레드 구현이 가능하게 된 것이다

그간 웹 페이지는 단일 쓰레드 모드에서 수행될 수 밖에 없었다
만일 값을 반환하기까지 작업이 오래 걸리는 스크립트를 수행한다면 다른 UI 작업을
스크립트 작업이 종료될 때 까지 대기해야만 했다

그러나 HTML 5 에는 Web Worker 라는 스펙을 추가 했으며 브라우저에서는 이 스펙을 기반으로
멀티 쓰레드 구동이 가능하도록 브라우저를 설계하기에 이르렀다


롱~타임(Long~ Time) 작업은 워커에게 맡기기
이제 스크립트 작업이 오래 걸린다고 해서 페이지를 멈추고 기다릴 필요가 없어졌다
웹 워커는 자바스크립트 코드를 UI 쓰레드와는 별도인 백그라운드에서 수행될 수 있도록 하는 표준적인 방법을 제공하기 때문에 웹 페이지를 가로막지 않고 스크립트를 돌릴 수 있게 되었다

다음과 같은 롱~타임 스크립트 작업에 웹워커는 안성맞춤 일 것이다
- 매우 복잡한 수학적 계산 작업
- 원격지에 있는 리소스에 대한 액세스 작업(또는 로컬 스토로지를 액세스 하는 경우)
- 백그라운드에서 조용히(?) 오랜시간 작업해야 하는 경우
- UI 쓰레드에 방해 없이 지속적으로 수행해야 하는 작업 등

사실 웹 워커 만의 지침은 없다. 일반적인 응용프로그램의 백그라운드 작업을 연상하면 된다


브라우저가 Web Worker 를 지원하나요?
HTML 5 가 아직 산업 표준이 완료된 것이 아니기에 브라우저별로 지원 여부가 상이할 수 있다
그리고 브라우저 버전별로도 지원 유/무가 다르기도 하다

따라서 웹 페이지에 웹 워커를 동작시키기 전에, 현재 페이지를 랜더링 하고 있는 브라우저가
웹 워커를 지원하는지 체크하는 것이 필수이다 (이것은 하위 호환성을 위해서도 중요하다)

브라우저의 웹 워커 지원 유/무 체크는 매우 간단한 방법으로 할 수 있다
전역 윈도우 객체의 워커(Worker) 속성을 살펴보면 된다. 아래는 샘플 코드이다

if(!!window.Worker){
      alert("이 브라우저는 웹 워커를 지원합니다")
}
else{
      alert("이 브라우저는 웹 워커를 지원하지 않습니다")
 }


Web Workers 개념도
웹 워커는 HTML 페이지에서 Worker 라는 객체를 통해 실행된다
HTML 페이지에 Worker 객체를 생성하기 위해서는 워커의 작업을 정의한 자바스크립트파일(.js)
을 Worker 객체 생성 시 전달해 줘야 한다
ex) var worker = new Worker("worker.js")

이후 롱~타임 작업은 .js 파일에 정의된 스크립트로 수행되며,
HTML 페이지와는 서로 데이터를 주고 받을 수 있는 매커니즘이 제공되는 것이다

양쪽 모두 상대에게 데이터를 송신할 때는 postMessage 라는 메서드를 이용하며
데이터를 수신할 때는 onmessage 이벤트를 통해 전달 받는다

아래 그림은 기본적인 (단일) 워커와 HTML 페이지 간 데이터 송/수신 개념도 이다

function sleep(milliSeconds){ 
  var startTime = new Date().getTime(); // get the current time  
  while (new Date().getTime() < startTime + milliSeconds); // hog cpu
}

- HTML 페이지
이제 이 워커(파일)을 이용하는 HTML 페이지를 아래와 같이 작성한다
앞서 정의한 worker.js 파일을 기반으로 Worker 객체를 생성하고 postMessage 메서드를 통해
워커로 메시지를 전달한다. 또한 onmessage 이벤트를 정의하여 워커로 부터 전달되는 메시지를
받을 수 있도록 한다. 그리고 워커의 작업을 중지시키려면 terminate 메서드를 호출하면 된다

<!DOCTYPE html>
<html>
  <head>
    <script type="text/javascript">             
      var worker;     
      function callWorker(){     
        if(!!window.Worker){ //브라우저가 웹 워커를 지원하는지 검사한다   
           
          if(worker) worker.terminate();      //워커가 이미 존재하면 종료시킨다                    
          worker = new Worker("worker.js");  //새로운 워커(객체)를 생성한다      
                      
          worker.onmessage = function(event){ //워커로부터 전달되는 메시지를 받는다
            alert(event.data);
          };
                           
          worker.postMessage("워커야! 깨어나라!"); //워커에게 메시지를 전달한다       
        }
        else{
          alert("현재 브라우저는 웹 워커를 지원하지 않습니다")
        }
      }
               
      function stopWorker(){
        if(worker){
          worker.terminate();
          alert("워커 작업이 중지되었습니다");
        }
      }
    </script>
  </head>
  <body>
    <button onclick="callWorker()">웹워커 호출</button>
    <button onclick="stopWorker()">웹워커 중지</button>   
    <br>   
    <input type="text">
  </body>
</html>

- 실행 화면
HTML 파일을 웹 브라우저(데스크 탑 사파리)에서 실행하면 10초 후에 메시지가 나타난다
또한 워커를 사용했기 때문에 브라우저가 얼어 버리는 일은 없다
즉 10초라는 대기 시간 동안에도 브라우저를 움직이거나 텍스트 상자에 글을 입력할 수 있게 되는 것이다

이전 ASP나 ASP.NET 웹폼 모델에서는 URL의 꼬리표에 붙여 있는 매개변수를
Request 객체를 통해전달 받을 수 있었다

즉 다음과 같이 두 개의 매개변수를 URL 에 붙여서 매개변수를 전달하게 되면,
요청 URL: http://yourdomain/main.aspx?param1=value1&param2=value2

아래처럼 매개변수 정보를 취할 수 있다(ASP.NET 기준)
string value1 = Request.QueryString["param1"].ToString();
string value2 = Request.QueryString["param2"].ToString();

그렇다면 ASP.NET MVC 모델에서는 매개변수를 어떻게 전달하고 받는지 알아보도록 하자

기본은 동일하다
ASP.NET MVC 역시 이전 웹폼 모델과 동일한 형태로 매개변수를 넘기고 받을 수 있다

즉 아래와 같이 요청 URL 에 ? 꼬리표로 매개변수를 전달하면
HomeController 의 Index 액션 메서드에서 다음과 같이 매개변수에 접근할 수 있게 된다

요청 URL: http://localhost:11102/Home/Index/?name=Park&age=10

public ActionResult Index()
{
    string name = Request.QueryString["name"].ToString();
   string age = Request.QueryString["age"].ToString(); 

    ViewData["param"] = String.Format("Hello, {0}, Your age {1}", name, age);

    return View();
}


액센메서드의 매개변수로 전달 받기
URL 에 포함되어 있는 매개변수를 액션 메서드의 매개변수로 전달 받을 수도 있다
아래 코드는 Index 매개변수를 통해 URL로 전달되는 매개변수를 전달 받고 있다

요청 URL: http://localhost:11102/Home/Index/?name=Park&age=10

public ActionResult Index(string name, string age)

{

    ViewData["param"] = String.Format("Hello, {0}, Your age {1}", name, age);

    return View();

}

액션 메서드를 통해 매개변수를 전달 받는 것은 ASP.NET MVC 프레임워크에서 제공해 주는 기능이며
이전 형태 보다는 조금 더 ASP.MVC 스럽다고 할 수 있겠다

액션 메서드로 매개변수를 전달 받을 경우 URL 에 정의된 매개변수 명과 액션메서드에 정의된
매개변수 명이 동일해야 한다는 규칙이 있다(순서는 상관 없다. 변수 이름이 중요하다)


참고로 URL 에 매개변수가 있다고 해서 반드시 액션 메서드에 매개변수를 정의 해야 하는 것은 아니다
그리고 그 반대의 경우, 즉 액션메서드에 매개변수가 정의 되었다고 해서 반드시 URL에 매개변수를 넘겨야 하는 것은 아니다 (물론 이 두 경우는 매개변수를 사용하지 않을 경우이다)

예를 들어 URL 에 매개변수가 생략되었을 경우 액션메서드로는 null 을 전달하게 될 것이다


URL 스키마 사용자 정의
앞서 Request.QueryString 으로 매개변수를 가져오는 방식에 비해 액션 메서드의 매개변수로 가져오는 것이 보다 깔끔하고 직관적이라는하다는 것을 느낄 수 있다.
이것은 매개변수를 가져오는 측면에서 ASP.NET MVC 가 지원해 주는 부분이 되겠다

이번에는 매개변수를 전달하는 측면에서의 ASP.MVC 의 장점을 살펴 보자

앞서 요청 URL은 다음과 같은 스키마로 이루어 졌었다
http://localhost:11102/Home/Index/?name=Park&age=10

전통적인 방식으로 URL에 ? 꼬리표를 통해 매개변수를 전달하고 있다
우리는 이러한 요청 URL을 보다 깔끔하게 변경하고 싶다

ASP.NET MVC 에서는 URL 스키마를 개발자의 입맛대로(?) 재 구성할 수 있는 방법을 제공해 준다.

이는 ASP.NET MVC의 라우팅 엔진이 제공해 주는 기능인데,
Global.asax 의 RegisterRoutes 메서드의 커스트마이징을 통해 구현할 수 있다

우선 매개변수를 어떤 형태의 URL 스키마로  정의할 지 결정해야 하는데,
다음과 같이 '/(슬래쉬)'를 계속 이어가고 싶다고 가정해 보자

http://localhost:11102/Home/Index/매개변수1/매개변수2

이와 같은 URL 스키마를 실현하기 위해 Global.asax 파일에 정의된
RegisterRoutes 메서드를 약간 수정해 보자

public static void RegisterRoutes(RouteCollection routes)

{

    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(

        "Default",

        "{controller}/{action}/{name}/{age}", // URL with parameters

              new { controller = "Home", action = "Index",

name = UrlParameter.Optional,

                         age = UrlParameter.Optional }

  );

}


MapRoute 메서드의 두 번째 정보에 URL 스키마를 정의한다
우리가 결정한 URL 스키마를 실현하기 위해 /(슬래시)로 매개변수를 취할 수있도록 하였다
컨트롤러/액션메서드/name매개변수/age매개변수 형태로 정의함
=> "{controller}/{action}/{name}/{age}"

그리고 다음과 같이 각 매개변수의 옵션 여부를 지정하였다
이는 name, age 정보가 URL에서 생략될 수 있다는 의미이다
name = UrlParameter.Optional, 
age = UrlParameter.Optional

이제 구성이 완료 되었으니 다음과 같은 요청에 정상적으로 반응하게 될 것이다
http://localhost:11102/Home/Index/Park/10


만일 다음과 같은 URL을 원한다면,
http://localhost:11102/Home/Index/Park-10

다음과 같이 정의하면 된다
"{controller}/{action}/{name}-{age}"

참고로 이런 식으로 URL 스키마 재정의로 매개변수 정보를 구성하였다면,
더 이상 Request.QueryString 로 받을 수 없다는 것에 주의하자
-----------------------------------------------------------------------------------

마지막으로 URL 재구성된 상태에서 전통적인 ? 매개변수 전달을 같이 혼용하면 어떻게 될까?
다시 말해 다음과 같은 URL 요청은 어떻게 되는지 살펴 보자

요청 URL: http://localhost:11102/Home/Index/Park/10?name=Kim&age=20

액션메서드:
public ActionResult Index(string name, string age)

{

    ViewData["param"] = String.Format("Hello, {0}, Your age {1}", name, age);

    return View();

}

이를 경우 URL 로 재구성된 매개변수 정보가 먼저 참조 된다
즉 URL 요청으로 부터 전달되는 name, age 라는 매개변수가 각각 두 개씩 이지만
URL 재구성에 의한 name=Park, age = 10 이 전달되는 것이다

그러나 만일 URL 스키마에서 매개변수 정보를 생략하고 다음과 같이 요청 된다면,
http://localhost:11102/Home/Index/?name=Kim&age=20

결과는 ?  매개변수가 전달되게 된다

ASP.NET MVC 는 라우팅 구성 정보에 의거한 적절한 매개변수를 가져올 수 없는 경우
전통적인 ? 질의 문자열에서 매개변수를 가져오게 되는 것이다

JQuery 는 오픈소스 자바스크립트 라이브러리이다

JQuery 를 이용해서 스크립트 작업을 하면 웹 표준에 위배되는지 걱정하지 않아도 되며
매우 간단한 문법구조로 많은 처리를 할 수 있는 장점이 있다
또한 스크립트의 안정성도 뛰어나 결과적으로 스크립트 작업의 생산성을 극대화 할 수 있게 된다

JQuery 를 페이지에서 사용하려고 하면 JQuery의 기반 라이브러리를 페이지에 정의해야 한다

일반적으로는 JQuery 라이브러리를 직접 다운로드 해서 페이지에 삽입하면 된다

1) JQuery 라이브러리 파일을 직접 페이지에 삽입하기
http://docs.jquery.com/Downloading_jQuery 에서 최신 버전 다운로드 받는다
(현재 최신 버전은 1.4.2 이다)

그리고 페이지의 head 영역에 해당 스크립트를 포함시킨다
<head>
    <script type="text/JavaScript" src="jquery-1.4.2.js"></script>
</head>

이제 해당 페이지에서는 JQuery 관련 기능을 이용할 수 있게 된다


2) 최소 버전 JQuery 라이브러리 사용하기
JQuery 라이브러리는 풀버전과 최소화버전 두 가지가 제공된다
최소화버전은 사이즈가 작은 대신 디버깅 환경은 제공되지 않는다는 특징이 있다
따라서 개발시에는 풀버전으로 하고 라이브 적용 때에 최소화 버전으로 변경하는 것을 생각해 볼 수 있다. 최소화 버전 역시 JQuery 홈페이지에서 다운로드 받을 수 있다
<head>
    <script type="text/JavaScript" src="jquery-1.4.2.min.js"></script>
</head>


3) 구글의 CDN 서비스 사용하기
CDN 서비스는 굉장히 빠른 속도로 컨텐트를 내려 받을 수 있는 환경을 제공한다
구글에서 JQuery 라이브러리 다운로드를 위해 CDN 서비스를 무료로 제공해 주고 있다

다음의 URL 이 JQuery 가 호스팅 된 곳이다

최소화 버전)
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js

풀버전)
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js

역시 이 URL을 head 에 스크립트로 명시하면 된다
<head>
  <script type="text/JavaScript"  src=http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js></script>
</head>


JQuery 서적에서는 구글의 CDN 서비스를 이용할 것을 다음과 같은 사유로 권장한다
- 안전하고 믿을 수 있다
- 다운로드가 빠르다
- 어디서나 사용할 수 있다(JQuery.js를 늘 들고 다니지 않아도 된다)


3. 마이크로소프트의 CDN 서비스 사용하기
마이크로소프트 역시 구글처럼 JQuery를 CDN 으로 무료 서비스를 제공한다
다음 URL이 그것이다

http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.js
http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js