KR20150043333A

KR20150043333A - 선언형 템플릿을 사용하여 컨트롤을 스탬프 아웃하기 위한 사용자 인터페이스 컨트롤 프레임워크

Info

Publication number: KR20150043333A
Application number: KR20157004037A
Authority: KR
Inventors: 코리 시린시온; 마크 리스; 도미니크 홉튼
Original assignee: 마이크로소프트 코포레이션
Priority date: 2012-08-14
Filing date: 2013-08-14
Publication date: 2015-04-22
Also published as: EP2885700A1; WO2014028655A1; JP2015534145A; US20140053063A1; CN104798036A

Abstract

사용자 인터페이스("UI") 컨트롤 프레임워크는, 보통 통상적인 UI 컨트롤 모드에서 요구되는 표준(boilerplate) 자바스크립트를 작성하기 않고도 UI 컨트롤이 HTML 마크업과 유사하게 선언형으로 생성되게 할 수 있다. 하나의 특정한 예시적인 구현에서, UI 컨트롤 프레임워크는 기존의 WinJS(Windows Library for JavaScript) 기능의 상위에 있도록 구성되고 많은 컨트롤 구현예에 걸쳐 공통적인 동작(behaviors)을 인캡슐화하여 UI 컨트롤 템플릿의 단일 인스턴스가 복수의 컨트롤 인스턴스를 스탬프 아웃(stamp out)하는 데 사용될 수 있다. UI 컨트롤 프레임워크는 보조 컨트롤(backing control)의 "코드 비하인드(code behind)"로부터 레이아웃을 분리하여 데이터 바인딩이 컨트롤 및 이의 임의의 자식 컨트롤의 레이아웃에 대한 명확한 지식 없이도 추상적으로 구현될 수 있다. 마크업은 코드가 자식 컨트롤에 대한 직접적인 액세스를 가지게 할 수 있는 "앵커 포인트(anchor points)"를 제공한다. 컨트롤 인스턴스에 명명된 특성을 배치하는 커스텀 익스펜도 HTML 속성(custom expando HTML attributes)이 사용된다.

Description

선언형 템플릿을 사용하여 컨트롤을 스탬프 아웃하기 위한 사용자 인터페이스 컨트롤 프레임워크{USER INTERFACE CONTROL FRAMEWORK FOR STAMPING OUT CONTROLS USING A DECLARATIVE TEMPLATE}

하이퍼텍스트 마크업 언어의 5차 개정판(revision)(즉, "HTML5")이 월드 와이드 웹 컨소시엄("W3C")으로 알려진 국제 표준체(international standards body)에 의해 공식적으로 정의된다. HTML5는 차세대의 웹 기술에 관한 100가지 이상의 사양(specifications)을 포함한다. HTML5는 디자이너 및 개발자가 차세대의 웹 사이트 및 애플리케이션을 구축할 수 있게 하도록 구성된 HTML, CSS(Cascading Style Sheets) 및 자바스크립트 세트의 사양을 서술한다. 그러한 기술은 많은 사용 시나리오에서 만족할 만하게 수행되고 있으나, 아직도 향상된, 더 풍부한 웹 애플리케이션 개발 경험이 구현될 여지가 남아 있다.

본 배경기술은 다음의 요약 및 상세한 설명에 대한 간략한 소개를 하기 위해 제공된 것이다. 본 배경기술은 청구된 발명의 대상의 범주를 결정하는 것을 돕기 위한 것이 아니며, 청구된 발명의 대상을 전술한 임의의 또는 모든 문제점을 해결하는 구현예로 제한하려는 것으로 제한되지 않는다.

사용자 인터페이스("UI") 컨트롤 프레임워크(framework)는, 보통 통상적인 UI 컨트롤 모드에서 요구되는 표준(boilerplate) 자바스크립트를 작성하지 않고도 UI 컨트롤이 HTML 마크업과 유사하게 선언형으로 생성되게 할 수 있다. 하나의 특정한 구현예에서, UI 컨트롤 프레임워크는 기존의 WinJS(Windows Library for JavaScript) 기능의 상위에 있도록 구성되고 많은 컨트롤 구현예에 걸쳐 공통적인 동작(behaviors)을 인캡슐화하여, UI 컨트롤 템플릿의 단일 인스턴스가 복수의 컨트롤 인스턴스를 스탬프 아웃(stamp out)하는 데 사용될 수 있다. UI 컨트롤 프레임워크는 보조 컨트롤(backing control)의 "코드 비하인드(code behind)"로부터 레이아웃을 분리하여 컨트롤 및 이의 임의의 자식 컨트롤의 레이아웃에 대한 명확한 지식 없이도 데이터 바인딩이 추상적으로 구현될 수 있다. 마크업은 코드가 자식 컨트롤에 대한 직접적인 액세스를 가지게 할 수 있는 "앵커 포인트(anchor points)"를 제공한다. 컨트롤 인스턴스에 명명된 특성(named property)을 배정하는 커스텀 익스펜도 HTML 속성(custom expando HTML attributes)이 사용된다.

