강좌 최초 작성일 : 2006년 05월 27일 강좌 최종 수정일 : 2006년 05월 29일
강좌 읽음 수 : 회
작성자 : Songgun(송 원석) 편집자 : Taeyo(김 태영)
강좌 제목 : HTC 작성 및 ASP.NET Custom 컨트롤 연동
강좌 전 태오의 잡담>
www.egocube.pe.kr 사이트를 운영하고 있는 송원석 군이 보내준 강좌입니다.
참고로, 송군은 Microsoft MVP 이기도 합니다. ^^
이번에는 ASP.NET 컨트롤과 HTC를 버무린 방법을 소개하고 있습니다.
재미있는 자바스크립트, HTCs 의 작성 및 ASP .NET 웹 사용자 지정 컨트롤 연동
지금까지 우리들은 두 차례에 걸친 논의를 통해서 간단하게나마 HTCs 란 어떠한 기술인지, 그리고 구체적으로 어떻게 활용될 수 있는 기술인지에 대해서 알아보았으며 비교적 간단한 수준의 HTCs 를 직접 작성해보기도 했다.
본문에서는 기술적인 관점에서 HTCs 를 작성하는 방법에 대하여 조금 더 논의를 진행해보고 그러한 과정의 결과로서 얻어지는 HTCs 를 ASP .NET 웹 사용자 지정 컨트롤과 연동하는 구체적인 사례를 살펴보고자 한다.
만약 여러분들이 전문적인 ASP .NET 개발자가 아니라던가 ASP .NET 웹 사용자 지정 컨트롤을 제작해본 경험이 없거나 ASP .NET 을 이제 막 시작하고자 계획중인 개발자라면,
다소 부족하나마 본문에서 제시되는 논의를 통해서 그 강력한 기능을 일부라도 접해볼 수 있는 의미있는 기회가 될 수 있었으면 한다.
먼저 살펴보고자 하는 부분은 과연 지난글에서 우리들이 고민하며 작성했던 HTCs 가 가지고 있는 문제점은 전혀 없는가 하는 점이다.
이 HTCs 의 구체적인 목표는 최종 사용자가 실수 또는 고의로 숫자값 이외의 데이터를 입력하는 것을 방지하는 것으로, 실제로도 그 기대에 부합하여 예상한 바와 같이 잘 동작한다는 사실을 이미 확인한 바 있다.
그러나 이 HTCs 에는 비록 간단하긴 하지만 반면 매우 치명적인 단점이 한 가지 존재한다.
즉 최종 사용자가 입력하는 데이터를 대상으로는 상대적으로 엄격한 유효성 검사를 수행하지만, 개발자가 저지르는 실수에 대해서는 거의 완벽하게 무방비 상태라는 점이다.
결과적으로 이러한 치명적인 단점을 개선하지 못한다면 이 HTCs 는 재사용성이라는 부분에 있어서 단적으로 낮은 평가를 받을 수 밖에 없을 것이다.
간단하지만 다음의 INPUT 태그 예제는 바로 이러한 문제점을 적나라하게 보여주고 있다.
대번에 알 수 있겠지만 이 예제에 사용된 자바스크립트 코드의 수준이라는 것은 특이하기는 커녕 실무에서는 되려 질려버릴 정도로 빈번하게 접하게 되는 평범한 코드로서 필자가 내용을 설명한다는 것이 무안할 정도의 코드에 불과한 것이다.
그럼에도 불구하고 HTCs 의 기능은 너무나도 쉽게 무너져 버렸다.
결과적으로 이러한 사례는 우리들이 작성한 HTCs 가 그다지 치밀한 설계를 바탕으로 작성된 것은 아니라는 반증인 셈이다.
그리고 다음의 HTML 코드 역시도 현재 이 HTCs 가 가지고 있는 문제점들 중의 하나를 명확하게 드러내주는 또 하나의 사례다.
너무나도 어이없는 단순한 조작만으로도 그냥 넘어가기에는 곤란한 문제점이 노출된다는 사실을 쉽게 인지할 수 있을 것이다.
그렇다면 이 두 가지 문제점을 해결하는 데에서부터 본격적인 논의를 시작해보도록 하자.
그런데 한 가지 안타까운 사실은 첫 번째 문제점의 경우에는 문제의 발생 그 자체를 방지할 수 있는 근본적인 해결 방법이 존재하지 않는다는 점이다.
적어도 필자가 지닌 지식으로는 별다른 방법을 찾을 수가 없었다.
일단 손쉽게 고려해 볼 수 있는 방법에는 기존의 HTCs 에 onchange 이벤트 헨들러를 추가하는 방법이 있을 것이다.
그러나 자바스크립트를 사용하여 데이터를 변경하는 경우에는 이 이벤트 자체가 발생하지 않는다.
따라서 이 방법은 거의 무용지물이나 마찮가지이며 그렇다고 별다른 대안도 존재하지 않는다.
결국 필자가 얻어낼 수 있었던 최선의 결론은 데이터 유효성 검사를 위한 후처리 작업의 일환으로서 사용될 수 있는, 그리고 입력된 데이터의 유효성을 검사해주고 경우에 따라서는 보정 작업까지 처리해주는 함수를 일관적인 형태로 제공해주는 어느 정도 소극적인 방법뿐이었다.
이를테면 사용자의 데이터 입력과 관련을 가지고 있는 모든 종류의 HTCs 에 미리 규정한 이름으로 작성된 하나의 함수, 가령 isValidate() 와 같은 함수를 제공하고 이 HTCs 들을 사용하는 모든 페이지에서는 FORM 이 서브밋되기 직전에 이 함수를 호출하여 유효성을 검증하도록 프로그래밍 룰을 정의하는 것이다.
그러면 HTCs 에 실제로 이 함수의 구현을 추가해보도록 하자.
먼저 지금까지 해왔던 것과 마찮가지로 PUBLIC:METHOD 엘레먼트 태그 선언을 다음과 같이 추가해준다.
그리고 이 함수의 실질적인 구현은 다음과 같은데, 이제는 상당히 익숙해진 작업 패턴과 코드일 것이라고 생각한다.
기술적인 관점에서 볼 때에도 그다지 주목할만한 부분이 없으므로 불필요한 설명은 하지 않도록 하겠다.
비록 냉정하게 평가해본다면 이 방법이 문제 자체에 대한 해결책이라고 볼 수는 없겠지만 나름대로 하나의 유효성 검증 프로세스를 만들어낸다는 점에서는 긍정적으로 받아들일 수 있을 것이다.
참고로 앞에서 간단하게 언급했던 onchange 이벤트를 헨들링하는 방법 대신 onpropertychange 이벤트를 통해서 우회적으로나마 문제점을 해결하는 방법도 필자 나름대로 고민해보고 있으므로 그 성과가 나오는 대로 본문을 갱신하도록 하겠다.
...
function isValidate()
{
if (!checkTagType()) return;
var objRegEx = /^\d+$/ig;
return objRegEx.test(trim(element.value));
}
//-->
</SCRIPT>
</PUBLIC:COMPONENT>
다행스럽게도 두 번째 문제점의 경우에는 보다 근본적이고 세련된 해결 방법이 존재한다.
그 핵심도 매우 간단한 편인데 바로 일반적인 객체 지향 언어의 클래스 구조에서 보편적으로 제공되어지는 프로퍼티 메서드 메커니즘을 HTCs 내부적으로 제공해주는 것이다.
자바에서의 getter / setter 나 비주얼 C# .NET 의 get / set 속성 접근자를 머리속에 떠올려보면 필자의 얘기를 쉽게 이해할 수 있을 것이다.
따라서 두 번째 문제점을 해결하기 위해서는 단지 HTCs 에서 제공되는 해당 기능을 충실히 구현하기만 하면 된다.
이번 논의는 각각의 과정들이 단계별로 약간 복잡하므로 서두르지 말고 차근차근 따라오기 바란다.
먼저 다음과 같이 기존에 작성했던 defaultValue 속성의 PUBLIC:PROPERTY 엘레먼트 태그에 새로운 두 개의 속성, get 과 put 을 추가해보자.
이것만으로 엘레먼트 태그의 변경이 다 마무리 된 것은 아니고 계속해서 추가적인 작업이 더 이루어져야만 되므로 잠시 이 점을 염두에 두고 있기 바란다.
일단 지금은 계속해서 다음 단계를 진행하도록 하겠다.
어쨌거나 이 속성들이 의미하는 바는 지극히 간단명료하다.
구체적으로 말해서 get 속성에는 defaultValue 프로퍼티의 값이 리턴될 때 호출되는 자바스크립트 함수의 이름을 설정하고, 반대로 put 속성에는 defaultValue 프로퍼티에 값을 설정할 때 호출되는 자바스크립트 함수의 이름을 설정하면 되는 것이다.
그리고 물론 지극히 당연한 얘기겠지만 이 두 가지 속성에 지정된 자바스크립트 함수들은 별도로 구현하여 HTCs 에 추가해주어야만 한다.
이를테면 다음의 두 자바스크립트 함수는 그 구현 결과의 한 사례다.
function getDefaultValue()
{
return defaultValue;
}
function putDefaultValue(value)
{
if (!checkTagType()) return;
var objRegEx = /^\d+$/ig;
if (objRegEx.test(value))
defaultValue = value;
else
defaultValue = 0;
}
이제 이런 패턴의 자바스크립트 코드는 거의 외우다시피 했을 터이므로 무의미한 코드 설명은 피하도록 하겠다.
아무튼 결과적으로 이제 우리들이 원하지 않는 기본값이 설정되는 사태는 거의 완벽하게 피할 수 있게 된 것으로 보인다.
그러나 과연 정말로 그런 것일까?
현재까지 작업한 결과를 저장하고 실제로 테스트를 해보면 스택 오버플로우 오류가 발생한다.
그렇다면 그 원인은 무엇일까?
지금까지 우리들이 작성한 코드를 가만히 살펴본다면 아마도 그 이유를 쉽게 파악할 수 있을 것이다.
빙빙 돌리지 않고 단도직입적으로 문제점을 얘기하자면 오류가 발생하는 원인은 defaultValue 프로퍼티의 내부 변수가 그 어디에도 선언되지 않았기 때문이다.
즉 이 두 자바스크립트 함수 내부에서는 defaultValue 프로퍼티의 값을 설정하거나 리턴하는 작업이 처리되는데, 역설적으로 이 두 함수가 호출되는 시점 자체가 바로 defaultValue 프로퍼티의 값을 설정하거나 리턴하고자 시도되어지는 경우이기 때문이다.
따라서 자연스럽게 무한 루프가 발생되며 그 결과로 자바스크립트의 함수 호출 스택애서 오버 플로우가 발생되는 것이다.
이 오류를 제거하는 방법은 간단하다.
다음과 같이 이 프로퍼티의 값을 담을 전역 변수를 하나 선언해주고 기본값을 초기화해주면 되는 것이다.
...
<SCRIPT language="javascript" type="text/javascript">
<!--
var defaultValue = 0;
...
이 전역 변수의 이름과 프로퍼티의 이름이 동일하다는 점에 주의하기 바란다.
비록 이러한 특징이 프로퍼티 내부 변수를 선언하기 위해 반드시 필요한 강제적인 룰은 아니지만, 기타 부가적인 작업없이 간단하게 전역 변수를 선언하기 위해서는 전역 변수의 이름과 프로퍼티의 이름이 동일해야만 한다.
만약 프로퍼티 자체의 이름과 전역 변수의 이름이 같아서 코드가 전반적으로 혼란스럽게 느껴진다면 다음과 같은 방법으로 전역 변수의 이름을 직접 지정해주는 것도 물론 가능하다.
먼저 해당 프로퍼티의 PUBLIC:PROPERTY 엘레먼트 태그에 다음과 같이 internalname 속성을 추가하고 그 값으로는 프로퍼티의 값을 담고자하는 전역 변수의 이름을 입력해준다.
그리고 앞에서 선언했던 것과 동일하게 이 이름으로 전역 변수를 선언해주면 된다.
결과적으로 방금 구현했던 프로퍼티 메서드 자바스크립트 함수에서 사용된 전역 변수의 이름도 이에 맞추어 변경되어야 한다.
그리고 지금까지 프로퍼티의 기본값 설정을 위해 사용되었던 PUBLIC:PROPERTY 엘레먼트 태그의 value 속성은 이제 더 이상 필요하지 않으므로 삭제한다.
대신 지금부터는 전역 변수의 초기값이 그 기능을 대신하게 된다.
다음의 예제는 이렇게 수정된 HTCs 가 올바르지 않은 프로퍼티값 설정 시도를 보정하는 모습을 보여주고 있다.
또한 지금 논의한 이 internalname 속성은 PUBLIC:METHOD 엘레먼트 태그를 대상으로도 동일한 영향력을 발휘하여 내부 자바스크립트 함수의 이름과 외부로 노출되는 HTCs 메서드의 이름을 다르게 지정할 수 있으므로 참고하기 바란다.
이번에는 논의의 각도를 조금 달리해보도록 하자.
지금까지 우리들이 다루어왔던 내용 대부분이 프로퍼티와 메서드에 관한 것이었다는 점을 감안해본다면 그 다음 단계로서 자연스럽게 이벤트에까지 생각이 미치게 될 것이다.
상식적으로 메서드와 프로퍼티에 대한 기반 구조를 제공해주는 HTCs 가 이벤트에 대한 기반 구조만 제공해주지 않을 이유는 없다.
오히려 이벤트에 대한 기반 구조를 제공해줄 뿐만 아니라 일반적인 DHTML 의 이벤트 모델과 유기적으로 잘 결합된 메커니즘을 제공해주므로 추가적인 노력 없이도 상당히 고품질의 결과를 얻을 수 있는 것이다.
그러면 지금까지 구현된 HTCs 에 사용자가 올바르지 않은 형식의 데이터를 입력하는 경우 우리들이 구현한 사용자 정의 이벤트가 발생하도록 코드를 추가해보자.
먼저 사용자 정의 이벤트의 이름은 onIncongruent 라고 하기로 하며 동일한 이름으로 태그의 속성에 노출되어질 것이다.
만약 사용자 정의 이벤트의 이름이 HTML 태그에 존재하는 기본 이벤트의 이름과 동일하다면 그 동작 특성이 사용자 정의 이벤트에 의해서 덮어씌워지므로 참고바란다.
다음과 같이 PUBLIC:EVENT 엘레먼트 태그를 선언을 추가한다.
지금까지 살펴보았던 프로퍼티나 메서드를 위한 엘레먼트 태그 선언과는 다르게 이벤트를 위한 엘레먼트 태그 선언의 경우에는 반드시 id 속성이 설정되어야만 하는데 그 구체적인 이유는 잠시 뒤에 설명하도록 할 것이다.
다음 작업으로는 이 사용자 정의 이벤트를 발생시키기 위한 목적의 자바스크립트 함수를 하나 만들어 주어야 한다.
사용자 정의 이벤트 자체를 발생시키기 위해서 반드시 별도의 함수를 정의해야만 하는 것은 아니지만 event 개체를 생성하고 필요한 속성값들을 적절하게 설정하는 등의 반복적인 작업을 효과적으로 처리하기 위해서는 이처럼 유틸리티 함수를 하나 만들어주는 것도 좋은 방법일 것이다.
다음 함수를 살펴보자.
...
function fireIncongruent(Value)
{
objEvent = createEventObject();
if (Value != null)
objEvent.returnValue = Value;
_Incongruent.fire(objEvent);
}
//-->
</SCRIPT>
이 함수에는 주의 깊게 살펴볼만한 내용들이 몇 가지 존재한다.
가장 먼저 짚어봐야될 부분은 함수의 가장 마지막 라인으로서, 무엇 때문에 PUBLIC:EVENT 엘레먼트 태그를 선언하면서 반드시 id 속성을 설정해야만 하는지에 대한 이유가 잘 드러나 있다.
사용자 정의 이벤트를 발생시키는 실질적인 역활을 담당하는 fire() 메서드를 호출하기 위해서는 해당 이벤트의 식별자 역활을 담당하는 id 속성이 필요한 것이다.
그리고 fire() 메서드에는 인자로 event 개체의 인스턴스를 생성하여 전달해야만 하는데, 여기에서 얘기하고 있는 event 개체는 일반적인 DHMTL 프로그래밍에서 사용되는 바로 그 event 개체와 정확하게 같은 개체를 의미하는 것으로, 위의 함수의 첫 번째 라인에서 찾아볼 수 있는 createEventObject() 메서드를 사용하여 그 인스턴스를 생성할 수 있다.
보통 event 개체로부터 제공되는 대부분의 정보들, 즉 마우스 버튼 정보나 키보드 정보, 좌표 정보 등을 담고 있는 속성들은 읽기 전용이지만, 지금과 같이 createEventObject() 메서드를 통해서 인스턴스가 생성된 경우에는 모든 속성값을 설정할 수 있다.
따라서 개발자들이 그 값을 자유롭게 설정할 수 있는데 이는 실로 대단한 장점이라고 평가할 수 있으며, 본문에서는 하나의 간단한 예로 returnValue 속성값을 설정하는 경우를 보여주고 있다.
참고로 이 메서드는 HTCs 에서만 사용이 가능한 것은 아니고 document 개체에서도 동일한 기능을 제공해주는 메서드를 같은 이름으로 지원해주므로 이 부분에 관심이 있으신 분들은 MSDN 을 살펴보기 바란다.
이제 이 함수를 적절한 위치에서 호출해주기만 하면 사용자 정의 이벤드가 이벤트가 발생된다.
다음 코드는 onblur 이벤트의 HTCs 이벤트 헨들러로 구현된 evtBlur() 함수를 수정한 결과이다.
...
function evtBlur()
{
if (!checkTagType()) return;
var objRegEx = /^\d+$/ig;
if (!objRegEx.test(trim(element.value)))
{
element.value = defaultValue;
fireIncongruent("Incongruent Data!");
}
}
...
그리고 다음은 지금까지 구현된 모든 코드들이 반영된 HTCs 가 적용된 최종 결과물이다.
숫자가 아닌 임의의 문자열을 복사하여 붙여넣기로 입력값을 변경해보면 이벤트가 발생하는 것을 확인할 수 있을 것이다.
그리고 한 가지 주의해야 할 점은 이와 같이 HTCs 수준에서 구현된 사용자 정의 이벤트는 기본적으로 버블링이 되지 않는다는 사실이다.
구체적인 실례로 아래의 코드에서 SPAN 태그에 정의된 onIncongruent 이벤트 헨들러의 코드는 전혀 동작하지 않는데 잠시만 곰곰히 생각해보면 매우 당연한 일이라는 것을 알 수 있다.
지금까지 우리들은 HTCs 의 프로퍼티나 메서드, 그리고 이벤트를 구현하는 방법과 관련된 여러가지 기법들에 관해서 살펴보았다.
그렇다면 이번에는 HTCs 자체의 전반적인 동작 특성을 제어하는 방법에 관해서 살펴보도록 하자.
이와 관련된 엘레먼트 태그는 두 가지로, 이미 앞에서 잠시 살펴보았던 HTCs 자체를 정의하는 기능을 가지고 있는 PUBLIC:COMPONENT 엘레먼트 태그와 지금 처음으로 논의되어지는 PUBLIC:DEFAULTS 엘레먼트 태그가 바로 그것이다.
그런데 필자가 말해 놓고서도 무안하기는 하지만 냉정하게 평가해 볼 때 우리들이 이 두 엘레먼트 태그를 가지고서 처리할 수 있는 작업은 현재 시점에서는 그다지 많지가 않다.
왜냐하면 지금까지 우리들이 논의해온 대부분의 내용들이 Attached Behavior 에 관한 것임에 반하여 앞에서 말한 두 엘레먼트 태그가 제공하는 대부분의 기능들은 Element Behavior 와 관련된 것들이기 때문이다.
그런 이유로 본문에서는 지금까지의 논의와 관련된 극히 일부의 기능들에 대해서만 살펴볼 생각이며 PUBLIC:DEFAULTS 엘레먼트 태그는 아예 거론하지 않을 것이다.
다음은 우리들이 작성한 HTCs 코드의 PUBLIC:DEFAULTS 엘레먼트 태그 선언으로서 지금까지 별다른 설명없이 일괄적으로 사용해온 부분이다.
무척이나 심플한 구조를 가지고 있으며 붉은색으로 강조된 부분을 살펴보면 lightWeight 라는 속성의 값이 true 로 설정되었다는 사실을 알 수 있을 것이다.
이 lightWeight 속성이 갖고 있는 의미는 매우 간단하다.
즉 이 HTCs 가 내부에 마크업, 즉 렌더링 되어야 할 HTML 태그를 가지고 있는지 여부를 나타낸다.
렌더링의 관점에서 볼 때 지금과 같이 HTCs 내부에 그 어떠한 HTML 태그도 존재하지 않는다면 HTML 태그가 존재하는 경우에 비하여 상대적으로 가볍다고 (lightWeight) 판단할 수 있으므로 그 값은 true 로 지정된다.
그리고 이 경우 렌더링 프로세스 자체가 필요없다는 의미로 받아들여져 퍼포먼스의 향상을 기대할 수 있게 되는 것이다.
그런데 여기에서 반복적으로 말하고 있는 'HTCs 의 내부에 존재하는 HTML 태그' 라는 문장의 의미를 오해하지 말아야 한다.
HTCs 의 종류에는 크게 Attached Behavior 와 Element Behavior 라는 두 가지 범주가 존재한다는 사실은 이미 지난번 글에서 간략하게 설명한 바 있다.
이 두 종류의 HTCs 간의 결정적인 차이점은 사용자 인터페이스가 존재하는지 또는 존재하지 않는지 여부이고 지금 우리들은 사용자 인터페이스가 존재하지 않는 Attached Behavior 를 중점적으로 논의하고 있는 과정중에 있다.
앞에서 말하고 있는 'HTCs 의 내부에 존재하는 HTML 태그' 란 바로 Element Behavior 에서 사용자 인터페이스를 구성하는 HTML 태그들을 뜻하는 것이다.
그러므로 이런 종류의 HTML 태그가 전혀 존재하지 않는 우리들의 HTCs 에서는, 비록 자바스크립트 코드의 내부에는 HTML 태그의 편린들이 포함되어 있다고 할지라도 lightWeight 속성값을 true 로 설정하여 퍼포먼스의 향상을 기대할 수 있다.
참고로 이 속성의 기본값은 false 이다.
마지막으로 이런 경우를 한 번 가정해보도록 하자.
임의의 HTML 태그가 존재하고 있다.
그런데 이 태그에는 두 가지 HTCs 가 동시에 설정되어 있다고 생각해보자.
그리고 공교롭게도 두 HTCs 에서 모두 MyFunction 이라는 메서드를 정의하고 있다면, 그리고 자바스크립트에서 해당 메서드를 호출한다면 어떻게 될까?
단순하게 머리속으로만 생각해봐도 뭔가 문제가 발생할 것이라는 사실을 짐작할 수 있을 것이다.
필자가 테스트 해 본 바에 따르면 이와 같은 경우 명시적인 오류가 발생하지는 않지만 두 개의 HTCs 중에서 순서적으로 먼저 설정된 HTCs 의 메서드만이 실행된다.
따라서 각각의 HTCs 를 구분하여 지정할 수 있는 어떤 방법이 제공되어야지만 개발자가 원하는 메서드를 정확하게 지시하여 호출할 수 있을 것이다.
이 목적으로 사용되는 속성이 바로 name 속성이다.
다음의 코드를 살펴보자.
이제 자바스크립트 코드는 다음과 같이 작성될 수 있다.
물론 해당 태그에 단 하나의 HTCs 만 설정되어 있다면 name 속성의 지정 여부와는 관계없이 지금까지 기존과 동일한 방법으로 메서드를 호출할 수 있다.
그리고 이러한 특성은 프로퍼티에도 동일하게 적용되므로 참고하기 바란다.
지금까지 우리들이 논의했던 내용들이 HTCs 를 보다 효과적으로 사용하기 위해 요구되어지는 가장 기초적인 사항들이었다면
지금부터 살펴보고자 하는 내용들은 HTCs 의 잠재력을 극대화시킬 수 있는 응용 방법에 관한 것이다.
이와 관련하여 여러가지 흥미로운 사례들이 있을 수 있겠지만 그 중에서도 필자가 개인적으로 많은 관심을 가지고 있는 영역은 본문의 서두에서 간단하게 언급한 바와 같이 ASP .NET 웹 사용자 지정 컨트롤과 연동하여 모든 혹은 거의 대부분의 클라이언트 사이드 스크립트를 HTCs 로 대체하는 기법이다.
그동안 업무의 일환으로서, 또는 학습을 목적으로 나름대로 ASP .NET 웹 사용자 지정 컨트롤을 작성하면서 언제나 불만스러웠던 점이 바로 서버 사이드 작업 영역에 대해서는 과거 ASP 프로그래밍 모델에 비해 비약적인 수준으로 향상된 모델을 .NET 프레임워크에서 기본적으로 제공해주지만, 반면 클라이언트 사이드 스크립트 작업 영역에 대해서는 일말의 진보도 없었다는 점이었다.
현실적으로 사용자 인터페이스와 관련된 자바스크립트 코드를 완전히 작업으로부터 배제할 수 없는 상황에서 이러한 제약은 웬지 반쪽짜리 컴포넌트를 작성하는 듯한 기분만을 느끼게 할 뿐이었다.
그러나 이제는 ASP .NET 웹 사용자 지정 컨트롤에 HTCs 를 도입하여 문제점의 대부분을 말끔하게 해소할 수 있게 되었다.
비록 HTCs 가 인터넷 익스플로러 환경에서만 동작하기는 하지만 기업체 내부에서만 가동되는 시스템과 같이 사용자 환경에 대한 기본적인 정의가 미리 이루어지는 환경에서는 기대한 수준을 넘어서는 효과를 얻을 수 있을 것이라는게 필자의 견해다.
다만 한 가지 안타까운 사실은 본문 자체는 어디까지나 HTCs 에 관해서 논의하고 있는 문서이므로 분량에 대한 고려나 기타 여러가지 이유로 인해서 지금 논의하고자 하는 ASP .NET 웹 사용자 지정 컨트롤에 대한 전반적인 영역들을 모두 살펴볼 수는 없다는 점이다.
게다가 필자 역시도 아직까지는 ASP .NET 웹 사용자 지정 컨트롤에 대한 지식이 많이 부족하다고 스스로 생각하고 있기 때문에 본격적인 논의를 진행하기에는 커다란 무리가 따른다는 점도 또 다른 한 가지 이유이다.
따라서 본문에서는 여러분들이 이미 간단한 ASP .NET 웹 사용자 지정 컨트롤을 직접 작성해 본 경험이 있거나, 최소한의 기본적인 지식은 보유하고 있다는 가정하에 모든 내용을 진행하도록 할 것이다.
그러나 코드 자체가 그다지 어렵지 않을 뿐더러 컨트롤 빌더나 컨트롤 디자이너, 또는 형식 변환기와 같은 고급 기법은 전혀 사용하지 않았으므로 코드만 보더라도 이해하는데 큰 무리는 없을 것이라는 생각이다.
작업 목표 자체는 상당히 단순한데, 우리들이 작성한 HTCs 를 ASP .NET 에서 제공해주는 기본 TextBox 서버 컨트롤과 결합하여 새로운 ASP .NET 웹 사용자 지정 컨트롤을 만드는 것으로 다음은 그 최종 결과물의 전체 소스 코드이다.
물론 이 소스 코드도 필자의 사이트를 통해서 공개해왔던 모든 프로그램들과 마찮가지로 소스 코드 자체 및 디자인, 주석 등을 포함한 프로그램의 모든 내용을 수정하거나 추가하여 재배포 할 수 있으며 상업적인 용도를 포함한 모든 유형의 목적에 있어 그 어떠한 종류의 제약도 존재하지 않는다.
그러나 이 코드를 수정하여 제작한 자신의 2 차 제작물에 대한 권리를 남용하여 다른 사용자들이 이 소스 코드를 자유롭게 사용할 수 있는 권리를 제한하지는 못한다.
이와 관련하여 보다 자세한 내용을 알고 싶으신 분들은 필자가 저작권에 대한 입장을 공식적으로 정리하여 작성한 'ECUM 버전 0.0.2b 의 저작권 관련 사항' 의 내용을 참고하기 바란다.
비록 해당 문서가 또 다른 별개의 프로그램인 ECUM 버전 0.0.2b 에 관한 문서내에 작성되어져 있기는 하지만 해당 문서에서 밝히고 있는 바와 같이
특별하게 저작권과 관련된 언급을 별도로 하지 않는 이상 필자가 공개하는 모든 프로그램은 상기 문서의 규정을 따른다는 점에 유의하기 바란다.
그러면 전반적인 작업 과정을 살펴보기에 앞서 먼저 결과물이 어떻게 생성되는지를 살펴보기로 하자.
무엇보다도 가장 먼저 짚고 넘어가야 할 점은 컴파일된 최종 결과물이 단 하나의 DLL 파일만으로 이루어진다는 것이다.
즉, 마지막 배포 단계에서 최종 개발자에게 전달되는 파일은 오직 하나의 DLL 뿐이라는 결론이 되는데,
필자가 본문을 준비하면서 ASP .NET 웹 사용자 지정 컨트롤과 HTCs 를 통합하는 사례의 하나로 이 샘플 컨트롤을 설계할 때 가장 주의를 기울였던 부분이 바로 이 부분이다.
가령 임의의 시스템을 구축하는 프로젝트가 존재하고 대략 10 여명 내외의 프로젝트 팀으로 구성된 개발자들이 존재한다고 생각해보자.
실력이 뛰어난 한 명의 개발자가 프로젝트 내부용으로 ASP .NET 웹 사용자 지정 컨트롤을 개발하여 나머지 팀원들에게 배포하면 웹 페이지를 개발하는 최종 개발자들이 해당 컨트롤을 사용하는 형태라고 할 때, 신규 컨트롤이 배포되거나 기존의 컨트롤이 변경되어 재배포되는 경우, 가장 이상적인 상황은 최종 개발자들이 해당 컨트롤에 대해서 그 어떠한 신경도 쓰지 않을 수 있는 환경일 것이다.
조금 더 구체적으로 말해본다면 최종 개발자들은 HTCs 가 존재하게 될 경로나 컨트롤의 버전 등 자질구레한 일체의 사항들에 대해서 신경쓰지 않아도 개발에는 전혀 지장이 없어야만 한다.
그런 이유로 이 샘플 ASP .NET 웹 사용자 지정 컨트롤은 컴파일된 코드뿐만 아니라 HTCs 를 포함한 모든 유형의 리소스들이 DLL 파일의 내부에 포함되어지도록 설계되었으며 최초 일회 런타임시가 되어서야 비로소 HTCs 가 DLL 파일로부터 추출되어져 미리 지정된 폴더에 생성되도록 되어있다.
그리고 실질적인 최종 결과물에 해당하는 HTML 의 태그는 이 추출된 HTCs 를 링크하도록 자동적으로 렌더링되어지는데, 추출된 HTCs 가 지정된 경로에 저장될 때 DLL 파일의 현재 버전 정보를 파일명에 반영하도록 설계가 되어 있어서 HTCs 가 변경되는 경우에도 DLL 파일의 버전만 조정해주면 HTCs 의 새로운 버전이 전체 웹 프로젝트로 즉시 전파될 수 있도록 구성되어져 있다.
따라서 웹 페이지만을 개발하는 최종 개발자의 입장에서는 부차적인 내용들을 전혀 신경쓰지 않아도, 배포된 DLL 파일을 ASP .NET 웹 응용 프로그램 프로젝트에서 참조하고, 도구 상자에 ASP .NET 웹 사용자 지정 컨트롤을 등록한 다음, ASP .NET 에서 기본으로 제공되는 서버 컨트롤을 사용하는 방법과 동일한 방법으로 이 컨트롤을 사용하는 것만으로도 HTCs 를 도입하여 얻을 수 있는 여러가지 장점들을 고스란히 활용할 수 있다.
게다가 ASP .NET 웹 사용자 지정 컨트롤 개발자의 입장에서도 전반적인 HTCs 관리가 혁신적으로 간단해지게 된다.
다만 지금 필자가 설명하고 있는 이러한 ASP .NET 웹 사용자 지정 컨트롤의 설계 방법이나 구현상의 몇 가지 특징들은 HTCs 를 보다 효율적으로 활용할 수 있는 방법을 다방면으로 모색한 끝에 얻어진 지극히 조그마한 필자의 개인적인 성과일 뿐이라는 점을 강조하고 싶다.
결코 이러한 내용들이 다른 방법들에 비하여 기술적인 우위에 있다던가 하지는 않으며 단지 하나의 흥미로운 구현 사례 정도로 받아들여 주었으면 한다.
어쩌면 지금 본문을 읽고 계신 분들 중에서도 필자가 제안하고 있는 방법보다 더 좋은 아이디어를 머리속으로 떠올리고 계신 분이 있을지도 모른다.
그리고 지금부터는 설명상의 편의를 위해 이 샘플 ASP .NET 웹 사용자 지정 컨트롤을 HTCs TextBox 서버 컨트롤이라고 가칭하여 부르기로 하겠다.
HTCs TextBox 서버 컨트롤의 실제 이름은 ASP .NET 에서 기본적으로 제공되는 TextBox 서버 컨트롤과 동일한 TextBox 서버 컨트롤이다.
물론 그 네임스페이스는 EgoCube.Web.UI.WebControls 라는 전혀 별개의 네임스페이스로 설정되어 있으므로 서버 컨트롤의 클래스가 충돌하거나 하지는 않는다.
그리고 지금부터의 살펴보게 될 모든 논의들은 마이크로소프트 비주얼 스튜디오 .NET 2003 버전을 사용하여 작업한다고 가정한다.
먼저 테스트용 웹 페이지를 만들기 위한 ASP .NET 웹 응용 프로그램 프로젝트를 생성한다.
그리고 본문에서 다운로드 받은 압축 파일에 들어있는 웹 컨트롤 라이브러리 프로젝트를 방금 생성한 ASP .NET 웹 응용 프로그램 프로젝트의 솔루션에 추가하여 다음과 같은 솔루션 구조를 구성한다.
전반적으로 솔루션의 구조가 대단히 단순하고 구성의도 또한 명확하므로 구조를 이해하는데 별다른 어려움은 없을 것이다.
그 다음에는 웹 컨트롤 라이브러리 프로젝트를 ASP .NET 웹 응용 프로그램 프로젝트에 프로젝트 형태로 참조한다.
물론 컴파일 된 DLL 파일을 직접 참조할 수도 있겠지만 지금 단계에서는 프로젝트 참조의 형태가 더 바람직할 것이다.
그리고 최종 개발자들이 비교적 편리하게 웹 페이지를 개발할 수 있으려면 아무래도 컨트롤이 도구 상자에 등록되어 있는 편이 좋을 것이다.
그러므로 이번에는 HTCs TextBox 컨트롤을 도구 상자에 등록해보자.
마이크로소프트 비주얼 스튜디어 .NET 2003 의 '도구(T)' 메뉴에서 '도구 상자 항목 추가/제거(X)...' 를 실행하거나, 직접 도구 상자에서 마우스 오른쪽 버튼을 클릭하여 팝업 메뉴를 띄우고 '항목 추가/제거(I)...' 메뉴를 실행하면 다음과 같이 '도구 상자 사용자 지정' 대화 상자가 나타난다.
이 '도구 상자 사용자 지정' 대화 상자에서 '찾아보기(B)...' 버튼을 클릭하고, 다운로드 받은 웹 컨트롤 라이브러리 프로젝트의 bin 폴더 하위에 위치한 Debug 폴더나 Release 폴더에 있는 EgoCube.Web.UI.WebControls.dll 파일을 선택하면 다음과 같이 컨트롤이 등록된다.
이미 설명했던 것처럼 컨트롤 자체의 이름은 ASP .NET 에서 기본으로 제공되는 TextBox 서버 컨트롤과 동일한 TextBox 서버 컨트롤이지만 네임스페이스와 어셈블리 이름을 살펴보면 그 본질은 전혀 다른 컨트롤이라는 점을 알 수 있을 것이다.
이제 '확인' 버튼을 눌러서 '도구 상자 사용자 지정' 대화 상자를 닫고, 도구 상자를 살펴보면 다음과 같이 여러가지 도구 상자 탭들 중 하나 - 대부분의 경우 일반 탭 - 에 등록된 HTCs TextBox 컨트롤을 쉽게 찾을 수 있을 것이다.
그리고 눈치가 빠르신 분들은 이미 대부분 짐작하고 계시겠지만 재미삼아 얘기해본다면 필자의 그래픽 프로그램 실력이 크게 부족한 관계로 기본 TextBox 서버 컨트롤에서 복사한 아이콘을 텍스트 색상만 약간 변경해서 새 컨트롤에 사용했다.
언제나 그렇지만 필자에게 아이콘 만들기란 너무나도 힘든 작업이다.
컨트롤을 사용하기 위한 대부분의 작업들이 대부분 완료되었으므로 이제 남은 일은 등록된 HTCs TextBox 컨트롤을 사용하는 일 뿐이다.
일반적인 ASP .NET 서버 컨트롤들과 마찮가지로 마우스를 이용한 드래그 & 드랍 기능을 지원하며, 위의 이미지에서 볼 수 있는 두 번째 TextBox 서버 컨트롤이 바로 그런 방법을 통해서 생성된 것이다.
그뿐만 아니라 디자인 뷰 상태에서 페이지에 올려진 HTCs TextBox 서버 컨트롤을 마우스로 선택하면 다음과 같이 컨트롤에 대응하는 속성들이 속성 창에 반영되어 출력된다.
다시 말해서 ASP .NET 에서 기본으로 제공되는 서버 컨트롤들과 그다지 차이날 바가 없는 것이다.
그러나 디자인 타임 지원 기능과 관련하여 결정적으로 부족한 기능이 한 가지 존재하는데 바로 HTML 뷰에서는 인텔리센스 기능이 동작하지 않는다는 점이다.
HTML 뷰에서의 인텔리센스 기능 지원은 현재의 마이크로소프트 비주얼 스튜디오 .NET 2003 버전 개발 환경하에서 다소 복잡할 뿐만 아니라 배포라는 관점에서 볼 때 상당히 번거로운 작업을 요구한다.
게다가 보다 민감한 문제는 그러한 작업들이 서버 컨트롤 개발자들 뿐만 아니라 컨트롤을 사용하는 웹 개발자들에게까지 요구되어진다는 점으로서, 본문에서는 굳이 문맥을 흐트려가면서까지 별도로 논의를 진행할 필요는 없다고 판단되어 HTML 뷰에서의 인텔리센스 기능 지원은 그 구현을 생략했다는 점을 감안하기 바란다.
그런데 위의 이미지만 놓고 본다면 속성 창에 나타난 속성들의 종류가 대단히 다양하므로 웹 사용자 지정 컨트롤에 대한 기본적인 지식이 없으신 분들은 필자가 이 모든 속성들을 직접 구현한 것으로 오해하기가 쉬울 것이다.
그러나 부모 클래스로부터 상속받은 속성들 외에 직접 코드로 구현하여 추가해준 속성은 '동작' 카테고리 하위의 'HTCs' 속성과 'HTCsDefaultValue' 속성, 고작 이렇게 두 가지에 불과하다.
그 밖의 나머지 속성들은 모두 ASP .NET 에서 기본으로 제공해주는 TextBox 서버 컨트롤로부터 상속받은 것들일 뿐으로 사용자 지정 컨트롤을 작성할 때마다 이렇듯 많은 분량의 속성들을 모두 코드로 직접 구현해주어야만 하는 것인지 미리부터 염려하시는 분들은 없기 바란다.
실제로 TextBox 서버 컨트롤을 상속받는 부분인 클래스 선언부의 코드는 다음과 같이 매우 일상적인 평범한 코드에 불과하며, 이 단 한 줄의 코드로 인해서 부모 웹 서버 컨트롤의 클래스로부터 모든 속성들을 상속받게 되는데, 사실 이는 너무나도 당연한 결과라고 말할 수 있을 것이다.
...
public class TextBox : System.Web.UI.WebControls.TextBox
{
...
컨트롤에 새로운 속성을 추가시키기 위해서는 해당 컨트롤의 클래스에 필요한 속성을 구현해주기만 하면 된다.
물론 아무렇게나 마음 내키는대로 클래스 속성을 구현하기만 하면 되는 것은 아니고 실제로는 여러가지 다양한 기법들이 동원되지만 그 기본적인 원리는 이를 크게 벗어나지 않는다고 말할 수 있다.
특히나 형식 변환기 등과 같은 디자인 타임 지원 기능이나 템플릿 또는 데이터 바인딩과 같은 컨트롤의 고급 기능들을 직접 구현하지 않는 경우에는 더욱 그렇다.
예를 들어서 아래의 코드는 방금 전에 설명했던 HTCs TextBox 서버 컨트롤에 추가된 'HTCs' 속성과 'HTCsDefaultValue' 속성의 실제 구현 코드이다.
문맥상 다소 혼란스러울 수도 있겠지만, Category 나 DefaultValue 등 클래스 라이브러리에 미리 정의된 일련의 특성 (Attribute) 들을 사용하여 속성 창에 출력되는 컨트롤의 속성 (Property) 들을 제어하는 부분 등을 유심히 살펴보기 바란다.
참고로 이러한 특성들에 대한 보다 상세한 정보는 System.ComponentModel 네임스페이스를 통해서 얻을 수 있다.
그리고 프로퍼티의 데이터를 저장하기 위해서 클래스 내부 변수를 선언하는 대신 ViewState 개체를 사용하는 기법이라던지, 'HTCs' 속성의 리턴 데이터 형이 열거형이라는 사실과 그로 인해 HTCs' 속성의 속성 창 출력 형태가 자동적으로 드롭다운 리스트로 나타난다는 점 등도 한 번 눈여겨 볼만한 부분이다.
...
#region 컨트롤 프로퍼티
/// <summary>
/// 컨트롤에 적용되는 HTCs 모드를 지정한다. 만약 마무런 값도 지정되지
/// 않으면 컨트롤은 HTCsType.NotSet 을 지정한 것과 동일한 모드로 동작하고,
/// 이는 ASP.NET 에서 기본으로 제공되는 TextBox 컨트롤의 동작과
/// 정확하게 동일한 것이다.
/// </summary>
[Description("컨트롤에 적용되는 HTCs 모드를 지정합니다.")]
[Category("Behavior")]
[DefaultValue(HTCsType.NotSet)]
public HTCsType HTCs
{
get
{
if (this.ViewState["HTCs"] == null)
return HTCsType.NotSet;
else
return (HTCsType) this.ViewState["HTCs"];
}
set
{
this.ViewState["HTCs"] = value;
}
}
/// <summary>
/// 컨트롤이 HTCs 모드에서 동작될 때 적용되는 defaultValue 속성값을 지정한다.
/// 이 속성값은 컨트롤이 HTCs 모드로 동작하지 않는 경우에는 무시된다.
/// </summary>
[Description("컨트롤이 HTCs 모드에서 동작될 때 적용되는 defaultValue 속성값을...")]
[Category("Behavior")]
[DefaultValue("")]
public string HTCsDefaultValue
{
get
{
if (this.ViewState["HTCsDefaultValue"] == null)
return "";
else
return (string) this.ViewState["HTCsDefaultValue"];
}
set
{
this.ViewState["HTCsDefaultValue"] = value;
}
}
#endregion
...
그러나 여러분들이 정말로 세심하게 주의를 기울여서 살펴봐야만 될 부분은 지금부터 논의될 몇 가지 내용들이다.
이미 앞에서 얘기했던 것처럼 HTCs TextBox 컨트롤은 컴파일된 코드뿐만 아니라 HTCs 파일을 포함한 모든 유형의 리소스들이 DLL 파일의 내부에 포함되어지도록 설계되어 있다.
이러한 결과를 얻기 위해서 우리들이 처리해주어야 할 작업은 매우 간단한데, 단지 DLL 파일 내부에 패키징하고자 하는 리소스 파일의 '빌드 작업' 속성값을 '포함 리소스' 로 설정해 주기만 하면 된다.
이를테면 다음 이미지는 HTCs_Numeric_Only.htc 파일의 실제 설정 상태를 보여주고 있다.
이것이 필요한 작업의 전부다.
다음 단계로 구현해야 할 작업은 최초 일회 런타임시에 DLL 파일로부터 HTCs 파일의 코드 내용을 추출하여 미리 지정해 놓은 폴더에 실제 파일을 생성하고, 렌더링되는 HTCs TextBox 컨트롤의 HTML 코드가 이렇게 만들어진 HTCs 파일을 링크하도록 처리하는 작업이다.
그런데 실제로 이러한 코드를 구현하기 전에 몇 가지 미리 고려해봐야만 할 사항들이 있다.
그 첫 번째로는 DLL 파일로부터 추출된 HTCs 코드를 구체적으로 어떤 폴더에 파일로 생성할 것인지를 결정해야만 한다.
두 번째로는 이미 컨트롤이 개발자들에게 배포된 상황에서 다시 HTCs 코드가 변경되는 경우가 발생한다면 당연히 재배포된 컨트롤의 HTCs 파일이 반영되어야만 하는데, HTCs 파일이 생성될 폴더에는 이미 이전 버전의 HTCs 파일이 존재하고 있을 수 있으므로, 결국 HTCs 파일간의 버전을 식별할 수 있는 어떠한 방안이 필요하다는 점이다.
마지막 세 번째로는 이와 같은 작업들을 처리하기 위해 필요한 실제 코드가 서버 컨트롤의 라이프 싸이클안에서 어떤 단계에서 구현되는 것이 가장 적절한지를 결정해야만 한다.
그렇다면 우선 HTCs 파일을 생성할 위치로는 어디가 가장 적당할지에 대해서 논의해보자.
개개인마다 선호하는 방법이 있겠지만 필자는 이 문제를 굳이 어렵게 접근하지 않고 가장 간단한 방법으로 해결하기로 했다.
잠시만 생각해본다면 ASP.NET 기반 구조에는 현재 우리들의 목적에 적절하게 활용할 수 있는 폴더가 이미 존재하고 있다는 점을 알 수 있을 것이다.
바로 aspnet_client 폴더가 그것이다.
그러나 이 폴더를 그 자체로 사용하기에는 조금 무리가 있는데, 왜냐하면 aspnet_regiis.exe 등의 프로그램이 실행되면 해당 폴더가 덮어씌워지거나 삭제될 수 있는 가능성도 충분히 존재하기 때문이다.
따라서 약간의 응용이 필요한데 지금부터 그 방법을 알아 보도록 하자.
그다지 널리 알려지지는 않은 사실이나 machine.config 파일의 355 라인 부근을 살펴보면 다음과 같은 노드를 찾아볼 수 있을 것이다.
그 유명한 processModel 노드의 바로 다음에 나타나는 노드이므로 찾는데 별다른 어려움은 없을 것이다.
그 내용을 한 번 살펴보기만 하면 아무리 눈치가 없는 사람이라도 뭔가 느껴지는 바가 있을 것이다.
이미 여러분들도 대부분 예상하고 계시겠지만 바로 이 노드가 ASP.NET 에서 사용하는 자바스크립트의 생성용 폴더 경로를 설정하는 노드이다.
더군다나 이 노드에 존재하는 유일한 속성인 clientScriptsLocation 의 값을 살펴보면 고맙게도 String 클래스의 Format() 메서드를 사용하는 것을 전제로 하는양 구성되어 있는 것이다.
따라서 이 속성값을 읽어들인 다음, 간단한 문자열 처리를 거치기만 하면 꽤나 그럴듯하면서 나름대로 합리적인 경로를 얻어낼 수 있다.
그래서 필자는 다음과 같은 유틸리티 메서드를 간단하게 작성하여 클래스에서 내부적으로 사용하고 있다.
그리고 그 결과로서 생성되는 폴더의 실제 구조는 다음의 이미지를 통해서 미리 살펴볼 수 있다.
이 폴더 구조는 필자의 개발 PC 에 현재 생성되어 있는 실제 구조다.
ASP .NET 의 자체적인 폴더들을 전혀 간섭하지 않으면서도 대부분의 분들이 납득할 수 있을만한 결과라고 생각한다.
여러분들도 각자 자신이 소속된 업체의 회사명이나 기관명 등을 활용하여 aspnet_client 폴더 하위에 고유한 폴더를 추가할 수 있을 것이다.
다만 한 가지 주의해야 할 점이 있는데 그것은 앞에서도 여러차례 얘기했던 것처럼 폴더가 생성되는 시점이 실제로 컨트롤이 최초로 로드되어 사용될 때라는 점이다.
즉 문제의 핵심은 개발자나 서버 관리자에 의해서가 아니라 일반 사용자의 페이지 요청에 의해서 폴더 생성이 이루어진다는 점이다.
따라서 ASP .NET 의 기본 실행 계정인 ASPNET 계정이 가지고 있는 제한된 권한만으로는 폴더의 생성이 불가능하므로 결과적으로는 권한 관련 오류가 발생하게 된다.
이러한 오류를 피하려면 IIS 6.0 을 사용하고 있는 경우에는 관련된 응용 프로그램 풀의 ID 설정을 '로컬 시스템' 으로 바꿔주고, 그 이하의 IIS 버전을 사용하고 있는 경우라면 machine.config 파일에서 processModel 노드의 userName 속성의 값을 SYSTEM 으로 바꿔주면 된다.
만약 응용 프로그램 풀이라는 개념 자체가 익숙하지 않다거나, 응용 프로그램 풀 ID 구성 방법을 잘 모른다면 마이크로소프트에서 제공하는
'IIS 6.0에서 응용 프로그램 풀 구성 (IIS 6.0)' 문서나 'IIS 6.0에서 응용 프로그램 풀 ID 구성 (IIS 6.0)' 문서 등을 먼저 참고하기 바란다.
버전 문제 역시도 생각하기에 따라서는 매우 간단하게 해결할 수가 있다.
물론 다른 여러가지 좋은 방안들이 존재할 수도 있겠지만 필자가 생각해낸 해결 방법의 핵심은 바로 리플렉션이다.
조금 더 구체적으로 얘기하자면 HTCs 파일의 버전 관리를 위해서 굳이 별도의 체계를 만들어낼 것이 아니라, 먼저 서버 컨트롤 어셈블리의 버전 정보를 리플렉션으로 가져와서 HTCs 파일의 버전으로 반영시키면 되는 것이다.
.NET 어셈블리의 버전 정보는 AssemblyInfo.cs 파일의 AssemblyVersion 속성을 통해서 제어가 가능하며, 대부분의 경우 다음의 코드에서 볼 수 있는 것과 같은 기본값으로 설정되어져 있다.
...
[assembly: AssemblyVersion("1.0.*")]
...
이 기본 설정을 그대로 사용하는 것도 나쁘지는 않겠지만, 서버 컨트롤의 어셈블리 버전 정보를 활용하여 논리적으로 HTCs 파일 버전을 관리한다는 현재의 논의를 위해서는 버전 정보를 명시적으로 설정하는 편이 더 바람직할 것이다.
따라서 다음과 같이 버전 정보를 명시적으로 직접 설정해보도록 하자.
당연한 얘기겠지만 이제 해당 서버 컨트롤 프로젝트를 컴파일하면 버전 정보가 1.0.1.0 인 어셈블리 DLL 이 생성된다.
...
[assembly: AssemblyVersion("1.0.1.0")]
...
다시 본론으로 돌아와 보자.
방금 우리들은 서버 컨트롤의 어셈블리 버전 정보를 설정하는 방법에 관해서 간단하게 알아보았다.
그런데 이 방법과 HTCs 파일의 버전 관리 사이에는 서로 어떠한 관계가 존재하는 것일까?
그 답은 매우 간단한데, HTCs 파일이 생성되는 시점에 리플렉션을 사용하여 서버 컨트롤의 버전 정보를 얻고 그 버전 정보를 실제로 생성되는 HTCs 파일명의 일부로 사용하는 것이다.
그리고 HTCs 파일의 내용이 다시 변경되는 경우에는 서버 컨트롤 어셈블리 자체의 버전 정보를 변경하여 DLL 파일을 재생성한 다음, 웹 페이지 개발자들에게 다시 DLL 파일을 배포하면 된다.
만약 또다시 HTCs 파일의 내용이 변경된다면 이번에도 서버 컨트롤 어셈블리의 버전 정보를 역시 다시 변경하여 컴파일하고 재배포하면 된다.
물론 렌더링되는 컨트롤의 HTML 태그에도 역시 다음과 같이 해당 버전 정보가 반영되어햐 하는 것은 당연한 일일 것이다.
그렇다면 이번에는 구체적으로 과연 어떻게 서버 컨트롤 어셈블리로부터 버전 정보를 읽어오는지 그 방법을 논의해볼 차례다.
앞에서 간단하게 언급했던 것처럼 리플렉션을 사용하면 이 문제는 쉽게 해결할 수 있다.
일단 System.Reflection 네임스페이스로부터 제공되는 Assembly 클래스의 정적 메서드인 GetExecutingAssembly() 메서드를 사용하여 현재 코드가 실행되고 있는 어셈블리에 대한 참조를 Assembly 클래스 형태로 얻는다.
당연한 얘기겠지만 이렇게 얻어낸 Assembly 개체는 서버 컨트롤 어셈블리를 가리키고 있게 되는데, 이 개체의 멤버 메서드인 GetName() 메서드를 통해서 얻어낼 수 있는 AssemblyName 클래스 타입 개체의 Version 프로퍼티 값으로 간단하게 어셈블리 버전 정보를 가져올 수가 있다.
이 과정이 구현된 실제 코드는 다음과 같으며 리소스로부터 Stream 개체 형식으로 읽어들인 HTCs 파일의 내용을 본래의 파일명과 어셈블리의 버전 정보를 결합한 새로운 파일명으로 저장하는 전반적인 과정을 보여준다.
코드를 잘 살펴보면 Assembly 개체의 멤버 메서드인 GetManifestResourceStream() 메서드를 사용하여 간단하게 HTCs 파일의 내용을 얻어내고 있다는 점 또한 쉽게 알 수 있을 것이다.
사실 이 리소스라는 개념은 대부분의 웹 개발자들에게는 그다지 친숙하지 않은 낯선 개념이지만 윈도우즈 응용 프로그램 개발자들에게는 매우 친숙한 개념으로서 이와 같은 방식으로 리소스를 활용하는 기법이 그다지 새로운 방법인 것은 아니다.
예를 들어서 EXE 파일이나 DLL 파일의 내부에 존재하는 아이콘 등의 경우를 머리속에 떠올려 보면 쉽게 이해가 갈 것이다.
...
// 리소스로부터 HTCs 파일을 읽는다.
switch (this.HTCs)
{
case HTCsType.Numeric:
HTCsName = "HTCs_Numeric_Only";
break;
}
System.Reflection.Assembly objAssembly
= System.Reflection.Assembly.GetExecutingAssembly();
HTCsResourceName = HTCsRootNameSpace + "." + HTCsName + ".htc";
using (System.IO.Stream objStream
= objAssembly.GetManifestResourceStream(HTCsResourceName))
{
using (System.IO.StreamReader objSR = new System.IO.StreamReader(objStream))
{
HTCsCode = objSR.ReadToEnd();
}
}
// HTCs 파일 존재 점검 및 생성
HTCsFullPathName = this.Page.Server.MapPath(this.ClientScriptsLocation())
+ "\\" + HTCsName + "_" + objAssembly.GetName().Version + ".htc";
if (!System.IO.File.Exists(HTCsFullPathName))
{
using (System.IO.StreamWriter objSW
= new System.IO.StreamWriter(HTCsFullPathName, false))
{
objSW.Write(HTCsCode);
}
}
...
이제 지금까지 논의한 내용들을 하나의 메서드로 구현한 뒤, 적절한 서버 컨트롤의 라이프 싸이클 단계에서 메서드를 호출해주기만 하면 모든 준비과정이 마무리 된다.
필자는 WriteHTCsFile() 라는 이름으로 해당 메서드를 작성하고 부모 클래스인 WebControl 클래스의 OnInit() 이벤트 헨들러 메서드를 재정의하여 다음의 코드에서 볼 수 있는 바와 같이 WriteHTCsFile() 메서드를 호출함으로서 실질적인 구현을 처리하고 있다.
물론 이와 같이 서버 컨트롤이 로드될 때마다 매번 반복하여 HTCs 파일의 추출 및 저장 작업을 실행하는 것은 필요없는 퍼포먼스 비용을 발생시키게 되므로 HTCs 속성이 NotSet 으로 설정된 경우에는 별다른 작업을 실행하지 않는 등의 간단간단한 대응 코드들이 실제 메서드에는 추가되어져 있다.
그러나 사실 보다 엄격하게 얘기한다면 코드의 효율성이라는 측면에서 볼 때 그 정도의 대처만으로는 많이 부족한 것이 사실이고, 보다 근본적인 접근 방법의 개선이 이루어져야 할 것이다.
예를 들어서 서버 컨트롤이 디자인 뷰에 드래그 & 드랍되는 시점이라던가 서버 컨트롤의 특정 속성값이 변경되는 시점에 HTCs 파일의 추출 및 저장 작업이 미리 이루어지는 등의 방법으로 말이다.
그러나 본문은 어디까지나 ASP .NET 사용자 지정 컨트롤과 HTCs 파일간의 연동에 관한 간단한 개념을 설명하는 것이 그 본래의 목적이므로 이 주제에 대해서는 더이상 언급하지 않을 것이다.
...
/// <summary>
/// WebControl.OnInit 메서드 재정의
/// </summary>
/// <param name="e">이벤트 데이터가 들어 있는 EventArgs 개체</param>
protected override void OnInit(EventArgs e)
{
this.WriteHTCsFile();
base.OnInit(e);
}
...
마지막으로 살펴보고자 하는 부분은 지금까지 논의한 내용들을 통해서, 미리 지정한 경로에 실제로 생성된 물리적인 HTCs 파일을 서버 컨트롤의 최종 결과물인 HTML 태그의 렌더링 결과에 반영시키는 작업이다.
여러분들도 이제는 익히 알고 있는 바와 같이 HTCs 파일은 케스케이딩 스타일시트의 behavior 속성을 통해서 설정되어 진다.
따라서 우리들이 원하는 작업을 처리하기 위해서는 어떠한 방식으로든지 서버 컨트롤의 케스케이딩 스타일시트 설정 과정중에 HTCs 를 설정하기 위한 단계가 추가되어야만 한다는 결론이 자연스럽게 이끌어 진다.
게다가 경우에 따라서는 defaultValue 와 같이 HTCs 내부에서 추가적으로 정의한 속성들이나 이벤트 등도 서버 컨트롤의 HTML 속성의 일부로 렌더링되어야만 하므로 이러한 부분들도 같이 고려되어져야만 하는 것이다.
물론 ASP .NET 의 웹 사용자 지정 서버 컨트롤 개발을 위한 기반 구조에서는 우리들의 기대에 어긋나지 않게 이러한 작업들을 처리하기 위한 탄탄한 방법들을 제공해주므로 이를 충실하게 구현해주기만 하면 원하는 결과를 그다지 어렵지 않게 얻을 수 있다.
구체적으로 말해서 AddAttributesToRender() 메서드를 재정의해주기만 하면 되는데, 이 메서드는 WebControl 클래스로부터 상속되며 서버 컨트롤의 HTML 태그에 렌더링되어질 HTML 속성 또는 케스케이딩 스타일시트 속성을 추가할 수 있는 보장된 기회를 제공해준다.
아래의 코드가 바로 그 실제 결과물이다.
...
/// <summary>
/// WebControl.AddAttributesToRender 메서드 재정의
/// </summary>
/// <param name="writer">
/// 클라이언트에서 HTML 컨텐트를 렌더링하기 위한
/// 출력 스트림을 나타내는 System.Web.UI.HtmlTextWriter 개체
/// </param>
protected override void AddAttributesToRender(HtmlTextWriter writer)
{
// HTCs 모드로 동작되는 경우에만 속성값을 추가한다.
if (this.HTCs != HTCsType.NotSet)
{
if (this.HTCs == HTCsType.Numeric)
{
// 스타일 속성값에 HTC 설정
System.Reflection.Assembly objAssembly
= System.Reflection.Assembly.GetExecutingAssembly();
if (this.Site == null || !this.Site.DesignMode)
writer.AddStyleAttribute("behavior",
"url('" + this.ClientScriptsLocation()
+ "HTCs_Numeric_Only_" + objAssembly.GetName().Version
+ ".htc')");
// defaultValue 속성값 설정
if (HTCsDefaultValue != null && HTCsDefaultValue.Trim().Length > 0)
writer.AddAttribute("defaultValue", this.HTCsDefaultValue.Trim());
}
}
base.AddAttributesToRender(writer);
}
...
리플렉션을 통해서 어셈블리의 버전 정보를 읽고, 그 버전 정보를 바탕으로 HTCs 의 전체 파일경로를 구성한 다음 HtmlTextWriter 개체로부터 제공되는 AddStyleAttribute() 메서드를 사용하여 케스케이딩 스타일시트 속성에 HTCs 관련 설정을 반영시키고 있다.
그리고 역시 비슷한 방법으로 AddAttribute() 메서드를 사용해 렌더링되어질 서버 컨트롤의 HTML 태그에 HTCs 에 구현된 속성을 추가하고 있다.
그 결과로서 생성되는 HTML 태그는 다음과 같으며, 사실상 이 HTML 태그가 본문의 최종 결과물인 셈이다.
이렇게 해서 장장 10 개월 동안을 끌어오던 본문의 작성이 마무리 되었다.
본문의 내용 그 자체도 여러모로 미흡한 부분들이 많거니와 너무나도 오랜 기간 동안 작성된 관계로 최근에 화제가 되고 있는 다양한 기술적인 이슈들과는 상당히 동떨어진 주제가 되어버린 감도 없지는 않을 것이다.
그러나 본문에서 논의하고 있는 이슈들 또한 그 나름대로 의미를 가지고 있는 글이라고 생각하여 뒤늦게나마 급하게 글을 마무리하게 되었다.
마지막으로 그 10 개월이라는 시간이 필자와 여러분들을 비롯한 ASP .NET 개발자들에게 가져온 변화에 대해서 한 번 생각해 보고서 본문을 정리하고자 한다.
먼저 개인적으로 필자가 가장 먼저 손꼽고 싶은 변화로는 파이어폭스의 약진을 들 수 있다.
물론 파이어폭스는 등장 그 자체부터가 매우 화려하기도 했지만, 최근 몇 달간 이루어진 파이어폭스의 존재감 확산은 웹 개발자들이 결코 무시할 수 없는 수준으로까지 치달았다라는 개인적인 결론이다.
단적으로 최근의 MSDN 매거진의 기사에서는 기사에서 작성한 자바스크립트 코드가 파이어폭스에서 정상적으로 동작함을 보여주기 위한 이미지 캡춰까지 나올 정도니 말이다.
아직까지는 이와 같은 일련의 변화들이 기업체의 솔루션 구축을 주요 업무로 삼고 있는 필자와 같은 개발자들에게까지는 별다른 영향력을 미치고 있지 못하고 있다라고 생각하고는 있지만,
HTCs 개발이나 ASP .NET 웹 사용자 지정 컨트롤 개발과 같이 전체 개발 범위상에서 어떠한 공통 분모를 담당하고 있는 개발자들이라면
지금까지보다 상대적으로 고민해야만 될 이슈들이 조금 더 늘어났으며, 게다가 조금 더 민감해지기까지 했다는 점을 인정할 수 밖에 없을 것이다. 따라서 본문의 주제이기도 하며 본문에서 계속해서 거론되어지고 있는 HTCs 라는 단어를 웹 브라우저 호환 자바스크립트라는 단어로 대신해야만 하는 경우도 충분히 있을 수 있을 것이다.
그런데 개인적으로 상당히 재미있다고 느껴지는 점은 필자가 두 번째 커다란 변화로 지목하고자 하는 마이크로소프트 비주얼 스튜디오 2005 의 정식출시와
그에 따라 점진적으로 증가되는 ASP .NET 2.0 의 도입추세야말로 ASP .NET 개발자들이 앞에서 거론되었던 변화에 대처하기 위해서 시도할 수 있는 가장 적극적인 방법의 시작점이 아닌가 하는 점이다.
물론 이와 같은 주장은 지극히 개인적인 필자의 사견일 뿐이지만, 나름대로 필자가 이렇게 생각을 하고 있는 이유에는 다음과 같은 두 가지 기술적인 근거가 존재한다.
첫 번째 근거는 ASP .NET 2.0 에서 제공되는 리소스 기반의 스크립트 코드 관리다.
본문의 후반부에서 논의하고 있는 주제는 필자가 나름대로 구현한 리소스 기반의 스크립트 (포괄적인 관점에서 HTCs 역시도 스크립트이므로) 관리 기법에 관한 것인데, ASP .NET 2.0 에서는 프레임워크 차원에서 리소스에 기반한 스크립트 코드 관리 기법을 보다 풍부하고 편리한 방법으로 제공해주고 있다.
따라서 본문에서 살펴봤던 바와 같이 리소스로부터 스크립트 코드를 가져오기 위해 굳이 이런저런 방법을 동원하여 난해한 코드를 일일이 구현할 필요가 없어진 것이다.
두 번째 근거는 코드명 ATLAS 로 잘 알려진 마이크로소프트의 AJAX 프레임워크가 바로 그것이다.
대부분 많은 분들이 AJAX 를 기술적인 관점에서 살펴볼 때 한 가지 간과하고 넘어가는 부분이 있다.
분명히 이 기술을 뒷받침해주는 핵심 요소중 한 가지가 페이지를 갱신하지 않고서도 서버단과 동기적, 또는 비동기적으로 데이터를 주고 받게 해주는 매커니즘이라는 사실을 부인할 수 있는 사람은 아무도 없을 것이다.
그러나 이러한 서버단과의 통신이라는 측면이 너무 강조된 나머지 페이지 렌더링을 위해서 필요한 DOM 과 스크립트단 구현에 대한 중요성이 무시되어지는 경향이 매우 강하다는 점이다.
이 부분이 만족스럽게 지원되지 않는다면 AJAX 는 또 다른 형태의 업무 증가만을 가져올 뿐이라는 것이 필자의 생각이다.
그러나 다행스럽게도 마이크로소프트에서 구현한 AJAX 라이브러리인 ATLAS 에서는 객체지향적인 방법으로 대부분의 웹 브라우저상에서 동일한 방법으로 클라이언트단 처리를 구현할 수 있도록 지원해주는 클라이언트 자바스크립트 라이브러리를 지원해주므로 웹 개발자가 크로스 브라우징을 위해 커다란 노력을 기울이지 않더라도 고품질의 결과물을 얻을 수 있게 해준다.
아직까지 ATLAS 가 정식으로 배포되지는 않은 상황이고, 필자의 ATLAS 에 대한 지식도 매우 부족한 편이기는 하지만 감히 단언컨데 행복한 기대를 해도 좋을 것이라고 믿는다.
宋
강좌 최초 작성일 : 2006년 05월 27일
