본 발명은 마크업 내부에서 명시적으로 서브클래스를 정의하고, 확장하며, 이용하는 시스템 및 방법을 가리킨다. 본 발명은 마크업 언어를 이용해서 개발자가 콤포넌트를 구축, 확장, 및 이용하는 메커니즘을 제공한다. 이들 콤포넌트는 재사용가능 콤포넌트, 애플리케이션 사용자 인터페이스, 문서 사용자 인터페이스 등을 포함한다. 그 메커니즘은 개발자에게 프로그래밍 언어를 인식할 것을 요구하지 않는다. 그 대신, 그 메커니즘은 개발자로 하여금 XML(확장성 마크업언어)과 같은 친숙한 마크업 언어를 이용하여 콤포넌트를 구축할 수 있게 한다. XML은 습득하기가 매우 용이하고 범용 컴퓨터 프로그래밍 커뮤니티에서 점점 친숙해지고 있기 때문에, 본 발명은 종래 프로그래밍 언어들을 이용하는 것보다 여러 이점들을 제공한다. 하나의 이점은 마크업 텍스트와 함께 마크업 문서 내에서 콤포넌트가 정의될 수 있어서 매우 정교한 전자문서를 생성할 수 있다는 점이다. 다른 이점은 개발자들이 실행가능 콤포넌트를 생성하기 위해서 어떠한 프로그래밍 언어를 인식하거나 이해할 필요가 없다는 점이다.
본 발명의 시스템, 방법, 및 데이터 구조는 서브클래스 관련 실행가능 어셈블리어가 마크업 문서 내부에서 기재된 서브클래스 정의로부터 생성될 수 있게 한다. 본 발명에 따라서, 서브클래스 정의는 스키마에 기초하여 기재된다. 그 스키마는 XML에 기초할 수 있다. 그 스키마는 서브클래스에 대한 네임(name)을 정의하는 서브클래스 태그를 구비한다. 그 네임은 실행가능 어셈블리어가 실행될 때 인스턴스화되는 오브젝트에 대한 유형에 관련된다. 그 스키마는 프로그래밍 언어를 규정하여 서브클래스 정의를 컴파일하는 것, 서브클래스가 유도되는 수퍼클래스를 규정하는 것, 오브젝트가 인스턴스화될 때 수행하는 동작들을 규정하는 것, 그 서브클래스에 대한 이벤트 정의 및 관련 이벤트핸들러를 생성하는 것, 및 오브젝트가 인스턴스화될 때 그 오브젝트 내의 필드가 되는 특성을 규정하는 것과 같은 하나 이상의 힌트를 더 포함한다.
본 발명은 마크업 문서 내부에서 명시적으로 서브클래스를 정의하고, 확장하며, 이용하는 시스템 및 방법을 가리킨다. 본 발명은 개발자에게 마크업 언어를 이용해서 콤포넌트를 구축하고, 확장하며, 이용하는 메커니즘을 제공한다. 그 메커니즘은 개발자에게 프로그래밍 언어를 인식할 것을 요구하지 않는다. 그 대신, 그 메커니즘은 개발자가 확장성 마크업 언어(XML)와 같은 친숙한 마크업 언어를 이용하여 콤포넌트를 생성할 수 있게 한다.
본 발명의 제1 형태에 의하면, 컴퓨터로 판독가능한 데이터 구조로 부호화되는 유형 콤포넌트를 갖는 컴퓨터 판독가능 매체로서, 상기 데이터 구조는: 마크업 문서 내 서브클래스 정의를 선언적으로 정의하기 위한 스키마를 포함하고, 상기 스키마는 실행가능 어셈블리어로 컴파일될 수 있고 - 상기 실행가능 어셈블리어는 상기 어셈블리어의 실행 시 상기 서브클래스 정의 내에 정의된 서브클래스와 관련되는 오브젝트를 인스턴스화함 -, 상기 실행가능 어셈블리어가 프로그래밍 언어와 무관하게 컴파일되도록, 상기 실행가능 어셈블리어는 상기 어셈블리어를 생성하는데 원래 이용된 상기 프로그래밍 언어와 독립적인, 컴퓨터 판독가능 매체가 제공된다.
본 발명의 제1 형태에 있어서, 상기 스키마는 확장성 마크업 언어(XML) 기반 스키마일 수 있다.
본 발명의 제1 형태에 있어서, 상기 스키마는 네임을 정의하기 위한 서브클래스 태그를 포함하고, 상기 네임은 인스턴스화되는 상기 오브젝트의 유형에 연관될 수 있다.
본 발명의 제1 형태에 있어서, 상기 스키마는 상기 서브클래스 정의의 컴파일시 이용되는 프로그래밍 언어를 특정하기 위한 언어 힌트를 포함할 수 있다.
본 발명의 제1 형태에 있어서, 상기 스키마는 상기 마크업 문서 내 코드를 서술하는 코드 힌트를 더 포함하고, 상기 코드는 상기 실행가능 어셈블리어로 직접 컴파일될 수 있다.
본 발명의 제1 형태에 있어서, 상기 코드는 상기 언어 힌트에 특정된 상기 프로그래밍 언어의 신택스(syntax)에 기초하여 직접 컴파일될 수 있다.
본 발명의 제1 형태에 있어서, 상기 스키마는 상기 서브클래스가 유도되는 수퍼클래스를 특정하기 위한 수퍼클래스 태그를 포함할 수 있다.
본 발명의 제1 형태에 있어서, 상기 스키마는 상기 수퍼클래스가 존재하는 네임스페이스를 특정하기 위한 수퍼클래스 네임스페이스 속성을 포함할 수 있다.
본 발명의 제1 형태에 있어서, 상기 스키마는 상기 서브클래스를 특정하기 위한 서브클래스 태그를 포함할 수 있다.
본 발명의 제1 형태에 있어서, 상기 스키마는, 상기 오브젝트가 인스턴스화될 때 수행되는 하나 이상의 추가 동작을 특정하기 위한 컨스트럭터 힌트를 포함할 수 있다.
본 발명의 제1 형태에 있어서, 상기 스키마는 이벤트와, 인스턴스화 시 상기 오브젝트와 관련되게 되는 대응 이벤트 핸들러를 특정하기 위한 이벤트 힌트를 포함할 수 있다.
본 발명의 제1 형태에 있어서, 상기 스키마는 특성을 특정하는 특성 힌트를 포함하고, 상기 특성은 상기 오브젝트가 인스턴스화되는 경우 상기 오브젝트 내 멤버가 될 수 있다.
본 발명의 제1 형태에 있어서, 상기 스키마는 상기 서브클래스의 차일드 요소(child element)를 특정하기 위한 요소 선언을 포함할 수 있다.
본 발명의 제2 형태에 의하면, 서브클래스에 대한 실행가능 어셈블리어를 생성하기 위한 명령어를 포함하는 유형 콤포넌트를 갖는 컴퓨터 판독가능 매체로서, 상기 명령어는 마크업 문서 내에서 서브클래스 정의를 식별하는 단계 - 상기 서브클래스 정의는 서브클래스를 정의함 -; 및 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계 - 상기 어셈블리어는 상기 서브클래스와 연관되는 오브젝 트의 인스턴스를 생성하기 위하여 실행될 수 있음 - 를 포함하고, 생성된 어셈블리어는, 상기 생성된 어셈블리어가 프로그래밍 언어와 무관하게 컴파일되도록, 상기 어셈블리어를 생성하는데 원래 이용된 상기 프로그래밍 언어와 독립적인, 컴퓨터 판독가능 매체가 제공된다.
본 발명의 제2 형태에 있어서, 상기 서브클래스 정의를 식별하는 단계는 서브클래스 태그를 분석하는 단계를 포함하고, 상기 서브클래스 태그는 네임을 정의하기 위한 서브클래스 네임 속성을 포함하며, 상기 네임은 인스턴스화되는 상기 오브젝트의 유형과 연관될 수 있다.
본 발명의 제2 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는, 상기 어셈블리어로 컴파일되는 대표 소스코드로 상기 서브클래스 정의를 컴파일하는 단계를 포함할 수 있다.
본 발명의 제2 형태에 있어서, 상기 대표 소스코드는 프로그램 언어를 기초로 할 수 있다.
본 발명의 제2 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 서브클래스 정의 내의 코드를 상기 어셈블리어로 컴파일하는 단계를 포함하고, 상기 코드는 코드 힌트에 의하여 상기 서브클래스 정의 내 서술될 수 있다.
본 발명의 제2 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 서브클래스가 유도되는 수퍼클래스를 정의하는 수퍼클래스 태그를 분석하는 단계, 프로그램 언어와 연관된 신택스를 이용하여 계 승(inheritance)을 특정하는 단계, 및 상기 어셈블리어의 일부가 되도록 상기 신택스를 컴파일하는 단계를 포함할 수 있다.
본 발명의 제2 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 오브젝트가 인스턴스화될 때 수행되는 하나 이상의 추가 동작을 정의하는 컨스트럭터 힌트를 분석하는 단계를 포함하고, 상기 추가 동작은 상기 어셈블리어의 일부일 수 있다.
본 발명의 제2 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 서브클래스에 대한 이벤트 정의 및 대응 이벤트 핸들러를 생성하는 이벤트 힌트를 분석하는 단계를 포함할 수 있다.
본 발명의 제2 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 오브젝트가 인스턴스화될 때 상기 오브젝트 내의 멤버가 되는 특성을 정의하는 특성 힌트를 분석하는 단계를 포함할 수 있다.
본 발명의 제2 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 서브클래스의 차일드 요소를 식별하는 요소 선언 태그를 분석하는 단계를 포함할 수 있다.
본 발명의 제3 형태에 의하면, 적어도 부분적으로 컴퓨팅 장치에 의하여 구현되는, 실행가능 어셈블리어를 생성하기 위한 방법으로서, 마크업 문서 내에서 서브클래스 정의를 식별하는 단계 - 상기 서브클래스 정의는 서브클래스를 정의함 -; 및 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계 - 상기 어셈블리어는 상기 서브클래스와 연관되는 오브젝트의 인스턴스를 생성하기 위하여 실행될 수 있음 - 를 포함하고, 생성된 어셈블리어는 상기 생성된 어셈블리어가 프로그래밍 언어와 무관하게 컴파일되도록, 상기 어셈블리어를 생성하는데 원래 이용된 상기 프로그래밍 언어와 독립적인, 방법이 제공된다.
본 발명의 제3 형태에 있어서, 서브클래스 정의를 식별하는 단계는 서브클래스 태그를 분석하는 단계를 포함하고, 상기 서브클래스 태그는 네임을 정의하기 위한 서브클래스 네임 속성을 포함하며, 상기 네임은 인스턴스화되는 상기 오브젝트의 유형과 연관될 수 있다.
본 발명의 제3 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 서브클래스가 유도되는 수퍼클래스를 정의하는 수퍼클래스 태그를 분석하는 단계, 프로그램 언어에 기초한 신택스를 이용하여 계승을 특정하는 단계, 및 상기 어셈블리어의 일부가 되도록 상기 신택스를 컴파일하는 단계를 포함할 수 있다.
본 발명의 제3 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 오브젝트가 인스턴스화될 때 수행되는 하나 이상의 추가 동작을 정의하는 컨스트럭터 힌트를 분석하는 단계를 포함하고, 상기 추가 동작은 상기 어셈블리어의 일부일 수 있다.
본 발명의 제3 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 서브클래스에 대한 이벤트 정의 및 대응 이벤트 핸들러를 생성하는 이벤트 힌트를 분석하는 단계를 포함할 수 있다.
본 발명의 제3 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어 를 생성하는 단계는 상기 오브젝트가 인스턴스화될 때 상기 오브젝트 내의 멤버가 되는 특성을 정의하는 특성 힌트를 분석하는 단계를 포함할 수 있다.
본 발명의 제3 형태에 있어서, 서브클래스에 대한 실행가능 어셈블리어를 생성하기 위한 명령어를 포함하는 유형 콤포넌트를 갖는 컴퓨터 판독가능 매체로서, 상기 명령어는 본 발명의 제3 형태의 방법을 수행할 수 있다.
본 발명의 제4 형태에 의하면, 마크업 문서를 이용해 서브클래스 정의로부터 어셈블리어를 생성하기 위한 컴퓨터 시스템으로서, 프로세서 및 메모리를 포함하고, 상기 메모리에는 상기 메모리에 로딩되는 복수의 컴퓨터 실행가능 명령어가 할당되며, 상기 프로세서는, 마크업 문서 내에서 서브클래스 정의를 식별하는 단계 - 상기 서브클래스 정의는 서브클래스를 정의함 -; 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계 - 상기 어셈블리어는 상기 서브클래스와 연관되는 오브젝트의 인스턴스를 생성하기 위하여 실행될 수 있고, 생성된 어셈블리어는, 상기 생성된 어셈블리어가 프로그래밍 언어와 무관하게 컴파일되도록, 상기 어셈블리어를 생성하는데 원래 이용된 상기 프로그래밍 언어와 독립적임 - 를 수행하는 상기 명령어를 실행하는, 컴퓨터 시스템이 제공된다.
본 발명의 제4 형태에 있어서, 상기 서브클래스 정의를 식별하는 단계는 서브클래스 태그를 분석하는 단계를 포함하고, 상기 서브클래스 태그는 네임을 정의하기 위한 서브클래스 네임 속성을 포함하며, 상기 네임은 인스턴스화되는 상기 오브젝트의 유형과 연관될 수 있다.
본 발명의 제4 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어 를 생성하는 단계는 상기 오브젝트가 인스턴스화될 때 수행되는 적어도 하나의 추가 동작을 정의하는 컨스트럭터 힌트를 분석하는 단계를 포함할 수 있다.
본 발명의 제4 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 서브클래스에 대한 이벤트 정의 및 대응 이벤트 핸들러를 생성하는 이벤트 힌트를 분석하는 단계를 포함할 수 있다.
본 발명의 제4 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하는 단계는 상기 오브젝트가 인스턴스화될 때 상기 오브젝트 내의 멤버가 되는 특성을 정의하는 특성 힌트를 분석하는 단계를 포함할 수 있다.
본 발명의 제5 형태에 의하면, 실행가능 어셈블리어를 생성하기 위한 시스템으로서, 마크업 문서 내에서 서브클래스 정의를 식별하기 위한 수단 - 상기 서브클래스 정의는 서브클래스를 정의함 -; 및 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하기 위한 수단 - 상기 어셈블리어는 상기 서브클래스와 연관되는 오브젝트의 인스턴스를 생성하기 위하여 실행될 수 있음 -을 포함하고, 생성된 어셈블리어는, 상기 생성된 어셈블리어가 프로그래밍 언어와 무관하게 컴파일되도록, 상기 어셈블리어를 생성하는데 원래 이용된 상기 프로그래밍 언어와 독립적인, 시스템이 제공된다.
본 발명의 제5 형태에 있어서, 상기 서브클래스 정의를 식별하기 위한 상기 수단은 서브클래스 태그를 분석하기 위한 수단을 포함하고, 상기 서브클래스 태그는 네임을 정의하기 위한 서브클래스 네임 속성을 포함하며, 상기 네임은 인스턴스화되는 상기 오브젝트의 유형과 연관될 수 있다.
본 발명의 제5 형태에 있어서, 상기 서브클래스 정의를 식별하기 위한 상기 수단은 상기 서브클래스가 유도되는 수퍼클래스를 정의하는 수퍼클래스 태그를 분석하기 위한 수단, 프로그램적 언어와 관련된 신택스를 이용하여 계승을 특정하기 위한 수단, 및 상기 어셈블리어의 일부가 되도록 상기 신택스를 컴파일하기 위한 수단을 포함할 수 있다.
본 발명의 제5 형태에 있어서, 상기 서브클래스 정의에 기초하여 어셈블리어를 생성하기 위한 상기 수단은 상기 오브젝트가 인스턴스화되는 경우 수행되는 하나 이상의 추가적인 동작을 정의하는 컨스트럭터 힌트를 분석하기 위한 수단을 포함하고, 상기 추가적인 동작은 상기 어셈블리어의 일부일 수 있다.
예시적인 컴퓨팅 환경
도 1은 본 발명의 예시적인 구현에서 사용될 수 있는 예시적인 컴퓨팅 장치를 나타낸다. 도 1을 참조하면, 매우 기본적인 구성에서, 컴퓨팅 장치(100)는 통상 하나 이상의 처리유닛(102)과 시스템 메모리(104)를 구비한다. 컴퓨팅장치(100)의 정확한 구성과 유형에 따라서, 시스템 메모리(104)는 휘발성(RAM 등), 비휘발성(ROM, 플래시 메모리 등) 또는 이 둘을 결합한 것일 수 있다. 시스템 메모리(104)는 통상 운영체제(105), 하나 이상의 프로그램모듈(106)을 구비하며, 프로그램 데이터(107)를 구비할 수 있다. 프로그램 모듈(106)의 일실시예는 브라우저 애플리케이션, 회계관리 애플리케이션, 워드프로세서 등을 포함한다. 이 기본 구성이 도 1에서는 점선(108)내의 컴포넌트들에 의해 나타낸다.
컴퓨팅 장치(100)는 부가적인 특징 및 기능을 가질 수 있다. 예를 들면, 컴퓨팅 장치(100)는 예를 들면, 자기디스크, 광디스크, 또는 테이프와 같은 추가적인 데이터 스토리지 장치(분리형 및/또는 비분리형)를 또한 구비할 수 있다. 이러한 추가적인 스토리지는 도 1에서는 분리형 스토리지(109) 및 비분리형 스토리지(110)에 의해 나타낸다. 컴퓨터 저장매체는 컴퓨터 판독가능 명령, 데이터구조, 프로그램 모듈, 또는 기타 데이터 등의 정보 저장을 위한 임의의 방법 또는 기술에서 구현되는 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 구비할 수 있다. 시스템 메모리(104), 분리형 스토리지(109) 및 비분리형 스토리지(110)는 모두 컴퓨터 저장매체의 실시예들이다. 컴퓨터 저장매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리기술, CD-ROM, 디지털 다용도 디스크(DVD) 또는 다른 광 스토리지, 자기 카세트, 자기 테이프, 자기 디스크스토리지 또는 다른 자기저장매체, 또는 원하는 정보를 저장하는데 사용될 수 있고 컴퓨팅 장치(100)에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만 이에 한정되지는 않는다. 이러한 임의의 컴퓨터 저장매체는 장치(100)의 일부일 수 있다. 또한, 컴퓨팅 장치(100)는 키보드, 마우스, 펜, 음성입력장치, 접촉식 입력장치 등과 같은 입력장치(들)(102)를 가질 수 있다. 또한, 디스플레이, 스피커, 프린터 등과 같은 출력장치(들)(114)도 포함될 수 있다. 이들 장치들은 당업계에 매우 잘 알려져 있기 때문에, 여기서 상세히 설명하지는 않는다.
또한, 컴퓨팅 장치(100)는 네트워크와 같이 장치가 다른 컴퓨팅장치(118)와 통신할 수 있게 하는 통신접속(116)을 포함할 수 있다. 통신접속(116)은 통신매체 의 일실시예이다. 통상, 통신매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈, 또는 반송파 혹은 다른 전송메커니즘과 같은 피변조 데이터신호의 다른 데이터에 의해 구체화되며 임의의 정보전달매체를 포함할 수 있다. "피변조 데이터신호"라는 용어는 신호에서 정보를 부호화하는 방식으로 하나 이상의 특성이 설정되거나 변경되게 하는 신호를 의미한다. 예를 들면 -한정이 아닌- 통신매체는 유선 네트워크 또는 직접 유선접속과 같은 유선매체 및 음향, RF, 적외선 및 다른 무선매체와 같은 무선매체를 구비한다. 여기서 사용되는 컴퓨터 판독가능 매체라는 용어는 저장매체와 통신매체 양자를 모두 포함한다.
예시적인 구현
도 2 는 본 발명의 일실시형태를 구현하는 개발시스템을 주로 나타내는 기능블록도이다. 그 시스템은 마크업 컴파일러(202)와 분석기(204)를 구비한다. 마크업 컴파일러(202)와 분석기(204)는 도 1에 나타낸 컴퓨팅 장치(100)와 같은 컴퓨팅 장치에 있을 수 있는 소프트웨어 모듈(예를 들면, 도 1에 나타낸 프로그램 모듈(106))이다. 마크업 컴파일러(202)는 마크업 문서(206)를 입력한다. 일실시형태에서, 마크업 문서(206)는 확장성 마크업언어 (XML) 기반 문서이다. 간단히 말하면, 도 4 내지 도 6에서 나타내고 이하 설명되는 마크업 문서(206)는 서브클래스 정의의 일부를 표시하는 태그(도시 생략)를 구비한다. 이하 상세히 설명하는 바와 같이, 그 태그는 서브클래스 및 관련 콤포넌트의 존재를 표시한다. 마크업 컴파일러(202)가 이들 태그들과 마주치면, 서브클래스를 구축하기 위해서 분석기(204)와 통신을 개시한다.
일실시형태에서, 분석기(204)에 의해 제공되는 기능은 마크업 컴파일러(202) 내부에서 제공될 수 있다. 다른 실시형태에서는, 분석기(204)에 의해 제공되는 기능이 마크업 컴파일러(202) 내에서 기존 분석기클래스로부터 분석 클래스를 유도함으로써 제공될 수 있다. 그 유도된 분석클래스는 본 발명에 따라서 정의된 서브클래스 토큰(즉, 태그) 각각에 대하여 함수 오버라이드(override)를 구비할 수 있다. 간단히 말하면, 도 10에 도시되고 이하 상세히 설명되는 함수 오버라이드는 서브클래스와 관련된 콤포넌트들의 정의에 대한 개시와 종료를 알리는 일련의 콜백(callback) 함수의 일부일 수 있다.
분석기(204)는 마크업 문서(206) 내에서 서브클래스 정의를 분석하도록 구성된다. 간단히 말하면, 마크업 컴파일러(202)는 마크업문서(202) 내의 컨텐츠를 컴파일한다. 일실시형태에서, 마크업 컴파일러(202)는 토큰화된 이진파일(208)에 저장되는 토큰화된 이진 스트림으로 컨텐츠를 변경한다. 그 토큰화된 이진파일(208)은 당업자에게 알려진 여러 형태들 중의 하나일 수 있다. 그 토큰화된 이진파일(208)은 마크업 문서(206)에 규정된 콤포넌트의 트리를 나타낸다. 그러나, 마크업 컴파일러(202)는 컨텐츠 중의 일부를 직접 변환시킬 수 없기 때문에, 이 컨텐츠는 분석기(204)에 전송될 수 있다. 본 발명에 따른 마크업 문서(206) 내의 서브클래스 정의는 이러한 컨텐츠의 일 예이다. 분석기(204)는 서브클래스 정의 내의 특성, 이벤트 등을 식별하여 이들 아이템들에 관한 영구적인 정보를 마크업 컴파일러(202)로 중계한다.
그 영구적인 정보의 수신시, 마크업 컴파일러(202)는 서브클래스 정의에 관 련된 마크업 문서(206)에 토큰을 증가시킨다. 마크업 컴파일러(202)는 IL 어셈블리어(210)가 생성되는 대표 소스코드(representative source code)(212)를 또한 생성시킨다. IL 어셈블리어(210)는 마크업 문서(206)내에서 정의되는 서브클래스들(예를 들면, 콤포넌트)에 대한 컴퓨터 명령을 포함한다. 종래에는, 이들 IL 어셈블리어는 프로그래밍 언어를 이용하여 기재되는 소스코드를 컴파일하고 링크하는 소프트웨어 개발툴을 이용하여 생성되었다. 또한, 당업자는 다른 실시형태에서 마크업 컴파일러(202)가 토큰화된 이진파일(208)을 생성시키지 않고 IL 어셈블리어(210)를 생성할 수도 있다는 것을 인식할 것이다.
마크업 컴파일러(202)에 의해 생성되는 IL 어셈블리어(210)는 종래 프로그래밍 개발툴에 의해 재사용될 수 있다. 또한, 그 IL 어셈블리어(210)는 다른 마크업 문서에서도 재사용될 수 있다. 마크업 문서에서 IL 어셈블리어(210)를 재사용하는 특성은 도 7에 도시되며 여기서 결합하여 개시된다. 따라서, 본 발명은 콤포넌트 개발자들이 마크업 언어를 이용하여 콤포넌트를 용이하게 구축하고 확장하도록 할 수 있다. 일단 본 발명에 따라서 새로운 콤포넌트가 구축되면, 그 새로운 콤포넌트는 종래 프로그래밍 언어를 이용하여 구축된 것처럼 보인다. 따라서, 이러한 본 발명의 메커니즘과 방법을 이용하여 개발자들은 하나 이상의 프로그래밍 언어의 구문과 뉘앙스를 습득하지 않고서도 콤포넌트를 구축할 수 있다.
도 3은 본 발명의 일실시형태를 구현하는 런타임 환경을 주로 도시하는 기능블록도이다. 그 런타임 환경은 런타임 엔진(302), 토큰화된 이진판독기(304), 및 토큰화된 이진로더(306)를 구비한다. 런타임 엔진(302)이 특정 자원(예를 들면, 도 2에 나타낸 마크업문서)을 로딩하는 요청을 수신하면, 그 런타임 엔진(302)은 페이지맵 테이블(308)을 액세스한다. 그 페이지맵 테이블(308)은 마크업 문서(206)가 컴파일된 버전(예를 들면, 토큰화된 이진파일; 208)인지를 식별한다. 만약 컴파일된 버전이 존재하면, 런타임 엔진(302)은 토큰화된 이진파일(208)과 통신하여 그 토큰화된 이진파일(208)을 로드한다. 일실시형태에서, 그 토큰화된 이진파일(208)은 토큰화된 이진파일(208)과 관련된 IL 어셈블리어(예를 들면, IL 어셈블리어(210))를 식별한다. 그 후, 토큰화된 이진로더(306)는 식별된 IL 어셈블리어(210)를 로드한다. 일단 토큰화된 이진파일(208)의 전체 또는 일부와 그 관련 IL 어셈블리어(210)가 로드되면, 토큰화된 이진판독기(304)는 토큰화된 이진파일(208)과 IL 어셈블리어(210)의 판독을 개시하여, 프로세서(예를 들면, 도 1에 나타낸 처리유닛(102)) 상에서 실행되는 네이티브 명령을 생성시킨다. 토큰화된 이진판독기(304)는 메타데이터(310)에 액세스하여 유형, 메소드, 및 이벤트와 같은 정보를 판단할 수 있다. 일반적으로, 메타데이터(310)는 메소드, 필드, 속성, 및 이벤트에 대한 정보를 포함한다. 이들 항목 각각이 부가적인 세부사항들을 판독해낼 수 있는 자체 메타데이터를 가진다. 따라서, 메타데이터(310)를 이용하면, 토큰화된 이진판독기(304)는 런타임동안 리플렉션(reflection)을 이용하여 토큰화된 이진파일(208) 내의 요소에 관한 정보를 프로그램적으로 판단한다. 또한, 이하 상세히 설명되는 바와 같이, 마크업 문서(206)에서 원시 정의되는 서브클래스는 본 발명에 따라서 생성되는 IL 어셈블리어(210)를 이용해서 직접 실행될 수도 있다.
도 4 내지 도 6은 본 발명의 일실시형태에 따라서 서브클래스를 명시적으로 정의하기 위한 예시적인 구문을 나타내는 마크업 문서(206) 내에서의 마크업의 일련의 특징부를 도시한다. 도 10은 도 4 내지 도 6에 나타낸 마크업의 특징부에 기초하여 마크업 컴파일러(202)가 생성되는 대표 소스코드를 도시하는 예시적인 소스코드 리스팅이다. 일실시형태에서, 마크업 컴파일러(202)는 실제 대표 소스코드를 포함하는 파일을 생성시킬 수 있다. 이는 개발자가 디버그 플래그를 설정할 때 발생할 수 있다. 대표 소스코드를 포함하는 파일은 개발자들로 하여금 마크업 문서(206)내의 텍스트에서 가능한 문제점과 마크업 컴파일러(202) 내에서의 문제점들을 판단할 수 있게 한다. 다른 실시형태에서, 대표코드는 파일 내부에 저장되지 않을 수도 있다. 이러한 실시형태에서는, 마크업 컴파일러(202)가 대표 소스코드를 우선 생성시키거나 생성시키지 않고서도 토큰화된 이진파일(208)과 IL 어셈블리어(210)를 생성시킬 수 있다.
개략적으로, 도 4 내지 도 6에서 본 발명에 따른 마크업 내에서 명시적으로 서브클래스를 정의하는 여러 태양을 설명한다. 도 4는 서브클래스 계층과 서브클래스를 정의하는 예시적인 구문을 도시한다. 도 5는 그 서브클래스에 대한 식별자, 코드 및 컨스트럭터(constructor)를 정의하는 예시적인 구문을 도시한다. 도 6은 그 서브클래스에 대한 특성과 이벤트를 정의하는 예시적인 구문을 도시한다. 이들 도면 각각은 이하 상세히 기재된다.
도 4는 서브클래스와 서브클래스 계층을 정의하는 예시적인 구문을 도시한다. 마크업(400)(예를 들면, 서브클래스 정의)의 특징부는 수퍼클래스 태그(402)(예를 들면, Button)를 구비한다. 다음 설명에서, 각각의 태그(예를 들면, 수퍼클래스 태그(402))는 대응 종료태그를 갖는다. 편의를 위해, 종료태그는 기재된 명세서에서는 명시적으로 참조되지 않지만, 관련 도면에서는 도시된다. 마크업(400)은 네임스페이스(namespace) 속성(attribute)(404), 정의 네임스페이스 선언(406), 및 여러 컴파일러 힌트(예를 들면, 힌트(408) 및 힌트(410))를 구비한다. 네임스페이스 속성(404)은 수퍼클래스(예를 들면, Button)가 위치되는 어셈블리어와 네임스페이스(예를 들면, "System.Control")를 식별한다. 정의 네임스페이스 선언(406)은 "def:" 접두어(prefix)를 포함하는 마크업(400) 내의 임의의 속성이 컴파일러가 행할 필요가 있는 동작에 관한 컴파일러에 대한 힌트를 나타냄을 나타낸다.
예를 들면, 힌트(408)(이하, 언어힌트(408)라 지칭함)는 그 언어힌트(408)에 할당된 언어(예를 들면, C#)를 이용하여 IL 어셈블리어를 생성하도록 컴파일러에 지시한다. 그 언어힌트(408)는 C, C++ 등과 같은 할당된 수개의 프로그래밍 언어들 중의 임의의 하나를 가질 수 있다. 힌트(410)(이하, def:Class 힌트(410)라 지칭함)는 그 def:Class 힌트에 할당되는 네임(예를 들면, MyButton)을 이용하여 서브클래스를 정의하도록 컴파일러에 지시한다. 그 def:Class 힌트(410)는 새로운 서브클래스가 관련되어야 할 네임스페이스(예를 들면, "MyControlLib")를 식별하는 서브클래스 네임스페이스(412)를 구비할 수도 있다. 따라서, 도 4에서는, 개발자가 "System.Controls" 네임스페이스에 위치되는 "Button" 클래스를 확장하는 "MyButton" 이라 명명된 새로운 서브클래스를 명시적으로 정의한다. 그 새로운 서브클래스는 "MyControlLIb" 네임스페이스에 관련될 것이다.
도 4에 도시된 마크업(400)에서는, 요소선언 태그(420)(예를 들면, "Image")가 정의된다. 특정 네임스페이스가 요소선언 태그(420) 내에서는 정의되지 않기 때문에, 네임스페이스 속성(404)은 또한 요소선언 태그(420) 관련 요소(예를 들면, "Image")에 대한 위치를 정의한다. 그 요소선언 태그(420)는 요소(421)와 소스 속성(422)을 구비한다. 소스속성(422)은 특성(property)(424)(예를 들면, "Source")과 값(426)(예를 들면, "HappyFace.jpg")을 구비한다. 요소선언 태그(420)는 "MyButton"으로서 정의되는 서브클래스에 대한 서브클래스 정의 내에 있기 때문에, 서브클래스가 인스턴스화되면 요소선언 태그(420)에 관련된 요소들이 인스턴스화될 것이다. 또한, 요소선언 태그(420)에 관련되는 요소들은 새로운 서브클래스의 차일드 모음(child collection) 내에 포함된다. 즉, 그 서브클래스는 요소선언 태그(420)에 관련된 요소들에 대한 부(parent)이다. 따라서, 컴파일러가 정의되어 있는 서브클래스(예를 들면, "MyButton")에 루트가 되는 요소 트리를 생성하는 것을 가능하게 하는 방식으로, 마크업(400)에 의해 개발자가 계층을 표현할 수 있음을 당업자는 인식할 것이다.
도 5는 서브클래스에 대한 식별자, 코드 및 컨스트럭터를 정의하는 예시적인 구문을 도시한다. 마크업(500)의 특징부는 식별자, 코드, 및 컨스트럭터를 정의하는 마크업 뿐만 아니라 상술한 마크업(400)도 포함한다. 가독성을 위해서, 도 4에 도시되고 상술한 참조부호들은 이들 새로운 태양을 설명하는데 유용하지 않다면 도 5에는 나타내지 않는다. 도 5에서는, 요소선언 태그(420)는 ID 속성(520) 및 이벤트 속성(526)과 같은 속성들을 더 포함한다. ID 속성(520)은 id 특성(521)(예를 들면, "ID")과 id 값(523)(예를 들면, "img1")을 포함한다. ID 속성(520)은 본 발명에 따른 서브클래스에 대한 식별자를 정의하는 예시적인 메커니즘을 도시한다.
이벤트 속성(526)은 이벤트 트리거(527)(예를 들면, "DataLodaded") 및 이벤트값(529)(예를 들면, "OnLoaded")을 구비한다. 그 이벤트 트리거(527)는 모니터되는 이벤트를 규정하며, 이벤트값(429)은 이벤트 트리거(527)가 발생할 때 실행되는 방법을 규정한다. 그 이벤트값(529)은 메소드(530)(예를 들면, "OnLoaded" 함수)에 관련된다. 그 메소드(530)는 프로그래밍 언어를 이용하여 기재될 수 있다. 메소드(530)는 마크업(500)에서 정의되는 클래스 및 서브클래스의 인스턴스들을 참조할 수 있다. 메소드(530)가 마크업 문서내의 프로그래밍 언어를 이용하여 기재될 때, 메소드(530)는 코드 힌트(540)에 관련된다. 그 코드힌트(540)는 개발자가 서브클래스 정의 몸체(body)에 코드 단편(snippet)을 더할 수 있게 한다. 일실시형태에서, 그 코드는 코드 힌트(540)를 뒤따르며, 호출가능 방법 또는 이벤트 핸들러이다. 마크업(500)에서, 예를 들면, OnLoaded 함수(530)는 이미지 제어에 의해 제기되는 DataLoaded 이벤트에 대한 이벤트 핸들러로서 기능한다. 또한, 다른 코드단편은 도 5 에 나타낸 CustomInit 함수(550)와 같은 서브클래스 정의의 몸체에 더해질 수 있다.
또한, 마크업(500)은 컨스트럭터 힌트(542)를 포함한다. 그 컨스트럭터 힌트(542)는 개발자가 서브클래스에 대하여 생성되는 기준 컨스트럭터를 보충하는 부가적인 컨스트럭터를 기입할 수 있게 한다. 일실시형태에서, 부가적인 컨스트럭터는 생성된 기준 컨스트럭터에 의해 실행되는 마지막 동작이다. 그 부가적인 컨스 트럭터는 구축시 서브클래스의 동작에 영향을 주는 코드를 포함할 수 있다. 개발자는 부가적인 컨스트럭터내에서 수퍼클래스의 컨스트럭터를 호출할 수 있다. 도 5에 나타낸 부가적인 컨스트럭터는 사용자정의된 전용(private) 메소드인 CustomInit 함수(550)를 호출한다.
도 6은 서브클래스에서의 특성과 이벤트를 정의하는 예시적인 구문을 도시한다. 마크업(600)의 특징부는 특성과 이벤트를 정의하는 마크업과 함께 상술한 마크업(400)과 마크업(500)을 포함한다. 가독성을 위해서, 도 4 내지 도 5에서 도시되고 상술한 참조부호는 이들 새로운 태양에서 유용하지 않다면 도 6에서는 나타내지 않는다.
마크업(600)은 특성들로 하여금 서브클래스에 대하여 정의될 수 있게 하는 특성 힌트(610)를 포함한다. 그 속성은 서브클래스의 멤버 변수로서 동작한다. 그 특성힌트(610)는 네임속성(612), 유형 속성(614), 기준값 속성(616), 및 플래그 속성(618) 등과 같은 하나 이상의 속성들을 포함할 수 있다. 네임 속성(612)은 그 특성에 대한 네임을 규정한다. 일실시형태에서, 네임들은 케이스에 의존하며 런타임 엔진은 네임에 대하여 이용되는 문자에 어떠한 제한도 두지 않는다. 네임은 그 네임을 등록한 소유자에게 고유하여야 한다. 유형 속성(614)은 특성의 값에 대한 유형을 규정한다. 그 유형은 instrinsic, user-defined, struct, class, interface, enum 등을 포함한다. 기준값은 그 특성이 인스턴스화될 때 할당되는 값을 규정한다. 플래그 속성(618)은 그 특성이 인스턴스화될 때 랩퍼(wrapper) 에 의해 생성되는 메소드들의 유형을 규정한다. 그 플래그들은 판독전용, 차일드 요 소에 상속가능, Private 등과 같은 특성의 특징을 제어할 수 있는 기능을 가질 수 있다.
또한, 마크업(600)은 이벤트 힌트(620)를 구비한다. 그 이벤트 힌트(620)는 이벤트가 서브클래스에 대하여 정의될 수 있게 한다. 그 이벤트 힌트(620)는 네임 속성(622), 라우트(route) 속성(624), 플래그 속성(626) 등과 같은 속성들을 구비할 수 있다. 네임 속성(622) 은 이 이벤트를 참조하는 스트링을 규정한다. xml 파일이 서브클래스를 이용할 때, xml 파일은 이 스트링을 사용하여 적절한 애플리케이션 개발자정의된 코드를 첨부한다. 라우트 속성(624)은 이 메소드를 규정하여, 이벤트를 제기하는 트리내의 요소들이 판단된다. 플래그 속성(626)은 그 이벤트와 관련되는 다른 특성들을 규정한다. 예를 들면, 마크업(600)에서, 마크업 컴파일러는 이벤트 호출된 DblClick을 가능하게 하는 코드를 생성하며, 라우팅 지원, 플래그와 같은 이벤트와 관련되는 정보를 포함할 수 있다. 당업자는 그 속성들에 관련된 네임과 값들이 본 발명의 범위를 벗어나지 않으면서 변형될 수 있음을 인식할 것이다.
또한, 마크업(600)은 이벤트 핸들러 선언(630)을 포함한다. 이벤트 핸들러 선언(630)은 public/private, delegate, return 유형등과 같은 관련 이벤트 핸들러 변형기(632)를 가질 수 있다. 도 6에서는, 이벤트 핸들러 선언(630)이 관련 이벤트가 발생할 때 호출되는 이벤트 핸들러(즉, 메소드)(예를 들면, "DblClickEventHandler")를 가질 수 있다.
또한, 다른 태그들도 마크업 문서 내에서 정의될 수 있다. 예를 들면, 루트 태그(예를 들면, "def:Library")가 컴파일러 및/또는 분석기에게 통보하여 별도 파일내에서 서브클래스를 정의하고, 한 개의 파일내에서 다른 서브클래스들과 함께 서브클래스를 정의하는 등을 행하는데 사용된다. 네임스페이스는 custom 요소, 루트 태그 내에서 정의된 모든 클래스 등에 대하여 선언될 수 있다.
도 7은 마크업 문서내로부터 서브클래스를 이용하기 위한 예시적인 구문을 설명하는 마크업 문서의 특징부를 도시한다. 마크업(700)은 루트 요소(702)(예를 들면, FlowPanel 요소), 기준 네임스페이스 선언(704), 정의 네임스페이스 접두어(706), 요소(708) 등을 구비한다. 요소(708)는 상기 규정된 구문을 이용하여 구축된 맞춤 콤포넌트를 참조할 수 있다. 그 기준 네임스페이스 선언(704)은 접두어없이 태그에 대한 기준 네임스페이스를 규정한다. 예시적인 마크업(700)에서, 기준 네임스페이스 선언(704)은 "System.Controls" 네임스페이스를 가리킨다. 정의 네임스페이스 접두어(706)는 맞춤 콤포넌트 또는 요소들이 발견될 수 있는 위치를 규정한다. 예시적인 마크업(700)에서, 정의 네임스페이스 접두어(706)는 "MycontrolLib"을 가리킨다. 요소(708)는 클래스 네임(710)(예를 들면, "MycontrolLib"), 식별자(712), 텍스트 스트링(714)를 구비한다. 클래스 네임(710)은 이 요소에 대하여 인스턴스화되는 클래스를 가리킨다. 식별자(712)는 요소를 가리키며 네임(예를 들면, "ID") 및 값(예를 들면, "button1")을 구비한다. 그 값은 런타임시(예를 들면, button1) 클래스 네임(710)의 인스턴스 네임이 된다.
예시적인 구현의 일반 동작
도 8은 본 발명의 일실시형태에 따라서 명시적으로 정의된 서브클래스를 컴 파일하기 위한 처리(800)를 주로 도시하는 논리 흐름도이다. 도 4 내지 도 6에 나타내는 예시적인 마크업은, 도 10에서의 대표 소스코드와 함께, 처리(800)를 설명하는 도 8과 더불어 이용된다. 도 10과 마크업(600)을 비교하면, 본 발명은 개발자로 하여금 하기 프로그래밍 언어를 이해하지 않고도 정교한 서브클래스가 명시적으로 생성될 수 있게 하는 것을 쉽게 인식할 것이다. 도 10에서의 대표 코드는 C# 코드이다. 그러나, 본 발명에 따른 마크업 컴파일러는 임의의 프로그래밍 언어의 구문을 이용하여 대표코드를 생성할 수 있다.
처리(800)는 블록(801)에서 개시하여, 마크업 컴파일러가 마크업 문서를 컴파일하며 서브클래스 정의를 갖는 마크업과 마주치게 된다. 그 마크업 컴파일러는 마크업을 임의의 다른 포맷으로 인식하지 않거나, 서브 클래스(예를 들면, def:Class) 등으로 인식하지 않는 것과 같은 임의의 메커니즘에 의해 서브클래스 정의와 마주쳤는 지를 판단할 수 있다. 예를 들면, 마크업(400)에서는, 마크업 컴파일러가 서브클래스 정의를 식별하는 서브클래스 태그(예를 들면, def:Class 힌트(410))를 마주치기 전에 여러 문장을 처리할 수 있다. 다른 실시형태에서, 서브클래스 태그는, 서브클래스가 기본 클래스(예를 들면, 버튼)를 규정하지 않는 경우 등에, 다른 문장들 이전에 마주칠 수도 있다. 통상, 서브클래스 태그는 마크업 내에서 요소 태그가 나타날 수 있는 어느 곳이라도 나타날 수 있다. 일단 마크업이 서브클래스 정의를 가진 것으로 식별되면, 처리는 블록(802)으로 진행한다.
블록(802)에서, 서브클래스 태그가 처리된다. 도 4를 참조하여 설명한 바와 같이, 서브클래스 태그(def:Class 힌트(410))라고도 불리움)는 서브클래스 네임스 페이스(412)를 포함할 수도 있는 네임(414)에 할당된다. 이 정보에 기초하여, 도10의 라인 1과 같은 대표코드는 어셈블리어용으로 생성될 수 있다. 또한, 할당된 네임을 가지는 클래스는 도 10의 라인5에 나타낸 바와 같이 생성된다. 라인 5에는 추가적인 문장(예를 들면, 네임스페이스와 수퍼클래스)이 처리되었으면 다른 생성코드가 부가될 것이다. 서브클래스 태그를 처리하는 일부로서, 그 처리는 서브클래스가 임의의 클래스(예를 들면, 수퍼클래스)로부터 확장되고 그 수퍼클래스 관련 정보를 획득하는 지를 식별한다. 도 4에서는, 생성되는 서브클래스 "MyButton"이 수퍼클래스 태그(402)에 의해 정의된 바와 같이 "Button"으로부터 확장된다. 따라서, 나타낸 바와 같이, 도 10의 라인 5는 Button으로부터 MyButton을 확장하는 대표코드를 포함한다.
또한, 서브클래스에 대한 기준 컨스트럭터가 생성된다. 마찬가지로, 추가적인 문장을 처리할 때, 이 기준 컨스트럭터에는 추가적인 대표코드가 부가될 수 있다. 도 10의 라인 23 내지 라인 24 및 26은 생성되는 대표코드에 대응한다. 그러나, "this.Initialinze_This()"는 이하 설명하는 바와 같이 다른 문장을 처리한 후에 부가되는 코드이다. 일단 그 서브클래스 태그가 처리되면, 처리는 블록(804)으로 진행한다.
블록(804)에서, 마크업에서의 다음 문장이 검색된다. 그 다음 문장은 서브클래스 정의 내에서의 서브클래스 태그 문장의 위치에 따라 서브클래스 태그문장의 후의 문장이거나 이전의 문장일 수 있다. 일단 다음 문장이 검색되면, 처리는 결정블록(806)으로 진행한다.
결정 블록(806)에서, 문장이 클래스를 정의하는 지에 대한 판단이 행해진다. 상술한 바와 같이, 본 발명은 계층이 명시적으로 표현될 수 있게 한다. 일실시형태에서, 서브클래스에 자(child)인 다른 클래스(즉, 요소)를 정의하는 문장은 서브 클래스 태그 문장 후에 발생할 것이다. 우선, 현재의 문장이 클래스를 정의하는 것이 아니라고 가정하면, 처리는 블록(808)으로 진행한다.
블록(808)에서는, 그 문장이 처리된다. 서브클래스 정의 내에서 발생할 수 있는 여러 유형의 문장들이 있다. 이들 문장은 다양한 순서로 발생할 수 있다. 각 유형의 문장에 대하여 포함되는 처리는 이하 상세히 설명된다. 그러나, 통상, 처리되는 각 문장에 의해 서브클래스 정의에 대한 추가적인 대표 코드가 생성된다. 일단 문장들 중의 하나가 블록(808)에서 처리되었으면, 처리는 블록(810)으로 진행한다.
블록(810)에서는, 임의의 문장들이 서브클래스 정의에 대하여 남는 처리가 있는 지에 대한 판단이 행해진다. 만약 다른 문장이 있으면 처리는 블록(804) 내지 블록(808)을 통하여 루프 백(loop back)하여 그 문장을 처리한다. 일단 서브클래스 정의 내의 모든 문장들이 처리되면, 그 처리는 결정블록(810)으로부터 블록(812)으로 진행한다.
블록(812)에서는, 상기 처리동안 생성되었던 대표코드가 서브클래스 정의에 대한 IL 어셈블리어를 생성하는데 이용된다. 개발자는, 컴파일러 힌트 문장들 중의 하나(블록 820)에, 대표코드를 생성할 때 사용하는 프로그래밍 언어를 규정하거나 어떠한 어셈블리어 파일이 그 서브클래스 정의를 저장할 지 등을 규정한다. 일 단 IL 어셈블리어 또는 IL 어셈블리어들이 생성되면, 처리가 종료된다. 상술한 바와 같이, 상기 생성된 어셈블리어는 종래 프로그래밍 언어를 이용하거나, 본 발명에 따른 마크업 문장들을 이용하는 등을 함으로써, 바로 실행되어 이용될 수 있다. 그 어셈블리어는 프로그래밍 언어를 이용하여 기재한 것처럼 보인다.
결정 블록(806)으로 돌아가면, 문장이 새로운 클래스(예를 들면, 요소)에 대한 정의를 개시하면, 처리는 블록(814)으로 진행한다. 블록(814)에서, 새로운 클래스에 관련되는 문장들은 각각의 문장에 대하여 블록(808) 내에서의 처리를 이용하여 그 새로운 클래스 관련 모든 문장이 처리될 때까지 처리된다. 예를 들면, 도 5에서는, 문장(520, 526, 422)이 새로운 클래스 "이미지"에 대하여 처리된다. 그 후, 이미지는 서브클래스 "MyButton"의 자(child)이다. 처리는 블록(804)으로 진행하여 그 서브클래스와 관련된 처리를 계속한다.
다시 블록(808)으로 돌아가면, 서브클래스 정의 내에서 발생할 수 있는 각각의 개별 유형의 문장(블록 820내지 블록 832)에 대한 처리를 설명한다. 블록(820)에서, 컴파일러 힌트인 문장들이 처리된다. 통상, 컴파일러 힌트인 문장들은 마크업 컴파일러에 어셈블리어가 어떻게 생성되는 지에 대한 정보를 제공한다. 예를 들면, 도 4 에서는, 언어힌트(408)는 대표 코드를 생성할 때 사용하는 프로그램언어를 마크업 컴파일러에 알리는 컴파일러 힌트 문장이다. 도 4 에서, 언어힌트(408)는 C#에 할당되기 때문에, 도 10에 도시된 대표코드는 C# 소스코드이다.
블록(822)에서, 네임스페이스를 정의하는 문장들이 처리된다. 따라서, 네임스페이스는 도 10의 라인 2와 라인 3에 나타낸 바와 같이 대표 코드에 포함된다.
블록(824)에서, 클래스에 대한 식별자(id)를 정의하는 문장들이 처리된다. 마크업 문서 내의 임의의 id 속성에 대하여, 마크업 컴파일러는 관련 클래스에 대한 필드 멤버를 생성시킨다. 그 필드 멤버는 id 속성이 정의되는 클래스와 동일한 클래스 유형을 갖도록 생성된다. 그 필드 멤버의 네임은 id 속성에 할당된 id 값이다. 예를 들면, 도 5에서, 이미지 클래스에 관련하는 문장들을 처리할 때, id 속성(520)이 마주치게 된다. 따라서, 도 10의 라인 7과 같이, 마크업 컴파일러는
private System.Controls.Image img1;
과 같이 정의되는 필드멤버를 가지는 MyButton 클래스에 대한 대표코드를 생성시킬 것이다.
런타임동안, 필드멤버는 InitComponent() 메소드에서 생성되는 대응유형(예를 들면, 이미지)의 인스턴스로 초기화된다. 그 결과, MyButton 클래스의 임의의 코드는 클래스에서의 id 값에 의해 간단히 그 계층에서의 임의의 다른 요소 인스턴스를 액세스할 수 있다. 필드 멤버를 초기화하는 것이 도 10의 라인 37에 나타낸다.
블록(826)에서, 클래스에 대한 특성을 정의하는 문장들이 처리된다. 마크업 문서 내에서 정의되는 임의의 특성들에 대하여, 마크업 컴파일러는 특성에 대한 대표 소스코드를 생성시키고 필요시 그 특성을 등록한다. 예를 들면, 도 6에서는, 마크업(600)은 여러 속성들(612 내지 618)을 갖는 특성 힌트(610)를 구비한다. 특성힌트(610)는 그 특성힌트(610) 다음의 문장들이 특성에 대한 것임을 마크업 컴파일러에 통보할 것이다. 그 후, 속성(612 내지 618)은 특성 문장들에서 판독된다. 마크업 컴파일러는 도 10의 라인 9 내지 라인 12에 나타낸 바와 같은 MyButton 클래스에 대한 특성을 등록하는 "라벨"특성에 대한 대표코드를 생성한다. 또한, 마크업 컴파일러는 도 10의 라인 28 내지 라인 30에 나타낸 바와 같은 특성을 정의하는 대표 코드를 생성시킬 것이다. 라인 28 내지 라인 30은 어떻게 네임속성(612)이 대표코드에서의 속성네임이 되며 어떻게 유형속성(614)이 대표코드에서 특성에 대한 유형이 되는지를 설명한다.
일실시형태에서, 처리는 특성 유형에 대한 TypeConverter를 호출함으로써 특성값에 대한 코드를 생성하며, 이는 리플렉션을 이용하고 스트링을 실제 특성유형의 오브젝트 인스턴스로 변형하는 코드를 런타임시 실행한다. 다른 실시형태에서, 처리(800)는 실제 오브젝트값을 획득하고 그 값을 InstanceDescriptor 오브젝트로 변형시키기 위해서 특성에 대한 유형 컨버터를 호출한다. 그 InstanceDescriptor 오브젝트는 충분한 정보를 포함하기 때문에, 마크업 컴파일러는 오브젝트에 대하여 리플렉션하여 특성힌트와 관련되는 특성에서 규정된 바와 같이 값 유형의 새로운 인스턴스를 생성하는 대표코드를 생성시킨다. 도 19의 라인 28 내지 라인 30은 어떻게 labelProperty가 Label 특성의 할당값의 런타임시 MyButton의 인스턴스에 설정될 것인 지를 설명한다. 그 할당된 값은 마크업(도 7에 도시된 바와 같이)에서 명시적으로 할당되거나 임의의 프로그래밍 언어를 이용하여 프로그래밍적으로 할당될 수 있다.
블록(828)에서, 클래스에 대한 이벤트를 정의하는 문장들이 처리된다. 이벤트 문장들에서는, 마크업 컴파일러가 이벤트에 대한 대표코드를 생성시킨다. 이벤 트는, 도 5에 나타낸 이벤트 속성(526)과 도 6에 나타낸 이벤트 힌트(620)와 같은 다양한 메커니즘을 이용하여 마크업에서 정의될 수 있다. 우선, 이벤트 속성을 이용하는 메커니즘을 설명한다. 이벤트 속성은 이벤트 트리거와 이벤트 값을 포함한다. 그 이벤트 트리거는 이벤트에 대응하며 이벤트값은 이벤트 트리거가 발생할 때 실행되는 메소드에 대응한다. 도 5를 참조하면, 이벤트값(529)("OnLoaded)은 새로운 System.Controls.DataLoadedEventHandler로서 "this.OnLoaded"를 정의함으로써 도 10의 대표코드의 라인 38 내지 라인 40에 대한 이벤트 핸들러로서 추가된다. 그 이벤트 트리거(527)("DataLoaded")는 System.Controls.DataLoadedEvent로서 AddHandler의 제 1 파라미터를 정의함으로써 도 10의 대표코드의 라인 38에 관한 이벤트로서 추가된다. AddHandler에 대한 다른 파라미터는 마크업 문서에서 규정될 수 있거나 기준값을 사용할 수 있다.
다음으로, 이벤트 힌트(620)를 사용하는 메커니즘을 설명한다. 이벤트 힌트(620)는 이벤트 네임속성 및 다른 속성들을 구비한다. 그 이벤트 네임속성에 할당된 네임은 이벤트로서 등록된다. 예를 들면, 도 6을 참조하면, "DblClick"은 이벤트 네임속성에 할당되는 네임이다. 따라서, "DblClick"은 도 10의 라인 14 내지 라인 16에 생성되는 RegisterEvent 메소드의 제 1 파라미터이다. 메소드 "DblClickEventHdlr"에 대한 이벤트 핸들러 선언(630)의 유형은 도 10의 RegisterEvent 메소드의 파라미터로서 포함될 수 있다. 또한, RegisterEvent 메소드에 대한 다른 파라미터는 기준값이거나 다른 속성들을 이용하여 마크업 문서에서 규정될 수 있다. 런타임시, 일실시형태에 따라서, 이벤트는 리플렉션을 이용하여 연결(hook up)되어 DblClickEventHandler의 유형을 식별하고 메소드를 위치시킨다.
블록(830)에서, 코드를 정의하는 문장들이 처리된다. 코드를 정의하는 문장들은 코드 힌트와 같은 컴파일러 힌트 문장(블록 820) 다음에 온다. 이들 문장은 프로그래밍 언어로 기재되며 대표 코드처럼 보일 것이다. 예를 들면, 도 5는 메소드(530)와 CustomInit 함수(550)을 도시한다. 메소드(530)과 CustomInit 함수(550)는 도 10의 라인 18 내지 라인 19와 라인 21에 각각 나타낸다.
블록(832)에서, 부가적인 컨스트럭터를 정의하는 문장들이 처리된다. 또한, 부가적인 컨스트럭터를 정의하는 문장이 컨스트럭터 힌트와 같은 컴파일러 힌트 문장(블록 820)의 다음에 온다. 마크업 컴파일러는 부가적인 컨스트럭터(도 10의 "this_Initialize_This()")를 생성시키며 그 부가적인 컨스트럭터 내에 문장들을 추가시킨다. 예를 들면, 도 5에서는, 컨스트럭터 힌트(542) 후의 문장들이 "CustomInit()"를 호출한다. 따라서, 도 10의 라인 33에서, 마크업 컴파일러는 대표소스코드에서의 부가적인 컨스트럭터에 "CustomInit()"을 추가한다.
당업자는 블록(812)이 본 발명을 벗어나지 않으면서 블록(804 내지 810)을 처리하는 동안 점진적으로 행해질 수 있음을 인식할 것이다. 또한, 분석기(204)와 마크업 컴파일러(202)의 기능적 구현에 따라서, 처리 (800) 동안 분석기(204)와 마크업 컴파일러(204) 간의 콜백(callback)이 있을 수 있다.
도 9는 본 발명의 일실시형태에 따라서 마크업 문서 내에서 선언된 서브클래스를 이용하는 런타임 처리(900)를 주로 설명하는 논리흐름도이다. 도 7에 나타내는 예시적인 마크업은 처리(900)를 설명하는 도 9와 결합하여 사용된다. 처 리(900)는 블록(901)에서 개시하며, 여기서 런타임 엔진은 특정 자원(예를 들면, 마크업 문서)에 대한 요청을 수신하여, 특정 자원에 대한 컴파일된 버전이 존재하는 지를 판단한다. 예를 들면, 도 7에서, 마크업(700)이 이전에 토큰화된 이진파일로 컴파일되지 않았다고 가정하면, 마크업 컴파일러가 요소(708)를 만날 때, 마크업 컴파일러는 MyButton 클래스가 관련 토큰화된 이진파일과 IL 어셈블리어를 갖는지를 판단한다. 그 후, MyButton 클래스에 대한 토큰화된 속성을 포함하는 이러한 관련 토큰화된 이진파일은 처리(900)를 이용하여 처리될 것이다. 그 관련 토큰화된 이진파일과 IL 어셈블리어는 본 발명을 이용하여 생성될 수 있다. 처리는 블록(902)으로 진행한다.
블록(902)에서는, 토크화된 이진파일이 로드된다. 그 토큰화된 이진파일은 점진적으로 또는 온전히 그대로 로드될 것이다. 그 토큰화된 이진파일은 로드될 필요가 있는 토큰화된 이진파일과 관련된 IL 어셈블리어를 식별할 것이다. 도 7을 참조하여, 예를 들면, MyButton 클래스와 관련되는 IL 어셈블리어가 로드된다. 처리는 블록(904)으로 진행한다.
블록(904)에서는, 토큰이 토큰화된 이진파일로부터 검색된다. 상술한 바와 같이, 새로운 런타임 환경에서는, 생성되는 토큰화된 이진파일이 그 토큰화된 이진파일을 생성하는데 이용된 프로그래밍 언어로부터 독립적이다. 따라서, 런타임 엔진은 그 토큰화된 이진파일을 생성하는 원시적으로 사용되었던 프로그래밍 언어 없이도 토큰화된 이진파일을 처리할 수 있다. 처리는 결정블록(906)으로 진행한다.
결정블록(906)에서는, 검색된 토큰이 이벤트인지 여부에 대한 판단이 이루어 진다. 토큰이 이벤트가 아닌 경우, 처리는 블록(908)으로 진행한다.
블록(908)에서, 토큰이 처리된다. 상술한 바와 같이, 토큰의 처리는 토큰화된 이진파일이 생성되는 방식에 의존하지는 않는다. 즉, 프로그래밍 언어를 이용하여 또는 마크업 문서 내로부터 명시적으로 생성되는 토큰화된 이진파일 내의 토큰의 처리는 동일한 방식으로 진행될 것이다. 따라서, 토큰화된 이진파일 내의 토큰의 처리가 당업자에게 알려져 있기 때문에, 토큰의 처리는 여기서 상세히 설명하지는 않는다. 처리는 결정블록(910)으로 진행한다.
결정블록(910)에서는, 토큰화된 이진파일내에 임의의 더 많은 토큰이 있는 지에 대한 판단이 행해진다. 보다 많은 토큰이 있으면, 처리는 블록(904)에 루프백하여 상술한 바와 같이 처리한다. 그 반면에, 더이상의 토큰이 없으면, 처리는 종료하여 종료블록으로 진행한다.
결정블록(906)으로 돌아가면, 토큰이 이벤트일 때에는, 처리는 블록(912)으로 진행한다. 블록(912)에서는, 토큰화된 이진파일에 관련되는 메타데이터가 로드된다. 그 메타데이터는 유형, 자원, 메소드 등에 대한 설명을 포함한다. 처리는 블록(914)으로 진행한다.
블록(914)에서는, 메타데이터와 리플렉션을 이용하여, 처리가 이벤트에 대한 목표 요소유형을 발견한다. 이는 메타데이터를 액세스하고 각각의 필드를 걸쳐 유형을 판단하는 것을 포함한다. 처리는 블록(916)으로 진행한다.
블록(916)에서는, 이벤트가 목표 요소유형에 대하여 확인된다. 이는 이벤트가 유효한 이벤트임을 보장한다. 이벤트가 목표 요소유형에 대한 유효한 이벤트가 아니면 에러가 발생한다. 처리는 블록(918)으로 진행한다.
블록(918)에서는, 리플렉션이 목표 요소유형에 대하여 사용되어 이벤트 메소드가 획득된 후 실행된다. 그 이벤트 메소드의 실행은 관련 IL 어셈블리어 내의 코드의 실행을 포함한다. 따라서, 도 7을 참조하면, 일단 MyButton이 인스턴스화되고 이벤트가 발견되면, 이벤트 메소드("DblClickEvent")가 첨부된다. 이는 이벤트 핸들러(예를 들면, DblClickEvent")를 이벤트(예를 들면, DblClick)에 첨부시킨다. 처리는 블록(910)에서 계속되며, 상술한 바와 같이 진행한다.
따라서, 상술한 바와 같이, 본 발명은 마크업 문서 내에서 명시적으로 서브클래스를 정의하고 마크업 문서 내로부터 서브클래스를 이용하는 메커니즘을 제공한다. 이는 개발자가 임의의 하나의 프로그래밍 언어에서의 콤포넌트를 어떻게 구현할지에 대하여 고민하는 대신 그 콤포넌트를 사용하는 방식에 보다 집중할 수 있게 한다.
상술한 명세서, 실시예들과 데이터는 본 발명의 구성의 생산 및 이용의 완전한 설명을 제공한다. 본 발명의 많은 실시형태들이 본 발명의 범위를 벗어나지 않으면서 행해질 수 있으며, 본 발명은 이하 첨부되는 청구항들로 청구된다.