효과적인 점으로는, 레이아웃 및 보조 컨트롤 사이의 느슨한 연결(loose coupling)이 HTML 및 CSS 분야의 전문가이나 프로그래머/개발자로서 자바스크립트 코딩에는 정통하지 않을 수 있는 웹 애플리케이션 디자이너에 의해 UI 컨트롤이 쉽게 생성될 수 있도록 한다. 프레임워크는 디자이너가 보조 컨트롤 코드를 터치할 필요 없는 UI 컨트롤의 선언형 생성을 지원한다. 프레임워크 및 이의 선언형 템플릿은 또한 본질적으로 유연성이 있어 디자이너가 보조 컨트롤 내의 코드를 업데이트할 필요 없이, 앵커 포인트가 동일하게 명명된 상태를 유지하는 한 컨트롤 레이아웃에 대해 대규모 변경을 할 수 있다. 그러한 유연성은 애플리케이션이 디자이너에게 풍부한 사용자 경험을 할 수 있는 강력한 도구를 제공하는 한편 코드 관리(maintenance)와 연관된 비용을 줄일 수 있다.

본 요약은 상세한 설명에서 이하에 기술되는 개념의 선택사항에 대해 간단한 소개를 하기 위해 제공된다. 본 요약은 청구된 발명의 대상의 주요 특징이나 핵심 특징을 식별시키기 위한 것이 아니며, 청구된 발명의 대상의 범주를 제한하는 데 사용하려는 것도 아니다.

도 1은 본 발명의 UI 컨트롤 프레임워크가 구현될 수 있는 예시적인 컴퓨팅 환경을 나타낸다.
도 2는 전형적인 UI 컨트롤 모델에서 UI 컨트롤 레이아웃이 어떻게 기본 "코드 비하인드"에 강하게 연결되는지를 나타낸다.
도 3은 음악 트랙을 디스플레이하고 이들의 구매를 가능하게 하는 UI 컨트롤을 호출(invoke)하는 예시적인 HTML 코드를 나타낸다.
도 4는 도 3에 도시된 UI 컨트롤을 구현하는 데 사용되는 표준 자바스크립트의 예를 나타낸다.
도 5는 UI 컨트롤 레이아웃을 특정하는 마크업 파일이 어떻게 본 발명의 UI 컨트롤 프레임워크의 보조 컨트롤에 느슨하게 연결되고 이로부터 분리되는지를 나타낸다.
도 6은 선언형 UI 컨트롤 템플릿이 어떻게 복수의 컨트롤 인스턴스를 "스탬프 아웃"하는 데 사용되는지에 대한 예를 나타낸다.
도 7은 보조 컨트롤에 의해 데이터가 제공되는 레이아웃에서 데이터를 컨트롤에 바인딩하기 위한 예시적인 배열(arrangement)을 나타낸다.
도 8은 본 발명의 UI 컨트롤 프레임워크의 구현을 위한 예시적인 아키텍처를 나타낸다.
도 9는 WinJS 하에서 본 발명의 UI 컨트롤 프레임워크를 지원하는 기능 및 네임스페이스를 생성하는 것을 나타낸다.
도 10 내지 12는 본 발명의 UI 컨트롤 프레임워크의 예시적인 용법을 나타낸다.
도 13은 예시적인 HTML DOM(Document Object Model) 트리의 일부를 나타낸다.
도 14 내지 17은 HTML 구성요소와 연관된 다양한 익스펜도 속성을 포함하는 예시적인 HTML 프레그먼트를 나타낸다.
도 18은 본 발명의 UI 컨트롤 프레임워크를 구현하는 데 이용할 수 있는 개인 컴퓨터 또는 서버와 같은 예시적인 컴퓨터 시스템에 대한 간략한 블록도이다.
도면에서 같은 참조번호는 같은 구성요소를 나타낸다.

도 1은 본 발명의 UI 컨트롤 프레임워크가 구현될 수 있는 예시적인 컴퓨팅 환경(100)을 나타낸다. 환경(100)에서, 복수의 웹 애플리케이션 사용자(105)는 개별적인 컴퓨팅 장치(110)를 이용하여 인터넷(120)을 통해 웹 애플리케이션 제공자(115)를 포함하는 웹 기반 자원에 액세스한다. 컴퓨팅 장치(110)는 다양한 특징 및 기능을 갖는 다양한 플랫폼(그러한 플랫폼 전부가 도 1에 도시되는 것은 아님)을 포함할 수 있고, 플랫폼은 예를 들어, 모바일 폰, 스마트 폰, 개인 컴퓨터("PC"), 울트라 모바일 PC, 개인 디지털 보조기(PDA), 이메일 애플리케이션, 디지털 미디어 플레이어, 태블릿 컴퓨터, 핸드헬드 게이밍 플랫폼 및 게이밍 콘솔, 노트북 및 랩톱 컴퓨터, 인터넷 연결 텔레비전, 셋탑 박스, GPS(Global Positioning System) 및 내비게이션 장치, 디지털 카메라 및 본 명세서 제공된 기능의 다양한 조합을 포함하는 장치를 포함한다. 그러나, 전술한 목록은 설명을 위한 것이며 본 배열은 HTML5 기능 또는 이들의 조합을 지원하는 다양한 플랫폼 중 어느 것에서나 사용되는 것으로 예상할 수 있다는 점이 강조된다.

본 발명의 UI 컨트롤 프레임워크를 구현하는 데 필요한 기능은 아니나, 흔히 컴퓨팅 장치(110)는 직접적인 또는 중계 장치(예, 인터넷 연결 개인 컴퓨터)를 통한, 또한 웹 브라우저나 애플리케이션 또는 내장된 기능(장치 상에서 동작하며, 예를 들면 터치스크린, 키패드, 포인팅 장치 등과 같은 입력 장치 및 디스플레이를 통해 사용자 상호작용을 지원하는 유사한 기능을 제공함)을 통한 소정 형태의 네트워크 연결 특징을 가질 수 있다. 도 1에 도시된 것과 같이, 컴퓨팅 장치(110)는 모바일 네트워크(125)를 사용하여 또는 인터넷 서비스 제공자("IPS")(130)를 통해, 또는 일부의 경우에는 이 둘 모두를 사용하여 인터넷(120) 및 웹 애플리케이션 제공자(115)에 액세스할 수 있다.

웹 애플리케이션 디자이너(135)는 제공자(115)와 함께 작업하여 애플리케이션 및 웹 사이트(HTML5의 기능을 이용함)를 포함하는 차세대 웹 기술을 디자인한다. 또한, 프로그래머(140)는 제공자와 함께 작업한다. 이러한 예시적인 실시예에서, 디자이너는 일반적으로 HTML 및 CSS에 익숙하고 이를 사용하나 코딩에 있어 프로그래머와 동일한 높은 수준의 전문성을 가질 필요는 없다.

도 2에 도시된 바와 같이, 전통적인 UI 컨트롤 개발 모델은 사용자를 위한 디스플레이 상에 컨트롤을 구성하고 제시하는 UI 컨트롤 레이아웃(205)과 웹 애플리케이션의 비즈니스 및/또는 프레젠테이션 로직을 사용하여 컨트롤을 구현하는 데 사용되는 기본 코드(210)(흔히 "코드 비하인드"라고 함) 사이에 강한 연결(tight coupling)을 구현한다. 그러한 강한 연결은 코드가 각각의 UI 컨트롤 및 임의의 자식 컨트롤의 레이아웃에 대한 명확한 지식을 가질 필요가 없다는 것을 의미한다. 또한, 자식 컨트롤이 가지는 임의의 의존성은 부모에 의해 명시적으로 관리될 필요가 없다.

전통적인 개발 모델에서, 디자이너는 애플리케이션 특징을 생성하거나 변경할 경우에 코드를 터치해야 할 필요가 있을 수 있으며, 이는 디자이너의 보다 제한적인 코드 전문성을 고려한다면 종종 문제가 될 수 있다. 또한, 코드 및 레이아웃 간의 강한 연결은 각각의 UI 컨트롤에 대해 상대적으로 많은 양의 표준 코드를 생성할 필요성을 일으킬 수 있다. 도 3 및 4는 WinJS에서 그러한 표준 코드의 설명을 위한 예를 제공한다. WinJS는 디자이너, 프로그래머 및 개발자로 하여금 자바스크립트를 사용하여 메트로 스타일 애플리케이션("앱") 용으로 디자인된 새로운 컨트롤을 구현할 수 있게 하는 종합적인 기능(comprehensive functionalities)을 제공한다. 현재, WinJS는 UI 컨트롤을 정의하기 위한 HTML 마크업 및 자바스크립트 사이의 간단하나 강력한 협약(contract)을 사용한다. 각각의 버튼을 눌러 구매할 수 있는 다양한 음악 트랙을 디스플레이하는 UI 컨트롤에 대한 HTML 마크업의 예시적인 프레그먼트가 도 3에 참조 번호 305로 도시된다. 대응하는 자바스크립트 코드는 도 4에 참조 번호 405로 도시된다.

본 예에 나타낸 바와 같이, 상대적으로 간단한 컨트롤에서도, 일반적으로 거의 모든 UI 컨트롤에 대해 반복될 필요가 있는 다량의 표준 코드가 존재한다. 이러한 상황은 유사한 문제를 여러번 해결할 필요가 있는 프로그래머(예, 도 1 및 도 2의 프로그래머(140))에게 이어질 수 있으며, 이는 코딩 에러 및 불일치로 이어질 수 있고, 공통의 및 공유된 코딩 패턴의 보급을 감소시킬 수 있으며, 최종적으로는 높은 애플리케이션 관리 비용을 발생시킬 수 있다.

전통적인 UI 컨트롤 모델에서의 강한 연결과 달리, 도 5에 도시된 본 발명의 UI 컨트롤 프레임워크에서 UI 컨트롤 레이아웃(505)은 코드 비하인드(510)에 느슨하게 연결된다. 구체적으로, 느슨한 연결은 예를 들면, HTML 및 CSS를 포함하는 마크업 파일(515)이 보조 컨트롤(520)로부터 분리될 수 있게 한다. UI 컨트롤은 임의의 자식 컨트롤에 대한 참조를 포함하여, 마크업 파일(515)에 자신의 레이아웃을 저장하고, 이는 이후에 복수의 컨트롤에 대한 레이아웃을 "스탬프 아웃"하기 위한 선언형 템플릿으로서 사용된다. 도 6에 도시된 바와 같이, 마크업 파일(515)(즉, 선언형 템플릿) 자체는 단일 인스턴스화되나, 스탬핑 아웃은 컨트롤 인스턴스 마다 수행된다. 각각의 레이아웃(605)이 보조 컨트롤(610)의 코드에 대해 1:1 기반으로 매핑된다. 따라서, 본 발명의 UI 컨트롤 프레임워크는 복수의 UI 컨트롤이 효과적으로 단일 템플릿으로 정의되게 할 수 있다(이는 마크업을 통해 컨트롤의 단순한 선언형 레이아웃을 가능하게 하면서 표준 코드의 반복적인 생성에 대한 필요성을 없앰).

특성(property) 또는 값과 같은 UI 컨트롤에 대한 데이터는 레이아웃 내의 컨트롤에 의해 직접적으로 관리되지 않는다. 대신에, 데이터는 보조 컨트롤로부터 데이터를 느슨하게 소싱(source)하기 위해 레이아웃 내의 선언형 명시(declarative specification)를 통해 요청된다. 도 7은 그러한 데이터 바인딩(여기서 컨트롤 레이아웃(705)은 참조 번호 715 및 720에 의해 표시된 두 개의 자식 컨트롤을 포함함)의 예로서 두 개의 자식 컨트롤을 포함한다. 자식 컨트롤에 대한 데이터는 참조 번호 725 및 730으로 나타낸 특성을 제공하는 보조 컨트롤(710)로부터 바운드된다. 중요하게는, 느슨한 연결은 자식 컨트롤에 대한 명확한 지식 없이도 보조 컨트롤에 의해 제공되는 데이터가 추상적으로 획득되도록 한다.

도 8은 기존의 WinJS 플랫폼에 구축된 본 발명의 UI 컨트롤 프레임워크의 하나의 특정한 구현예에 대한 예시적인 아키텍처를 나타낸다. WinJS에 대한 추가적인 정보는 http://msdn.microsoft.com/en-us/library/windows/apps/br2l l377.aspx에서 찾아볼 수 있다. 이러한 구체적인 예에서, 컨트롤 프레임워크(805)는 UI 컨트롤(810)을 지원하고 코어 구축 블럭(core building blocks)으로서 세 개의 WinJS 컴포넌트 상에 구축된다. 컴포넌트는 Base.js(참조 번호 815로 표시됨)를 포함하며, 이는 타입 정의를 제공하고 WinJS 프라미스 객체(promise object)를 사용하여 비동기식 거치 호출 모델(asynchronous deferred invocation model)을 지원한다. Binding.js 컴포넌트(820)는 일방향의 선언형 및 명령식 바인딩 시스템(declarative and imperative binding system), 동적 특성 바인딩(dynamic property binding) 및 데이터 템플레이팅(data templating)을 제공하는 데 사용된다. UI.js 컴포넌트(825)는 기본 컨트롤 모델, HTML 프레그먼트 로더 및 다양한 UI 유틸리티 기능을 제공한다. WinJS 플랫폼 및 이의 특정한 바인딩 블록 컴포넌트의 용법이 WinJS 플랫폼 구현예에 한정되는 것이 아니라는 점을 강조한다. 본 명세서에 제시된 원리는 특정한 구현예의 필요에 따라 다양한 프로그래밍 패러다임(이들 중 일부는 CSS 및 자바스크립 객체를 사용할 수 없음)과 함께 사용하도록 적용될 수 있다.

네임스페이스 및 디폴트 컨트롤 클래스가 도 9에 도시된 코드 세그먼트(905)에 도시된 바와 같이 WinJS에 정의된다. 이러한 클래스는 컨트롤 선언을 간단하게 하고 최적화(optimization)의 일부를 인캡슐화하도록 배열되는 기능 세트 및, 프레그먼트, 템플릿 등의 백그라운드 관리를 제공한다. 새로운 컨트롤 클래스는 WinJS 컨트롤 정의 기능 대신에 사용된다. 그러나, 제공된 defineUserControl 기능은 동일한 WinJS 컨트롤 협약(contract)에 맞춰진다. 이 기능은 많은 파라미터를 WinJS로부터의 WinJS.Class.define()에 넘겨주고, 마찬가지로 값을 디폴트 컨트롤 클래스(default control class)로 넘겨준다.

이하의 표 1에는 함수 파라미터가 도시된다.

기존의 컨트롤로부터 얻는 것이 가능하다는 점에 주의한다. 이러한 경우에 일반적인 용법(common usage)은 동일한 컨트롤 동작(control behavior)에 대해 서로 다른 템플릿을 이용할 것이다. 그러한 용법은 윈도우즈 프레젠테이션 파운데이션("WPF")에서의 컨트롤 구현과 유사하다.

컨트롤 베이스 클래스는 WinJS 협약(예, setOptions, setElement 및 funct ion(element, options) 컨스트럭터 기능)을 구현하면서, 이러한 클래스를 확장하는 디자이너 및 프로그래머에게 선택적 맞춤화(optional customization)를 제공한다. 컨트롤 베이스 클래스는 이하의 표 2에 나타낸 다양한 기능을 제공한다.

예를 들어, 자원을 자유롭게 하거나 상태를 지속시키기 위해 작성자의 컨트롤이 UI로부터 제거되는 경우에 컨트롤 작성자가 작업을 수행해야 할 경우가 존재할 수 있다. 이를 가능하게 하기 위해, 컨트롤이 HTML DOM(Document Object Model)로부터 제거되면, "언로드"라고 불리는 메소드가 컨트롤 인스턴스에 호출된다. 이는 작성자로 하여금 정확한 시점에 작업을 수행할 수 있게 한다.

템플릿이 로딩되는 경우에, UI 컨트롤을 구현하는 마크업 및 CSS의 로딩이 컨트롤 소비자(예, 디자이너(135))에게 투명하게 인캡슐화된다. 이러한 투명성을 가능하게 하기 위해, 컨트롤 정의는 그 템플릿에 대한 파일 내에 파일 및 식별자 모두를 나타내는 URI(Uniform Resource Identifier)를 가질 것이다. 이하의 표 3에 도시된 “SimpleControls.html#EditBoX”는 설명을 위한 예이다.

HTML id 속성(attribute)을 사용하여 특정한 템플릿을 식별하는 것이 가능할 수 있으나, 부모 문서와 통합되는 경우에 고유성(uniqueness)에 관한 문제가 일부 존재한다. 이를 해결하기 위해, 커스텀 HTML 익스펜도 속성인 'data-ent-templateid’가 사용되며, 이는 HTML 문서 내에 고유한 값으로 설정된다. 전세계적으로 파일 경로 및 id의 조합은 템플릿을 식별하는 데 사용될 수 있다.

템플릿에 대한 컨트롤 레이아웃 파일의 일대다 관계를 고려하면, 템플릿에 대한 액세스를 위해 특정한 파일(프레그먼트)의 DOM으로의 로딩은 컨트롤 소비자에게 투명할 필요가 있다. WinJS는 본 발명의 UI 컨트롤 프레임워크에 의해 이용될 수 있는 풍부하고 완전한 기능을 갖는 프레그먼트 로딩 메커니즘을 가진다. 이는 프레그먼트가 문서에 로딩되게 하고, 프레그먼트는 명확하게 언로딩될 때까지 문서에 상주한다. 이에 따라, 동일한 프레그먼트를 로딩하기 위한 후속 콜(call)이 즉시 완료될 것이다. 따라서, 이러한 암시적인 캐싱(implicit caching)은 프래그먼트가 로딩됨에 따라 프래그먼트를 관리한다. 또한, 인스턴스화된 WinJS.Binding.Template 인스턴스가 캐싱되어 컨트롤이 렌더링될 때마다 인스턴스가 페칭(fetch)될 필요가 없다.

부모 문서로의 복사 없이, 소스 HTML 파일에 포함된 CSS 및 스크립트가 병합된다. WinJS는 프레그먼트를 '언로드'하기 위한 기능을 제공하며, 이는 콘텐트를 제거 및 언로드할 것이다. 템플릿은 컨트롤에 대한 실제 템플릿 하이드레이션(hydration) 및 데이터 바인딩을 수행하기 위한 WinJS의 WinJS.Binding.Template() 함수(이는 컨트롤 협약에 따름)를 사용할 것이다. 따라서, 프레그먼트 로딩 및 템플릿 하이드레이션 모두는 컨트롤 작성자를 위해 균일하게(seamlessly) 처리될 것이다.

도 10 내지 도 12는 본 발명의 UI 컨트롤 프레임워크의 예시적인 용법의 예를 나타낸다. 도 10은 도 3 및 도 4에 도시되며 첨부된 설명에 기술된 예와 유사한 방식으로 버튼 누르기를 통해 사용자가 디스플레이되는 음악 트랙을 구매할 수 있게 하기 위한 UI를 구현하는 UI 컨트롤 템플릿에 대한 HTML 코드(1005)의 프래그먼트를 나타낸다. 대응하는 자바스크립트 코드(1105)는 도 11에 도시된다. 컨트롤 소비자는 도 12에 도시된 HTML 프레그먼트(1205)를 사용하여 간단히 선언형으로 UI 컨트롤을 인스턴스화 할 수 있다.

전술한 UI 컨트롤 프레임워크의 코어 기능에 추가하여, 추가적인 컨트롤 동작을 위해 제공되는 복수의 커스텀 HTML 익스펜도 속성이 사용될 수 있다. 속성에 의해 처리되는 한 가지 특정한 문제는, 지정된 컨트롤의 DOM 트리에 관해 특정한 HTML 구성요소에 (직접적으로 또는 그 구성요소에 의해 표현된 컨트롤을 통해) 액세스할 필요가 있을 수 있다는 것이다. 예시적인 DOM 트리(1310)가 도 13에 도시되며, 이는 HTML 구성요소, 텍스트 구성요소, 및 키(1315)에 나타낸 속성을 포함하는 연결된 노드 그룹으로서 애플리케이션의 페이지를 나타낸다. 자바스크립트는 자신의 콘텐트를 변경하거나 삭제하고 새로운 구성요소를 생성하기 위해, 트리를 통해 노드에 액세스할 수 있다. DOM 트리의 노드는 서로에 대해 계층적 관계를 갖는다.

이러한 액세스 문제를 처리하기 위해, "data-ent-member"라 불리는 익스펜도 속성(expando attribute)이 소정의 구성요소에 배치되는 템플릿의 작성이 허용된다. 이러한 속성은 그 속성이 배치되어 있는 구성요소의 인스턴스를 컨트롤 인스턴스 상의 멤버로서 배치하도록 해석된다. 구성요소가 컨트롤을 나타내면, 구성요소 대신에, 컨트롤 인스턴스가 그 멤버에 배치된다. 일 예가 도 14에 나타낸 HTML 프레그먼트(1405)에 도시된다. 이러한 예에서, 이러한 템플릿을 소비하는 컨트롤은 그러한 구성요소에 대한 쉬운 액세스를 가능하게 하는 두 개의 특성(property) 세트(즉, member1, member2)를 가지는 것을 알 수 있다. 특성이 이하의 표 4에 설명된다.

전형적인 DOM 트리의 복잡성 및 가능한 한 코드 구현으로부터 레이아웃(즉, HTML, CSS)을 분리하려는 목적을 고려하면, 코드를 사용하여 이벤트 리스너(event listener)를 구현하기보다는 이벤트가 선언형으로 부착된다. 'data-ent-member' 속성은 템플릿의 구성 부분(constituent part)이 이동되게 하고 코드에 대해 영향을 적게 유지하도록 하나, 여전히 이벤트 리스너, 정의된 기능 등을 호출할 필요가 있다. 또한, 'this' 포인터는 컨트롤 자체가 아닌 이벤트를 일으키는 구성요소를 가리킨다. 이것은 통상적으로 도구 개발자(means developer)가 자신의 코드 전체에서 'var that'을 사용하고 있거나 .bind(this)를 실행하고 있음을 의미한다. 개발자가 그러한 형식(formality)을 신경 써야 하고 임의의 다른 기능처럼 이벤트 핸들러를 작성해야하는 것을 방지하기 위해, 도 15에 도시된 HTML 프레그먼트(1505)에 나타낸 바와 같이 익스펜도 속성인 'data-ent-member'가 사용된다. 도 15에 도시된 이러한 구체적인 실시예에서, HTML 구성요소에 부착될 DOM 이벤트가 이하의 표 5에 표현된다.

모든 핸들러 메소드가 컨트롤 인스턴스에서 발견될 것이고 자신의 'this' 포인터를 컨트롤 인스턴스로 설정되게 할 것이다. 이들은, 호출되면, 임의의 DOM 이벤트 핸들러로 전달되는 표준 파라미터를 넘겨줄 것이다.

컨트롤 소비자에게 동작의 복잡성을 숨기기 위해 애플리케이션에서 소정의 동작(예를 들면, 비디오 플레이, 트랙 구매 등)을 추상화할 추가적인 필요성이 존재한다. 이러한 문제를 해결하기 위해, '액션(actions)'이라 불리는 개념이 생성된다. 이러한 개념은 인에이블된(예를 들면 유효 선택을 가짐) 그리고 이용가능한(머신 환경설정 또는 마켓 요구에 기초하여서는 발생할 수 없음) 호출(invocation)의 상태에 대한 간단한 협약(simple contract)을 제공한다.

본 발명의 UI 컨트롤 프레임워크는 기능의 실제 호출 자체를 처리하지 않으나(이는 최선의 상호작용을 결정하는 컨트롤에 달려있기 때문임), 액션을 취하고, 이용가능성(availability)을 처리하며, 그것을 컨트롤에 이용가능하게 하는 인프라스트럭처는 컨트롤 프레임워크의 일부이다. 따라서, 익스펜도 속성인 'data-ent-member' 속성은 도 16의 HTML 프레그먼트(1605)에 나타낸 것과 같이 사용된다. 이러한 예에서, 'data-ent-member' 속성의 값이 내부 서비스에서 액션을 검색하고 실제 컨트롤에 인스턴스를 배치하는 데 사용된다. 이어서 컨트롤은 액션 특성이 (사실이면) 유효한 액션 및 데이터 바인드(valid action and data bind)라고 가정할 수 있고 그렇지 않으면 이를 조작하는 것으로 가정할 수 있다.

애니메이션은 흔히 사용자를 위한 매력적인 경험 세트를 생성하기 위해 사용된다. 스크린 상에 조화롭지 못한 시각적 플래시로서 나타나는 단순한 구성요소보다는 지속적이고 매력적인 경험을 가능하게 하기 위해, 본 발명의 UI 컨트롤 프레임워크의 목적은 컨트롤이 스스로 드러나게 하는 것이다. 컨트롤이 사례별로 개별적으로 이를 관리하게 하기보다는, 'data-ent-showanimation’ 및 ‘data-ent-hideanimation’의 익스펜도 속성이 사용되어 각각 보이거나 감춰지는 경우에 주어진 구성요소 상에서 플레이되는 CSS 애니메이션을 선언할 수 있다. ‘shown’은 구성요소가 자신이 보일 것이라고 믿을 수 있을 수 있으나 부모 구성요소의 가시성으로 인해 실제로는 보이지 않을 수 있다는 가능성을 고려한다는 점에 주의해야 한다. 이는 이러한 애니메이션이 있는 트리를 고려하는 경우에 애니메이션이 실제로 보이게 되는 경우에만 이러한 애니메이션이 플레이되어야 한다는 것을 의미한다. 또한, 이러한 애니메이션이 보이거나 감춰지는 경우에 자동으로 플레이되게 하는 것과 마찬가지로, 명시적으로 이러한 애니메이션을 시작하는 방법이 필요하다. 주로, 이는 DOM으로부터의 알려진 [remove|insert|append] Child 기능에 대한 대체 기능으로 여겨지는 기능을 중심으로 다룰 것이다. 기능 및 대응하는 설명의 완전한 세트를 이하의 표 6에 나타낸다.

애니메이션 처리에 대한 예시적인 실시예가 도 17의 HTML 프레그먼트(1705)에 표현된다. 이 예에는 두 개의 HTML 구성요소에 대한 두 개의 쇼 애니메이션이 존재한다. 이러한 구성요소가 보이게 되면, 이들은 속성이 설정되는 구성요소에 적용되는 애니메이션을 호출할 것이고, 개발자가 스스로 플레이하는 애니메이션을 관리하지 않게 할 수 있다. 또한, 이러한 애니메이션 기능에서, 가시성에 대해 프로그램가능한 컨트롤이 존재한다. 구체적으로, 보기/감추기 하기 위한(특성이 됨) 적합한 애니메이션을 플레이할 '가시성(visibility)' 불 특성(boolean property)이 존재하며, 이는 컨트롤 가시성에 대한 데이터 바인딩을 쉽게 할 수 있다.

도 18은 PC 또는 웹 서버 또는 본 발명의 UI 컨트롤 프레임워크를 구현할 수 있는 다른 서버와 같은 예시적인 컴퓨터 시스템(1800)의 간략한 블록도이다. 컴퓨터 시스템(1800)은 프로세서(1805), 시스템 메모리(1811) 및 시스템(1811)을 포함하는 다양한 시스템 컴포넌트를 프로세서(1805)에 연결하는 시스템 버스(1814)를 포함한다. 시스템 버스(1814)는 메모리 버스 또는 메모리 컨트롤러, 주변회로 버스 또는 다양한 버스 아키텍처 중 임의의 아키텍처를 사용하는 로컬 버스를 포함하는 복수의 유형의 버스 구조 중 어느 하나일 수 있다.

시스템 메모리(1811)는 판독 전용 메모리(ROM)(1817) 및 랜덤 액세스 메모리(RAM)(1821)를 포함한다. 스타트-업 동안과 같은, 컴퓨터 시스템(1800) 내의 구성요소들 사이의 정보를 전송하는 것을 돕는 기본적인 루틴들을 포함하고 있는, 기본적인 입력/출력 시스템(1825)(BIOS)은 ROM(1817)에 저장된다. 컴퓨터 시스템(1800)은 추가로 내부에 배치된 하드 디스크(도시되지 않음)에서 판독하고 기입하는 하드 디스크 드라이브(1828), 이동식 자기 디스크(1833)(예, 플로피 디스크)에서 판독하고 기입하는 자기 디스크 드라이브(1830), 및 CD(compact disk), DVD(digital versatile disc) 또는 다른 광학 매체와 같은 이동식 광 디스크(1843)에서 판독하고 기입하는 광 디스크 드라이브(1838)를 포함한다. 하드 디스크 드라이브(1828), 자기 디스크 드라이브(1830) 및 광 디스크 드라이브(1838)는 하드 디스크 드라이브 인터페이스(1846), 자기 디스크 드라이브 인터페이스(1849) 및 광 드라이브 인터페이스(1852)에 의해 각각 시스템 버스(1814)에 연결된다.

드라이브들 및 그들의 연관된 컴퓨터 판독가능 저장 매체는 컴퓨터 시스템(1800)을 위한 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 다른 데이터의 비휘발성 저장소를 제공한다. 도시된 실시예는 하드 디스크, 이동식 자기 디스크(1833) 및 이동식 광 디스크(1843)를 보여주지만, 자기 카세트, 플래시 메모리 카드, 디지털 비디오 디스크, 데이터 카트리지, RAM, ROM 등과 같은 컴퓨터에 의해 액세스 가능한 데이터를 저장할 수 있는 다른 유형의 컴퓨터 판독가능 저장 매체가 또한 본 발명의 UI 컨트롤 프레임워크의 일부 응용예에서 사용될 수 있다. 또한, 본 명세서에 사용된 컴퓨터 판독가능 매체라는 용어는 미디어 유형(예, 하나 이상의 자기 디스크, 하나 이상의 CD 등)의 하나 이상의 인스턴스를 포함한다.

운영체제(1855), 하나 이상의 애플리케이션 프로그램(1857), 다른 프로그램 모듈(1860) 및 프로그램 데이터(1863)를 포함하여 복수의 프로그램 모듈이 하드 디스크, 자기 디스크(1833), 광 디스크(1843), ROM(1817) 또는 RAM(1821)에 저장될 수 있다. 사용자는 커맨드 및 정보를 컴퓨터 시스템(1800)에 키보드(1866)와 같은 입력 장치 및 마우스와 같은 포인팅 장치(1868)를 통해 또는 내추럴 사용자 인터페이스("NUI")(도 18에 도시되지 않음)를 사용하여 음성을 통해 입력할 수 있다.

다른 입력 장치(도시되지 않음)는 마이크로폰, 조이스틱, 게임 패드, 위성 디스크, 스캐너 등을 포함할 수 있다. 이러한 다른 입력 장치는 흔히 직렬 포트 인터페이스(1871)(이는 시스템 버스(1814)에 연결되나 병렬 포드, 게임 포드 또는 버범용 직렬 버스("USB")와 같은 다른 인터페이스에 의해 연결될 수 있음)를 통해 프로세서(1805)에 연결된다. 모니터(1873) 또는 다른 유형의 디스플레이 장치 또한 비디오 어댑터(1875)와 같은 인터페이스를 통해 시스템 버스(1814)에 연결된다.

모니터(1873)에 추가하여, 개인 컴퓨터는 일반적으로 스피커 및 프린터와 같은 그 외 다른 주변 출력 장치(도시되지 않음)를 포함한다. 도 18에 도시된 실시예는 또한 호스트 어댑터(1878), 스몰 컴퓨터 시스템 인터페이스("SCSI") 버스(1883) 및 SCSI 버스(1883)에 연결된 외부 저장 장치(1876)를 포함한다.

컴퓨터 시스템(1800)은 원격 컴퓨터(1888)와 같은 하나 이상의 원격 컴퓨터에 대한 로직 연결을 사용하는 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(1888)는 개인 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 다른 공통 네트워크 노드일 수 있으며, 일반적으로 컴퓨터 시스템(1800)에 관련하여 전술한 구성요소 중 많은 또는 모든 구성요소를 포함하나, 도 18에는 하나의 대표적인 원격 메모리/저장 장치(1890) 만이 도시되어 있다.

도 18에 나타낸 로직 연결은 지역 네트워크("LAN")(1893) 및 광역 네트워크("WAN")(1895)를 포함한다. 그러한 네트워킹 환경은 흔히 예를 들어, 사무실, 전사적 컴퓨터 네트워크, 인트라넷 및 인터넷에서 이용된다.

LAN 네트워킹 환경에서 사용되는 경우에, 컴퓨터 시스템(1800)은 네트워크 인터페이스 또는 어댑터(1896)를 통해 LAN(1893)에 연결된다. WAN 네트워킹 환경에서 사용되는 경우에, 컴퓨터 시스템(1800)은 브로드밴드 모뎀(1898), 네트워크 게이트웨이 또는 인터넷과 같은 WAN(1895)을 통한 통신을 설정하기 위한 다른 수단을 포함한다. 브로드밴드 모뎀(1898)은 내장형 또는 외장형일 수 있으며, 직렬 포트 인터페이스(1871)를 통해 시스템 버스(1814)에 연결될 수 있다.

네트워크 환경에서, 컴퓨터 시스템(1800)과 관련된 프로그램 모듈, 또는 이들의 일부가 원격 메모리 저장 장치(1890)에 저장될 수 있다. 도 18에 도시된 네트워크 연결은 예시적이며, 특정한 응용예의 특정한 요구사항에 따라 컴퓨터 사이에 통신 링크를 설정하는 다른 수단이 사용될 수 있다는 점에 주의해야 한다.

발명의 대상이 구조적인 특징 및/또는 방법론적 행위에 특정된 언어로 기술되었으나, 첨부된 청구범위에서 한정된 발명의 대상은 위에서 기술된 특정한 특징들과 행위들로 제한될 필요가 없다는 점이 이해되어야 한다. 오히려 전술한 특정한 특징들과 행위들은 청구범위를 구현하기 위한 예시적인 형태로서 개시된다.

Claims

사용자 인터페이스("UI") 컨트롤 프레임워크를 구현하는 방법으로서,
캐스캐이딩 스타일 시트(CSS:Cascading Style Sheet) 및 하이퍼텍스트 마크업 언어(HTML: Hypertext Markup Language) 코드를 포함하는 마크업 문서를 생성하는 단계 - 상기 문서는 i) 적어도 하나의 UI 컨트롤 및 이의 레이아웃의 인라인 선언형 정의(inline declarative definition)를 포함하고, ii) 단일 인스턴스화된 템플릿으로서 사용됨 - 와,
복수의 UI 컨트롤 인스턴스를 상기 템플릿을 사용하여 스탬프 아웃(stamping out)하는 단계와,
각각의 UI 컨트롤 인스턴스에 대한 보조 컨트롤(backing control)을 일대일 기반으로 생성하는 단계와,
상기 템플릿의 HTML 구성요소와 연관된 익스펜도 속성(expando attribute)을 사용하는 단계 - 상기 속성은 상기 보조 컨트롤이 상기 레이아웃의 임의의 자식 UI 컨트롤에 직접 액세스할 수 있도록 컨트롤 인스턴스에 명명된 특성(named property)을 배정함 -
를 포함하는 사용자 인터페이스 컨트롤 프레임워크 구현 방법.
제1항에 있어서,
상기 HTML은 HTML 버전 5("HTML5")이고, 상기 CSS는 CSS 레벨 3("CSS3")인
사용자 인터페이스 컨트롤 프레임워크 구현 방법.
제1항에 있어서,
상기 HTML 구성요소는 UI 컨트롤을 나타내는
사용자 인터페이스 컨트롤 프레임워크 구현 방법.
제1항에 있어서,
상기 보조 컨트롤은 자바스크립트를 사용하여 구현되는
사용자 인터페이스 컨트롤 프레임워크 구현 방법.
제1항에 있어서,
상기 속성은 앵커 포인트(anchor point)가 상기 마크업 문서에 정의될 수 있게 하는
사용자 인터페이스 컨트롤 프레임워크 구현 방법.
제5항에 있어서,
상기 앵커 포인트의 명칭이 수정(revision) 중에 계속 유지되면서 레이아웃이 수정되는
사용자 인터페이스 컨트롤 프레임워크 구현 방법.
제1항에 있어서,
상기 보조 컨트롤은 일대일 기반으로 스탬프 아웃된 레이아웃에 매핑되는
사용자 인터페이스 컨트롤 프레임워크 구현 방법.
제1항에 있어서,
상기 레이아웃은 상기 UI 컨트롤을 구현하는 애플리케이션 아래의 비즈니스 로직에 느슨하게 연결되는(loosely coupled)
사용자 인터페이스 컨트롤 프레임워크 구현 방법.
제1항에 있어서,
상기 보조 컨트롤은 UI 컨트롤이나 자식 컨트롤에 바인딩할 데이터를 제공하고,
상기 보조 컨트롤은 상기 자식 컨트롤에 대한 직접적인 지식 없이도 상기 데이터를 추상적으로 제공하는
사용자 인터페이스 컨트롤 프레임워크 구현 방법.
제1항에 있어서,
상기 HTML 코드는 상기 익스펜도 속성을 사용하여 특정된 앵커 포인트를 포함하는
사용자 인터페이스 컨트롤 프레임워크 구현 방법.