KR100969720B1 - 그래픽 출력 레이아웃 관리 시스템, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템, 레이아웃을 처리하기 위한 방법, 레이아웃의 처리를 용이하게 하기 위한 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 저장 매체 - Google Patents

Abstract

한 세트의 그래픽 요소가 할당되어 있는 애플리케이션 뷰의 레이아웃을 유지하는 것을 용이하게 하는 표현자 세트를 호스팅하기 위한 표현자 시스템 프레임워크 및 이러한 프레임워크에 의해 수행되는 방법에 대해 기술되어 있다. 표현자 시스템은 지정된 뷰 내에서의 레이아웃 동작 동안 여러가지 그래픽 요소 데이터 타입을 처리하기 위한 확장가능한 한 세트의 표현자 클래스를 생성 및 통합하기 위해 표현 엔진에 의해 수행되는 한 세트의 인터페이스 메소드 및 표현자 기본 클래스를 제공한다. 표현자 시스템은 애플리케이션 사용자 인터페이스 개발자가 표현 엔진의 호출을 통해 복잡한 표시 레이아웃 동작을 구현할 수 있도록 해준다. 이러한 복잡한 표시 레이아웃 동작의 일례로는 페이지 분할, 부분적 계산, 점진적 계산, 다중 트리, 레이아웃 기능/동작의 체인화가 있다.

표현자, 렌더링, 그래픽 출력, 기본 클래스, 메소드

Description

그래픽 출력 레이아웃 관리 시스템, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템, 레이아웃을 처리하기 위한 방법, 레이아웃의 처리를 용이하게 하기 위한 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 저장 매체{SYSTEM FOR HOSTING GRAPHICAL LAYOUT/PRESENTATION OBJECTS}

본 발명은 일반적으로 컴퓨팅 장치에 관한 것이다. 보다 상세하게는, 본 발명은 그래픽 문서/사용자 인터페이스를 통해 표시되는 그래픽 요소를 정렬하는 컴퓨팅 컴포넌트에 관한 것이다.

컴퓨팅 시스템 상에서 실행되는 애플리케이션의 그래픽 출력을 표시(display) 및/또는 렌더링하는 일에는 많은 작업이 포함된다. 이러한 작업의 하나로 레이아웃(layout)/표현(presentation) 관리가 있다. 레이아웃/표현 관리는 한 세트의 표시 요소(display element)를 그의 할당된 표시 공간(예를 들면, 사각형) 내에 정렬하여 이를 장식하는 것과 관계가 있다. "레이아웃"과 "표현"이 다른 상황에서는 서로 구별될 수 있는 것일 수도 있지만, 표현과 레이아웃은 본 명세서에서 사용되는 바와 같이 서로 교환가능하고 동등한 용어로서 취급되어야만 한다. 레이아웃/표현 시스템에 의해 처리되는 표시 요소는 그래픽 출력 시스템 및 그래픽 디스플레이 드라이버의 렌더링 컴포넌트에 그래픽 출력 데이터를 제공한다. 이러한 렌더링 컴포넌트는 모니터 및 프린터 등의 그래픽 디스플레이 하드웨어를 구동한다.

컴퓨팅 시스템에 의해 실행되는 레이아웃/표현 동작은 그래픽 표시 요소에 대해 수행되는 광범위한 기능들을 포함한다. 이러한 동작의 일례로는 에디터 애플리케이션(editor application)의 그래픽 디스플레이 사용자 인터페이스의 할당된 영역 내에 텍스트를 정렬하는 것이 있다. 레이아웃 동작은 지정된 사각형 공간 내의 텍스트 행의 내용 및 배치를 결정한다. 다른 일례로는 요소(예를 들어, 대화 상자, 툴바(toolbar), 콘트롤 바(control bar), 등)를 표준화된 경계로 둘러싸는 것이 있다. 이들 동작을 본 명세서에서는 "기능"(feature)이라고도 한다. 컴퓨터 시스템의 렌더링 컴포넌트는 이전에 실행된 레이아웃/표현 동작/기능에 의해 수정될 수도 있는 표시 요소의 상태에 기초하여 그래픽 출력 데이터를 생성한다.

여러가지 표현 엔진(presentation engine)이 공지되어 있다. 예를 들어, MICROSOFT WINDOWS의 "사용자 모듈"(user module)은 그래픽 사용자 인터페이스에 대해 최상위 레벨 윈도우에 관한 레이아웃 동작을 수행한다. MICROSOFT WINDOWS의 대화 상자 관리자(dialog box mananger)는 사전 정의된 위치에 객체를 배치하고 객체의 그룹화를 가능하게 해준다. 객체의 배치는 논리적 방식으로 행해지며, 물리적 장치에 독립적이다. JAVA SWING에서는 객체에 지정된 프로퍼티(property)에 기초하여 뷰 내에서의 객체에 관한 기본적인 배치 동작을 행할 수 있다.

레이아웃/표현 동작은 다수의 방식으로 수행되어 왔다. 애플리케이션 자신이 그의 표시 요소 레이아웃 동작을 전부 수행할 수 있다. 레이아웃 (또는 "표현") 동작은 애플리케이션 내에 캡슐화되어 있다. 애플리케이션은 그 자신의 현재의 상태와 관련된 뷰 또는 뷰들의 표시 요소를 장식/정렬한다. 애플리케이션은 그 자신에 할당된 표시 영역 내에 요소들을 정렬한다. 그 후에, 애플리케이션 은 정렬된 표시 요소에 대응하는 표시 출력을 그래픽 시스템/드라이브로 렌더링한다.

MICROSOFT WINDOWS XP 운영 체제 내에 포함되어 있는 다른 레이아웃 처리 구성은 애플리케이션에 의해 호출될 수 있는 한 세트의 미리 정의된 레이아웃 기능에 대한 지원을 제공한다. 한 세트의 레이아웃 기능은 애플리케이션의 사용자 인터페이스 그래픽 표시 요소에 대한 전용의 레이아웃/표현 동작을 포함한다. 예를 들어 제공된 사각형의 경계 발생기(border generator) 등의 한 세트의 사전 정의된 레이아웃/표현 기능은 그래픽 표시 요소를 구성하여 표현하는 일의 특정 측면과 관련하여 애플리케이션 개발자의 프로그래밍 부담을 덜어준다. 한 세트의 사전 정의된 기능은 또한 전술한 경계 등의 어떤 기본적인 표시 기능/함수의 실행과 관련하여 일관성을 증진시킨다. 애플리케이션은 그 애플리케이션 자체 내에 내장된 부가의 레이아웃 동작으로 사전 정의된 레이아웃 기능을 보충한다.

애플리케이션에 의해 호출될 수 있는 사전 정의된 레이아웃 기능을 비롯한 공지의 레이아웃 처리 아키텍처는 그래픽 데이터 및 명령을 컴퓨터 시스템의 렌더링 컴포넌트로 렌더링하기에 앞서 뷰를 정렬하는 과정 동안에 애플리케이션이 만나게 되는 프로그래밍 레이아웃 작업을 단순화시킨다. 그렇지만, 공지의 레이아웃 처리 아키텍처에서는 애플리케이션에 의해 호출될 수 있는 한 세트의 사전 정의된 레이아웃 기능에 관한 개선 또는 수정에 대한 지원이 용이하지 않다. 따라서, 예를 들어, 새로운 레이아웃 기능은 그 기능을 표현/레이아웃 아키텍처에 의해 제공되는 사전 정의된 레이아웃 기능에 집어 넣기보다는 오히려 애플리케이션 코드 내 에 직접 들어 있다. 그 후에, 실행 동안, 애플리케이션은 사전 정의된 레이아웃 기능과 내부적으로 실행되는 레이아웃/표현 동작의 조합을 사용하여 레이아웃을 계산한다.

본 발명은 그래픽 출력 레이아웃 관리 시스템 내에 포함시키기 위한 표현자 시스템을 포함한다. 이러한 레이아웃 관리는 객체가 표시 공간 상에 정렬되고, 크기 조정되며 배치되는 방식에 관한 것이다. 이러한 시스템은 프로그램의 표시 가능 내용을 표현하는 데이터를 포함하는 그래픽 요소(예를 들어, 표시되거나 인쇄된 페이지 상에 정렬될 필요가 있는 텍스트 블록)를 제공하는 그 프로그램을 대신하여 레이아웃을 처리한다. 표현자(presenter)는 그래픽 요소의 내용을 표현하기 위한 표시 상태(display state)를 정의함으로써 (데이터를 지정하는) 그래픽 요소에 대해 우호적 역할을 수행한다. 이와 같이, 표현자는 대응하는 그래픽 요소에 대한 레이아웃 설명을 유지하고 있다.

본 발명에 따르면, 표현자 시스템(presenter system)은 뷰 내의 그래픽 요소와 관련된 표현자를 호스팅 및 정렬한다. 표현자 시스템은 많은 타입의 표현자의 파생을 지원하는 역할을 하며, 표현자 기본 클래스(presenter base class)를 포함하며, 이 표현자 기본 클래스로부터 표현자 클래스가 파생된다. 그 후에, 표현자는 파생된 표현자 클래스로부터 인스턴스화된다.

표현자 시스템은 또한 표현자 호스트 인터페이스(presenter host interface)를 포함한다. 이 호스트 인터페이스는 그래픽 요소와 관련된 표현자에 따라 뷰 내의 그래픽 요소를 레이아웃하는 메소드(method)를 포함한다. 이와 같이, 뷰 내의 그래픽 요소의 레이아웃은 관련된 표현자에 의해 지정된다.

첨부된 청구항들이 본 발명의 특징들에 대해 상세히 기술하고 있지만, 본 발명 및 그 이점은 첨부 도면과 연계하여 기술된 이하의 상세한 설명으로부터 잘 이해될 것이다.

도 1은 본 발명의 일 실시예를 수행하기 위한 예시적인 컴퓨터 시스템을 나타낸 블록도.

도 2는 본 발명을 구현하는 컴퓨팅 시스템에서 그래픽 레이아웃 관리를 수행하는 표현자 시스템을 포함한 레이아웃 관리 아키텍처의 주요 컴포넌트를 나타낸 상위 레벨 개략도.

도 3은 본 발명을 구현하는 시스템에서 그래픽 문서/사용자 인터페이스를 정의하는 표현자와 그래픽 요소 사이의 관계를 나타낸 개략도.

도 4a 및 도 4b는 표현자 기본 클래스의 구조를 요약한 도면으로서, 본 발명을 구현하는 시스템에서 특정의 레이아웃/렌더링 작업을 수행하기 위한 커스터마이즈된 표현자 객체 클래스가 이 표현자 기본 클래스로부터 파생됨.

도 5는 자식 프록시 클래스의 구조를 요약한 도면.

도 6은 통지 핸들러 클래스 인터페이스의 구조를 요약한 도면.

도 7은 통지 핸들러 사이트 클래스의 구조를 요약한 도면.

도 8은 뷰 클래스의 구조를 요약한 도면.

도 9는 BoxSizeInfo 구조의 일부를 요약한 도면.

도 10은 페이지 기술자 구조의 일부를 요약한 도면.

도 11은 표현 엔진 클래스의 구조를 요약한 도면.

도 12는 그래픽 요소에 대한 변동의 통지 핸들러 기반 처리를 위한 예시적인 단계를 요약한 흐름도.

도 13은 본 발명의 일 실시예에 따라 한 세트의 표현자를 포함하는 뷰를 재계산 및 렌더링하기 위한 예시적인 단계들을 요약한 흐름도.

도 14는 관련된 그래픽 요소에 대한 변동에 응답하여 표현자 (및 영향을 받은 관련된 자식)에 대해 갱신을 실행하는 단계들을 나타낸 흐름도.

본 명세서에는 사용자 인터페이스 및 문서 레이아웃/표현 아키텍처에 대해 개시되어 있다. 개시되어 있는 레이아웃/표현 아키텍처는 문서/사용자 인터페이스에 있어서의 관련된 기반 데이터(그래픽 요소)의 뷰 측면을 실행하는 그래픽 레이아웃 처리/렌더링 컴포넌트(표현자)를 포함한다. 표현자 시스템은 표현자를 호스팅한다. 표현자 시스템은, 그의 호스트 역할에 있어서, 대응하는 그래픽 요소에 대한 변동에 응답하여 한 세트의 표현자를 포함하는 뷰를 갱신하는 일을 오케스트레이션(orchestrate) 및 조정(coordinate)한다. 따라서, 표현자 시스템은 그래픽 요소의 상태(예를 들어, 데이터 상태)를 대응하는 표현자 객체에 의해 갱신, 캐싱 및 렌더링되는 뷰 상태에 링크시키는 메카니즘을 제공한다.

본 발명을 구현하는 표현자 시스템 기반의 레이아웃/표현 아키텍처의 한 특징은 그 시스템이 호스팅하는 표현자의 타입에 관해 확장성이 아주 높다는 것이다. 표현자 시스템에 의해 제공되는 표현자 기본 클래스는 대응하는 그래픽 요소에 의해 제공되는 정보를 레이아웃 및 렌더링하는 데 이용가능한 한 세트의 표현자 타입(객체 클래스)의 확장이 용이하도록 해준다. 표현자 기본 클래스로부터 파생된 여러가지 표현자 타입은 표현자 기본 클래스에 의해 지정된 디폴트 메소드에 대한 재정의(override)로서의 특정 레이아웃/렌더링 메소드를 포함한다. 한 세트의 표현자 객체 클래스로부터 인스턴스화된 표현자 객체는 대응하는 그래픽 요소의 데이터 상태에 따라 레이아웃/표현 기능을 구현한다.

표현자 시스템은 한 세트의 표현자 객체 클래스로부터 인스턴스화된 표현자 객체를 호스팅한다. 표현자 시스템은 표현자 객체의 수명 관리(즉, 생성, 삭제 등)를 수행한다. 표현자 시스템은 변동된 표현자만을 선택적으로 갱신하기 위해 더티 트래킹(dirty tracking)을 사용한다. 표현자 시스템은 메인 표현자(main presenter)에 장식을 제공하기 위해 표현자 모두를 체인화(chain)하는 것을 지원한다. 표현자 시스템은 또한 표현자를 갱신 및 렌더링하는 일도 조정한다.

뷰 상태(view state)에 영향을 줄 수 있는 그래픽 요소에 대한 변동의 통지는 본 발명의 일 실시예에서는 통지 핸들러(notification handler)에 의해 용이하게 행해진다. 통지 핸들러는 변동 통지 처리가 표현자에 의해 수행되는 변동 처리와 분리될 수 있게 해준다. 각각의 표현자 요소 타입은 통지 핸들러 타입과 관련되어 있다. 각각의 통지 핸들러는 대응하는 그래픽 요소에 대한 변동을 처리한다. 갱신이 필요한 경우, 통지 핸들러는 관련된 표현자 객체에 대한 더티니스 프로퍼티(dirtiness property)의 설정을 개시한다. 더티니스 프로퍼티가 설정되어 있으면 대응하는 그래픽 요소에 대한 변동에 응답하여 표현자 객체를 재계산해야 한다.

본 명세서에 일례로서 기술되어 있는 사용자 인터페이스 레이아웃/표현 아키텍처는 그래픽 사용자/문서 인터페이스를 갖는 애플리케이션을 호스팅하는 운영 체제 내에 포함되어 있다. 장치 고유 드라이버와 운영 체제의 장치 고유 렌더링 컴포넌트, 표현자 및 애플리케이션은 인터페이스/문서 그래픽 출력 장치 제어 명령/데이터를 디스플레이 장치 하드웨어(예를 들어, 모니터, 프린터 등)로 렌더링한다. 렌더링된 출력의 레이아웃 기능은 적어도 부분적으로는 표현자 시스템에 의해 호스팅되는 표현자에 의해 수행되는 레이아웃/표현 처리 및 렌더링에 기초하고 있다.

표현 아키텍처는 표시된 요소의 데이터 상태를 그의 뷰 상태와 분리시키는 것을 가능하게 해준다. 이러한 분리(disassociation)는 기반 그래픽 요소에 대한 새롭고 다채로운 표시 특징을 생성하기 위한 확장성있고 고도로 커스터마이즈 가능한 플랫폼(extensible and highly customizable platform)을 제공한다. 본 발명의 일 실시예에서, 표시 요소는 그래픽 요소 객체(요소의 데이터 상태를 나타냄) 및 특정 뷰에 요소를 레이아웃하기 위한 적어도 하나의 관련 표현자 객체(뷰 상태를 나타냄)에 의해 표현된다. 표현자는 관련된 요소의 레이아웃에 대한 커스터마이즈된 갱신을 수행한다. 표현자는 또한 레이아웃을 갱신한 후에 그 요소의 뷰를 렌더링한다.

표현자 객체를 사용함으로써 표시된 요소의 데이터 상태와 뷰에서의 그의 표 시를 분리시킨다. 그 결과, 각 그래픽 요소(표시 데이터 소스)는 그래픽 요소의 별개의 뷰(예를 들면, 사진 요소의 실물 크기(full scale) 뷰 및 축소된(thumbnail) 뷰)를 제공하는 다수의 표현자를 가질 수 있다. 다수의 표현자를 하나의 그래픽 요소와 관련시키는 기능은 또한 하나의 요소가 필드 내의 다수의 장소와 관련될 수 있게 해준다(예를 들면, 하나의 그래픽 요소를 다수의 단(column)으로 분할함). 또한, 표현자 시스템은 서로 다른 타입의 다수의 별개의 표현자를 하나의 요소에 체인화(chain)시킴으로써 다양한 커스터마이즈된 장식을 요소의 기본 뷰에 첨부하는 것을 지원한다. 이들은 물론 예시적인 표시 레이아웃/렌더링 아키텍처의 다른 특징에 대해 도면을 참조하여 이하에 기술한다.

도 1은 본 발명을 구현하는 표현자 시스템 기반의 표시 레이아웃/렌더링 아키텍처를 수행하기에 적당한 운영 환경(100)의 일례를 예시한 것이다. 운영 환경(100)은 적당한 운영 환경의 한가지 일례에 불과한 것으로서, 본 발명의 사용 또는 기능의 범위에 관한 어떤 한정을 암시하기 위한 것이 아니다. 본 발명과 함께 사용하기에 적당할 수 있는 다른 공지의 컴퓨팅 시스템, 환경 및/또는 구성으로는 퍼스널 컴퓨터, 서버 컴퓨터, 랩톱/휴대용 컴퓨팅 장치, 핸드-헬드 컴퓨팅 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기 시스템이나 장치 등의 어느 것이라도 포함하는 분산 컴퓨팅 환경이 있지만, 이에 한정되는 것은 아니다. 표현자 시스템을 비롯한 개시되어 있는 레이아웃 관리 아키텍처는 도 1에 도시한 것과 같은 컴퓨팅 시스템의 표시 기능에 관한 확장성(extensibility), 통합성(integration), 및 균일성(uniformity)을 비롯한 다수의 다양한 관심사를 제공한다.

본 발명에 대해서는 일반적으로 컴퓨터에 의해 실행되고 있는 프로그램 모듈 등의 컴퓨터 실행가능 명령어에 의해 수행되는 일련의 단계 및 프로세스와 관련하여 기술되어 있다. 일반적으로, 프로그램 모듈에는 특정의 작업을 수행하거나 특정의 추상 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 아키텍처 등이 포함된다. 예시적인 실시예가 하나의 컴퓨터 시스템 상에서 국부적으로 실행되는 프로세스를 참조하여 기술되어 있지만, 본 발명은 작업들이 통신 네트워크를 통해 링크되어 있는 원격 처리 장치들에 의해 수행되는 분산 컴퓨팅 환경에서 동작하는 네트워크 노드 내에서 실시될 수도 있을 것이다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 일반적으로 메모리 저장 장치를 비롯한 국부 및 원격 컴퓨터 저장 매체 양쪽 모두에 위치하고 있다.

계속하여 도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(110)의 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들로는, 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 프로세싱 유닛(120)에 연결시키는 시스템 버스(121)가 포함될 수 있지만, 이에 한정되는 것은 아니다. 시스템 버스(121)는 다양한 버스 아키텍처 중의 임의의 것을 사용하는 로컬 버스, 주변 버스, 및 메모리 버스 또는 메모리 컨트롤러를 포함하는 몇가지 타입의 버스 아키텍처 중의 임의의 것일 수 있다. 예로서, 이러한 아키텍처는 산업 표준 아키텍처(ISA) 버스, 마이크로 채널 아키텍처(MCA) 버스, 확장 ISA(Enhanced ISA; EISA) 버스, 비디오 일렉트로닉스 표준 어 소시에이션(VESA) 로컬 버스, 및 (메자닌(Mezzanine) 버스라고도 하는) 주변 컴포넌트 상호접속(PCI) 버스를 포함하지만, 이에 한정되는 것은 아니다.

컴퓨터(110)는 통상적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있으며, 휘발성 및 비휘발성 매체, 이동식(removable) 및 비이동식(non-removable) 매체를 둘다 포함한다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만, 이에 한정되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 모두 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광학 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 기타 자기 저장장치, 또는 컴퓨터(110)에 의해 액세스될 수 있고 원하는 정보를 저장하는 데 사용될 수 있는 임의의 기타 매체를 포함할 수 있지만, 이에 한정되지 않는다. 통신 매체는 통상적으로 반송파 또는 기타 전송 메카니즘 등의 변조된 데이터 신호에 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈, 또는 기타 데이터를 구현하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는, 신호 내에 정보를 인코딩하도록 그 신호의 특성 중 하나 이상이 설정되거나 변경된 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크 또는 직접 배선 접속 등의 유선 매체와, 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함하지만, 이에 한정되지 않는다. 상술한 것들 중의 임의의 조합도 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.

시스템 메모리(130)는 ROM(131) 및 RAM(132) 등의 휘발성 및/또는 비휘발성 메모리의 형태의 컴퓨터 저장 매체를 포함한다. 시동중과 같은 때에 컴퓨터(110) 내의 구성요소들간에 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(133; BIOS)은 때로는 ROM(131)에 저장된다. RAM(132)은 일반적으로 프로세싱 유닛(120)에 의해 즉시 액세스될 수 있는 것 및/또는 프로세싱 유닛(120)에 의해 현재 작동되고 있는 것인 프로그램 모듈 및/또는 데이터를 포함한다. 예로서, 도 1에는 운영 체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)가 도시되어 있지만, 이에 한정되는 것은 아니다.

컴퓨터(110)는 또한 다른 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장 매체도 포함할 수 있다. 단지 예로서, 도 1에는 비이동식 비휘발성 자기 매체로부터 판독하거나 그 자기 매체에 기록하는 하드 디스크 드라이브(141), 이동식 비휘발성 자기 디스크(152)로부터 판독하거나 그 자기 디스크에 기록하는 자기 디스크 드라이브(151), 및 CD-ROM 또는 기타 광학 매체 등의 이동식 비휘발성 광학 디스크(156)로부터 판독하거나 그 광학 디스크에 기록하는 광학 디스크 드라이브(155)가 도시되어 있다. 예시적인 운영 환경에서 사용될 수 있는 다른 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래쉬 메모리 카드, DVD(Digital versatile disk), 디지털 비디오 테이프, 고상(solid state) RAM, 고상 ROM 등을 포함하지만 이에 한정되지 않는다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 비이동식 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광학 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 이동식 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

앞서 기술되고 도 1에 도시된 드라이브 및 그 관련 컴퓨터 저장 매체는 컴퓨터(110)에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 제공한다. 도 1에서, 예를 들어, 하드 디스크 드라이브(141)는 운영 체제(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)를 저장하는 것으로 도시되어 있다. 이들 컴포넌트는 운영 체제(134), 애플리케이션 프로그램(135), 다른 프로그램 모듈(136), 및 프로그램 데이터(137)와 동일한 것이거나 그와 다른 것일 수 있음에 유의한다. 운영 체제(144), 애플리케이션 프로그램(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 이들이 서로 다른 사본(different copies)임을 나타내기 위하여 다른 번호를 부여하였다. 사용자는 일반적으로 마우스, 트랙볼, 또는 터치 패드라 불리우는 포인팅 장치(161) 및 키보드(162)와 같은 입력 장치를 통해 컴퓨터(110)에 명령 및 정보를 입력할 수 있다. (도시되지 않은) 기타 입력 장치로는 마이크, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등이 있을 수 있다. 이들 입력 장치 및 그외의 입력 장치는 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 종종 프로세싱 유닛(120)에 접속되지만, 병렬 포트, 게임 포트 또는 유니버설 시리얼 버스(USB)와 같은 기타 인터페이스 및 버스 구조에 의해 접속될 수 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치도 비디오 인터페이스(190) 등의 인터페이스를 통해 시스템 버스(121)에 접속될 수 있다. 모니터 외에도, 컴퓨터는 또한 출력 주변 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196) 등의 기타 주변 출력 장치도 포함할 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용하여 네트워크화된 환경에서 운영될 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어(peer) 장치, 또는 기타 공통 네트워크 노드(common network node)일 수 있으며, 컴퓨터(110)에 관하여 상술한 구성요소 중 다수 또는 그 모두를 일반적으로 포함할 수 있지만, 도 1에는 메모리 저장 장치(181)만이 도시되어 있다. 도 1에 도시된 논리적 접속은 근거리 통신망(LAN; 171) 및 원거리 통신망(WAN; 173)을 포함하지만, 그 외의 네트워크/버스도 포함할 수 있다. 이러한 네트워킹 환경은 사무실, 전사적 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷, 및 인터넷에서 일반적인 것이다.

LAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(110)는 일반적으로 인터넷 등의 WAN(173)을 통해 통신을 설정하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메카니즘을 통해 시스 템 버스(121)에 접속될 수 있다. 네트워크화된 환경에서, 컴퓨터(110)에 관련하여 도시된 프로그램 모듈 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수 있다. 예로서, 도 1에서는 원격 애플리케이션 프로그램(185)이 메모리 장치(181)에 상주하는 것으로 도시되어 있지만, 이에 한정되는 것은 아니다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들간의 통신 링크를 구축하는 그 외의 수단이 사용될 수 있음을 잘 알 것이다.

도 2는 본 발명을 구현하는 레이아웃/표현 관리 시스템 아키텍처의 인스턴스화된 객체 및 데이터 컴포넌트 뿐만 아니라 소프트웨어 모듈 및 프로그램을 나타낸 상위 레벨 개략도이다. 도 2에 도시한 예시적인 레이아웃/표현 관리 시스템 아키텍처는 운영 체제(205) 상에서 실행되는 애플리케이션(204)의 요청이 있을 시 뷰 객체 클래스(view object class)(이하에 기술되는 도 8을 참조할 것)로부터 생성된 뷰(202)와 관련된 한 세트의 계층 구조로 정렬된 표현자 객체에 기초하여 표시 가능 객체의 레이아웃/표현을 지원하는 표현자 시스템(200)을 포함한다.

본 발명의 일 실시예에서, 각각의 뷰(예를 들어, 뷰(202))는 뷰 내의 표시 가능 객체를 관리하는 일을 맡고 있는 대응하는 표현자 시스템(예를 들어, 표현자 시스템(200))을 갖는다. 본 발명의 일 실시예에서, 뷰(202)는 표현자 시스템(200)에 의해 생성된 모든 비쥬얼(visual)의 비쥬얼 루트(visual root)이다. 뷰(202) 내의 표시된 내용은 배킹 스토어(backing store)(208) 내의 그래픽 요소(206)에 기초하고 있다. 애플리케이션(204)은 배킹 스토어(208) 내의 그래픽 요소(206)의 소스이다. 애플리케이션과 관련된 뷰, 표현자 시스템, 뷰의 표현자 트리, 및 그래픽 요소 트리 사이의 관계를 나타내는 예시적인 일례가 이하에 기술되는 도 3에 도시되어 있다.

도 2에 도시된 레이아웃/표현 관리 시스템 아키텍처는 한 세트의 기능(functional) 컴포넌트로 분할된다. 도시된 컴포넌트 사이의 선은 컴포넌트 사이의 상호 작용 경로를 나타낸다. 본 발명은 도 2에 도시된 예시적인 실시예에서 컴포넌트 및 그의 표시된 예시적인 상호작용의 특정 구성에 한정되지 않는다. 오히려, 이하에 기술되는 컴포넌트들의 기능은 본 발명의 대체 실시예에 따라 여러가지 방식으로 그룹화된다.

본 발명의 일 실시예에서, 애플리케이션(204)은 뷰(202) 객체 인스턴스의 루트 객체를 생성하기 위해 뷰 객체 클래스 애플리케이션 프로그램 인터페이스(이하에 기술되는 도 8의 뷰 클래스 구조를 참조할 것)의 생성자 메소드(constructor method)를 호출한다. 뷰(202)를 생성하기 위한 메소드 호출은 배킹 스토어(208)에 들어 있는 그래픽 요소(206)의 루트 그래픽 요소에 대한 참조(reference)를 전달한다. 뷰(202)를 생성한 후에, 뷰(202)에 대한 DoLayout 메소드의 호출은 뷰(202)를 생성한 생성자 메소드로 초기에 전달된 루트 그래픽 요소에 대응하는 루트 표현자 객체를 사용하여 뷰(202)의 표현자 트리를 생성한다. 뷰(202)의 표현자 트리(도 2에 도시되어 있지 않음)는 뷰(202)의 비쥬얼 출력을 구성 및 렌더링하는 일을 맡고 있는 한 세트의 표현자를 포함한다.

본 발명의 일 실시예에서, 각각의 뷰(예를 들어, 뷰(202))는 표현자 시스템(예를 들어, 표현자 시스템(200))을 소유한다. 따라서, 뷰(202)는 DoLayout 메소드 에 응답하여, 새로운 표현자 트리의 생성을 개시하고 이를 호출자(caller)(예를 들어, 애플리케이션(204))에게 반환한다. 처음에, 뷰(202)는 표현자 호스트 애플리케이션 프로그램 인터페이스(표현자 호스트 API)를 포함한 표현 엔진(212) 인스턴스를 생성하기 위해 표현 엔진 객체 클래스의 생성자 메소드를 호출한다. 표현 엔진(212)은 그래픽 출력을 지원하는 컴퓨팅 시스템에서 레이아웃/표현 동작의 실행을 조정 및 오케스트레이션하기 위한 실행가능 코드를 포함한다. 표현 엔진(212)에 의해 수행/조정되는 기능으로는, 표현자 객체(루트 객체 및 자식 객체 모두)를 생성하는 것, 표현자의 표시 상태의 재계산을 조정하는 것, 렌더링, 표현자의 수명 관리, 더티 트래킹, 다수의 표현자를 하나의 요소에 체인화하는 것, 및 점진적 레이아웃(incremental layout)을 수행하는 것이 있다. 표현 엔진(212)의 표현자 호스트 API에서 호출가능한 메소드의 일례가 도 12를 참조하여 이하에 기술되어 있다. 이들 메소드는 뷰(202)의 표현자 객체 트리를 생성 및 관리하는 상위 레벨 요청이다. 표현 엔진(212)에 의해 수행되는 기술한 작업들은 예시적인 것으로서, 당업자라면 본 발명의 대체 실시예에서 부가의/대체 작업이 표현 엔진(212)에 의해 수행될 수 있음을 잘 알 것이다.

표현 엔진(212)은 뷰(202)와 관련된 표현자 객체를 처리하기 위한 표현자 시스템(200)을 구성한다. 본 발명의 실시예에서, 표현자 시스템(200)은 표현자 기본 클래스(216)를 포함한다. 표현자 기본 클래스(216)는 본 명세서에 기술된 시스템의 레이아웃 관리 기능을 이용할 수 있는 표현자 서브클래스 및 표현자 객체를 생성하기 위한 전 기능을 갖춘 기본 클래스(full featured base class)이다. 표현자 기본 클래스(216)는 가상 (재정의가능한(overridable)) 프로그램 코드 및 데이터 구조를 포함하는 템플릿(template)을 포함하며, 그로부터 한 세트의 표현자 클래스(214)가 파생된다. 표현자 클래스(214)는 특정 표시 프로퍼티/거동(behavior)을 갖는 그래픽 요소들로 된 뷰에 대응하는 한 세트의 특수 표현자 타입을 포함한다. 표현자 기본 클래스(216)로부터 파생된 커스터마이즈된 표현자 클래스(214)는 일례로서 내용을 레이아웃하고, 자식을 정렬하며, 첨부된 요소의 비쥬얼(visual)을 생성하고, 인쇄 문서의 내용을 페이지 분할(paginate)하며, 그래픽 요소(206)를 포함한 비쥬얼을 점진적으로 갱신한다. 한 세트의 표현자 클래스(214) 내의 각 표현자 클래스의 전용 기능은 표현자 기본 클래스(216)에 의해 정의된 가상 메소드(virtual method)를 재정의하고 보충함으로써 설정된다. 한 세트의 표현자 클래스(214)로부터 인스턴스화된 표현자 객체는 그래픽 요소(206)의 표시 측면을 표현하고 처리한다.

본 발명의 일 실시예에서, 사전 정의된 표현자 클래스(218) 및 외부 표현자 클래스(220) 모두를 포함한 한 세트의 표현자 객체 클래스(214)는 확장 가능하다. 한 세트의 사전 정의된 표현자 클래스(218)는 표현자 시스템(200)을 갖추고 있다. 외부 표현자 객체 클래스(220)는 일반적으로 표현자 시스템(200)에 독립적으로 설치된다. 그렇지만, 외부 표현자 객체 클래스(220)를 표현자 시스템(200)과 적절히 통합시키는 일은 표현자 기본 클래스(216)(도 4a 및 도 4b를 참조하여 이하에 기술됨)의 공표된 인터페이스 사양에 의해 용이하게 이루어진다. 외부 표현자 클래스(220)의 개발자는 커스텀 크기 조정(custom sizing) 기능, 자식 배치(child position) 기능, 및 렌더링 기능을 달성하기 위해 표현자 기본 클래스(216)의 커스터마이즈가능한 레이아웃/렌더링 메소드와 관련된 데이터 구조 및 프로그램 코드를 재정의/수정한다. 그 후에, 새로운 표현자 클래스는, 예를 들면 새로운 객체 클래스를 포함하는 파일을 컴퓨터의 파일 시스템 내의 지정된 디렉토리에 설치함으로써 한 세트의 외부 표현자 객체 클래스(220)에 설치된다.

본 발명의 일 실시예에서, 표현자 클래스(214)는 예를 들어 내용 레이아웃(content layout), 자식 객체 정렬, 비쥬얼 생성, 문서 내용 페이지 분할, 및 비쥬얼(예를 들면, 다수의 표시 화면에 걸쳐 있는 HTML 페이지)의 점진적인 갱신을 비롯한 레이아웃 기능을 수행하는 표현자 클래스를 포함한다. 특정 표현자 타입의 일례로는 여러가지 방식(예를 들어, 굵은체(bold), 이탤릭체 등)으로 포맷된 텍스트를 측정 및 표시하는 텍스트 표현자, 지정된 이미지를 측정 및 표시하는 이미지 표현자, 및 다수의 자식 표현자에 공간을 분배하는 독 표현자(dock presenter)가 있다.

표현자 시스템(200) 및 표현자 클래스(214)를 생성한 후에, 뷰(202) 및 표현자 시스템(200)과 관련된 한 세트의 표현자 객체는 뷰에 대해 인스턴스화되며, 이는 루트 표현자 객체에서 시작한다. 유의할 점은 표현 엔진(212)을 생성하기 위해 표현 엔진 객체 클래스에 대한 생성자 메소드 호출이 뷰(202)의 루트 그래픽 요소를 식별한다는 것이다. 인스턴스화 이후에, 표현 엔진(212)은 뷰(202)의 루트 그래픽 요소와 관련된 표현자 객체 타입을 결정하기 위해 그래픽 요소(206)를 호출한다. 그래픽 요소의 표현자 타입을 결정한 후에, 표현 엔진(212)은 그래픽 요소(206)에 의해 식별된 표현자 객체 타입에 대응하는 표현자 객체 클래스(214) 중 하나의 메소드를 호출하여, 뷰(202)의 루트 표현자 객체를 인스턴스화한다.

표현자 클래스(214)와 배킹 스토어 사이의 경로로 나타낸 바와 같이, 루트 표현자를 포함한 표현자 객체는 특정 그래픽 요소의 프로퍼티를 결정하기 위해 배킹 스토어(208)의 그래픽 요소(206)에 액세스한다. 일례로서, 특정 그래픽 요소의 표현자 객체는 그 특정 그래픽 요소의 임의의 자식 그래픽 요소와 각각의 자식 그래픽 요소의 표현자 타입을 식별할 수 있다. 그 후에, 표현자 객체는 각각의 식별된 자식 그래픽 요소마다 표현자 시스템(200)의 자식 프록시 클래스(222)로부터 자식 프록시 객체를 인스턴스화하기 위해 그 자신의 메소드(예를 들어, GetChildProxyForElement(486))를 호출한다. 자식 프록시 객체는 부모 표현자 객체에 할당된 표시 공간 내에 내포된(nested) 표현자 객체(표현자 객체 클래스(214)로부터 인스턴스화됨)의 래퍼 객체(wrapper object)이다. 자식 프록시 클래스(222)는 캡슐화 및 보안 요건을 충족시킨다(예를 들어, 자식 표현자 객체는 부모 표현자 객체, 또는 애플리케이션(204)이 자식 표현자 내에 포함된 표현자의 내용으로 액세스 하는 것을 제한한다). 다른 대안에서, 자식 프록시 객체에 의해 제공되는 캡슐화 계층은 우회되고, 부모 표현자는 그의 자식 표현자에 직접 액세스한다.

본 발명의 일 실시예에서, 요소의 자식 프록시 객체를 생성하기 위해 표현자 객체 메소드는 자식 프록시 클래스(222)의 생성자 메소드를 호출하고 자식 그래픽 요소의 새로운 자식 프록시 객체 및 표현자 객체를 인스턴스화하기 위해 자식 그래 픽 요소의 식별자(identity)를 전달한다. 일단 인스턴스화되면, 새로운 자식 프록시 객체는 식별된 자식 그래픽 요소에 지정된 표현자 타입에 대응하는 표현자 생성자를 통해 자식 그래픽 요소의 표현자 객체를 생성한다. 자식 프록시 객체는 이어서 부모 표현자 객체로 그 자신의 참조를 반환한다. 부모 표현자 객체는 반환된 자식 프록시 객체 참조를 자식 프록시 객체에 대한 참조의 배열에 보관한다. 이와 같이, 표현자 객체의 자식 프록시 객체 배열 엔트리는 부모 표현자와 관련된 부모 그래픽 요소의 자식 그래픽 요소에 대응한다.

도 2에 도시된 그래픽 요소 정렬/표현 아키텍처의 또하나의 특징은 변동 통지(change notification)이다. 본 발명의 일 실시예에서, 한 세트의 통지 핸들러 클래스(224)가 표현자 클래스(214)로부터 인스턴스화된 표현자 객체에 제공된다. 통지 핸들러 클래스(224)는 통지 핸들러 기본 클래스(225)에 따라 정의된다. 통지 핸들러 기본 클래스(225)는 통지 핸들러 클래스(224)의 인터페이스를 정의하는 추상 클래스이다. 통지 핸들러 기본 클래스(225)는 2개의 가상 메소드(도 6을 참조할 것)의 인터페이스 정의를 제공하며, 이의 구현은 그의 대응하는 표현자 클래스(214)에 따라 통지 핸들러 클래스(224)에 제공되어 있다. 통지 핸들러 클래스(224)는 점진적인 레이아웃 갱신, 즉 한 세트의 대응하는 그래픽 요소에 대한 변동에 의해 영향을 받는 표현자 객체만을 재계산하는 일을 돕는다. 본 발명의 일 실시예에서, 그래픽 요소 및 뷰 조합에 대해 통지 핸들러가 지정된다. 하나의 그래픽 요소/뷰 조합에 대해 다수의 표현자가 생성되는 경우, 뷰 내의 요소에 대한 다수의 표현자를 갱신하기 위해, 하나의 통지 핸들러가 요소에 대한 변동을 추적하 기 위한 단일 소스로서 동작한다. 각각의 표현자 타입은 특정의 대응하는 통지 핸들러 타입을 지정한다. 통지 핸들러를 필요로 하는 요소의 표현자 객체가 인스턴스화될 때, 표현자 시스템은 지정된 타입의 대응하는 통지 핸들러를 생성하고 이 통지 핸들러를 표현자 객체에 링크시킨다.

통지 핸들러 클래스(224)의 인스턴스는 표현자 객체 중 어느 부분이 더티 상태(dirty)이고 따라서 갱신을 필요로 하는지를 결정한다. 처음에, 뷰(예를 들어, 애플리케이션(204)의 뷰(202)) 내의 표현자에 대해 생성된 통지 핸들러와 그래픽 요소 사이에 통지 관계가 확립된다. 통지 핸들러는 표현 시스템(200)의 표현 엔진(212)을 통해 배킹 스토어(208) 내의 그래픽 요소와 관련된 변동 통지를 수신한다. 통지 핸들러는 요소에 대한 변경에 의해 영향을 받은 표현자의 부분이 있는 경우 그 부분을 결정한다. 통지 핸들러는 영향받은 부분 정보를 표현자 시스템(200)으로 반환한다. 표현자는 표현 엔진(212)에 의해 "더티 상태"로 표시된다. 표현자 시스템(200)은 모든 표현자에 대한 "더티 상태" 표현자 정보를 뷰(예를 들어, 뷰(202))에 대해 유지되고 있는 데이터 구조에 누적한다. 나중에, 뷰의 레이아웃을 재계산하라는 요청에 응답하여, 표현자 시스템(200)의 표현 엔진(212)은 더티 상태 표현자에 대해서만 갱신 메소드/동작을 호출한다. 따라서, 통지 핸들러 클래스(224)는 레이아웃 갱신을 표현자 클래스(214)로부터 생성된 표현자 객체 중 영향받은 것으로 제한하는 것을 가능하게 해준다.

본 발명을 구현하는 레이아웃 관리 시스템 아키텍처는 레이아웃된 요소들이 그의 정의된 뷰에 따라 궁극적으로 표시되는 곳인 임의의 특정 출력 하드웨어 장치 에 독립적으로 동작한다. 도 2에 도시된 레이아웃/표현 관리 시스템 아키텍처는 그래픽 표시 출력에 관한 사전 처리 단계를 수행한다. 본 발명의 일 실시예에서, 레이아웃/표현 관리 시스템 아키텍처와 관련되어 있는 정렬된 출력은 장치 독립적이다. 그 후에, 렌더링 단계 동안, 표현자 객체는 재계산된 뷰를 컴퓨팅 시스템의 그래픽 출력 컴포넌트로 렌더링한다. 그렇지만, 본 발명의 다른 실시예에서, 레이아웃/표현 시스템의 출력은 표현자 객체(214)나 표현자 시스템(200) 중 어느 하나에 의해 호출측 애플리케이션(calling application)(204)으로 반환되며, 애플리케이션(204)은 렌더링 작업을 수행한다. 본 발명의 일 실시예에서, 렌더링 명령은 표현자 클래스(214)으로부터 파생된 표현자 객체, 뷰(202) 또는 애플리케이션(204)에 의해 발행된 것인지에 상관없이 사용자의 컴퓨터 상의 그래픽 서브시스템 및 그래픽 장치 드라이버(234)로 전달된다. 그래픽 서브시스템 및 그래픽 장치 드라이버(234)는 렌더링 명령어 및 데이터를 모니터(236)나 프린터(238) 등의 선택된 특정 출력 장치에 맞게 변환한다.

상기한 레이아웃/표현 관리 시스템 아키텍처에 대해 요약하면, 표현자 시스템(200)은 애플리케이션(204) 등의 애플리케이션에 장치 독립적인 레이아웃 처리 플랫폼을 제공한다. 레이아웃 처리는 표현자 시스템(200)에 의해 호스팅되는 한 세트의 표현자 클래스(214)로부터 인스턴스화된 표현자 객체에 의해 수행된다. 표현자 시스템(200)은 뷰(202)에 의해 소유된다. 표현자 객체는 그래픽 요소(206)의 특정 뷰 상태/렌더링에 대응한다. 뷰 상태(표현자 객체)와 요소 상태(그래픽 요소(206))를 분리시킴으로써 다수의 뷰 상태/표현자가 하나의 요소 상태에 대해 독립적으로 지정될 수 있게 된다. 레이아웃은 뷰(202) 등의 뷰들로 분리되며, 이 때 각 뷰는 애플리케이션(204)에 할당되는 출력 화면 상의 특정 사각형이나 그래픽 프린터 출력에서의 문서 페이지 등의 표시 영역에 대응한다. 데이터 상태와 뷰 상태를 분리시킴으로써 하나의 요소가 그 그래픽 요소의 다수의 뷰를 구동할 수 있게 되며, 따라서 하나의 그래픽 요소가 다양한 뷰/방식으로 표시될 수 있게 된다.

개시된 레이아웃 관리 시스템 아키텍처의 또하나의 특징은 그 확장성이 아주 높다는 것이다. 표현자 시스템(200)에 의해 제공되는 표현자 기본 클래스(216) 및 표현 엔진(212)의 표현자 호스트 API를 이용하여 한 세트의 표현자 클래스(214)를 용이하게 확장시킬 수 있다.

상기의 레이아웃 관리 시스템 아키텍처는 그래픽 출력을 그래픽 사용자 인터페이스 및 프린터로 렌더링하는 애플리케이션의 다양한 진보된 레이아웃 처리 기능을 지원한다. 하나의 요소(그래픽 요소)를 다수의 뷰 상태(표현자)로 분리시키는 기능은 프린터 출력이나 표시 화면 상의 문서의 프린터 출력 뷰를 렌더링할 때 애플리케이션에서 다수의 단(colume)(페이지 분할의 한 형태)으로의 요소 분할 및 페이지 분할에 도움이 된다. 이러한 애플리케이션으로는 웹 브라우저와 워드 프로세싱 프로그램이 있다.

다수의 표현자의 또하나의 이점은 애플리케이션이 그의 내용을 주어진 표시 공간 내에 맞추려는 시도를 여러번 수행할 수 있다는 것이다. 애플리케이션은 서로 다른 입력 파라미터를 사용하여 하나의 요소의 서로 다른 표현자 객체에 대한 다수의 시도를 인스턴스화할 수 있으며, 따라서 사용자가 그래픽 요소(들)의 표시 된 뷰 중 최상의 것을 선택할 수 있게 해준다.

전술한 레이아웃 관리 아키텍처로부터 얻게 되는 또다른 이점은 한 세트의 대응하는 요소의 한 세트의 표현자를 포함하는 뷰에 대해 점진적인 갱신을 수행할 수 있다는 것이다. 변경은 배킹 스토어(예를 들면, 도 3의 배킹 스토어(308)를 참조할 것)에서 요소별로 구현된다. 통지 핸들러 및 표현자 시스템(200)은 대응하는 뷰의 갱신을 배킹 스토어 내의 대응하는 요소에 대한 변동에 의해 영향을 받은 표현자로 제한하는 하부 구조(infrastructure)를 제공한다.

예시적인 레이아웃 관리 아키텍처의 또다른 이점은 이전에 생성된 표현자로 구현된 요소의 뷰 상태를 장식할 수 있다는 것이다. 이것은 부가의 표현자를 특정요소 타입에 대해 지정된 타입의 표현자에 체인화함으로써 달성된다. 체인화에 의해 개발자는 요소의 특정 표현자 타입에 의해 지정된 뷰 상태에 경계, 배경 등을 부가함으로써 사용자 인터페이스 및 문서 출력을 개선시킬 수 있다.

본 발명을 구현하는 레이아웃 관리 시스템의 일반적인 아키텍처를 서술하였으며, 이제는 도 3을 참조하여 특정 예시적인 뷰에 대한 뷰, 표현 엔진, 뷰 내의 표현자 객체, 그래픽 요소, 및 통지 핸들러 사이의 관계를 살펴볼 것이다.

개념상으로, 뷰는 지정된 표현자에 따라 배킹 스토어(208)에 표현된 한 세트의 그래픽 요소를 레이아웃하기 위한 특정 방식을 정의한다. 본 발명의 일 실시예에서, 뷰는 출력 필드(예를 들면, 표시 화면) 내의 사각형에 의해 정의된다. 사각형 및 그의 위치 이외에, 뷰는 또한 뷰에 포함된 그래픽 요소 및 관련 표현자도 지정한다. 게다가, 유의할 점은 본 발명의 일 실시예에서 각각의 뷰는 그 자신의 표 현자 시스템 인스턴스(예를 들면, 뷰(202a)의 표현자 시스템(200a) 및 뷰(202b)의 표현자 시스템(200b))와 관련되어 있다는 것이다.

계속하여 도 3을 참조하면, 배킹 스토어(208)는 뷰(202a, 202b)와 관련된 그래픽 요소(Ex)의 조직화된 컬렉션을 포함한다. 그래픽 요소(Ex)는 조직화된 사용자 내용(organized user content)의 엔티티이다. 요소의 일례로는 그래픽 사용자 인터페이스(GUI) 버튼이나 텍스트 패널, 텍스트 에디터 윈도우, 비트맵 등이 있다. 본 발명의 일 실시예에서, 배킹 스토어(208) 내의 그래픽 요소(Ex)는 트리 형태로 정렬되어 있다. 배킹 스토어(208) 내에 유지되는 한 세트의 그래픽 요소(206) 내의 각 요소(Ex)는 한 세트의 프로퍼티(property)/플레이스홀더(placeholder)(명시적인 것이거나 다른 명시적인 프로퍼티/플레이스홀더로부터 암시될 수 있음)와 관련되어 있다. 그래픽 요소에 대한 하나 이상의 이러한 프로퍼티/플레이스홀더는 컴퓨터 시스템의 다른 컴포넌트와 협력하여 그래픽 요소의 내용을 레이아웃 및 렌더링하는 데 사용되는 표현자 타입을 지정한다. 본 발명의 실시예들에서, 체인화된 표현자(chained presenter)는 명시적으로 정의되거나 다른 대안에서는 요소에 지정된 다른 프로퍼티로부터 암시된다(예를 들어, 2개의 픽셀의 "경계"(border) 프로퍼티는 경계 체인화된 표현자(border chained presenter)를 암시한다). 그래픽 요소에 대해 지정된 프로퍼티 타입은 특정 그래픽 요소에 의존하며, 컬러, 폰트 이름, 높이, 폭 등을 포함한다.

배킹 스토어(208)는 다수개 일 수 있는 뷰(예를 들어, 뷰(202a, 202b))와 관련되어 있다. 다수개 일 수 있는 뷰의 각각은 배킹 스토어(208) 내의 한 세트의 그래픽 요소에 대응하는 한 세트의 표현자 객체 인스턴스를 독점적으로 소유한다. 따라서, 그래픽 요소가 다수의 뷰에 존재하는 경우, 각각의 뷰 내의 요소에 대해 표현자 객체(예를 들어, 요소(E2)에 대해 표현자(P2)와 표현자(P2'))가 생성된다. 표현자와 관련되어 있는 그래픽 요소는 요소 소유자(element owner) 필드에 지정되어 있으며 표현자로부터 그의 대응하는 그래픽 요소로의 점선에 대응한다. 이것은 다수의 표현자가 하나의 그래픽 요소에 의해 제공되는 정보에 동작하는 것을 지원하는 도 2 및 도 3에 나타낸 표현 아키텍처의 일례에 불과하다.

다수의 뷰 (및 표현자)를 배킹 스토어(208) 내의 동일한 그래픽 요소 컬렉션에 연계시킬 수 있는 상기한 기능을 구현하는 표현 아키텍처의 결과로서, 그래픽 사용자 인터페이스는 그래픽 요소에 의해 제공되는 한 세트의 동일한 정보의 다수의 뷰를 표시할 수 있다. 예를 들어, MICROSOFT의 파워포인트 등의 애플리케이션에서, 동일한 슬라이드 그래픽 요소에 대해 슬라이드의 2개의 동시적인 뷰, 즉 메인 뷰와 미리보기(또는 썸네일) 뷰가 지원된다.

하나의 그래픽 요소에 대해 다수의 표현자 객체 인스턴스를 생성할 수 있는 기능은 또한 하나의 그래픽 요소(예를 들면, 문서 텍스트)를 다수의 페이지/단에 걸쳐 페이지 분할하는 것을 용이하게 해준다(즉, 하나의 그래픽 요소가 2개의 페이지에 걸쳐 분할되는 경우, 그 요소에 대해 2개의 표현자 객체가 각 페이지마다 하나씩 생성된다). 도 3을 참조하면, 부모 표현자 객체(예를 들면, P5)는 요소 내의 내용이 2개의 단에 걸쳐 표현될 수 있음을 나타내는 전달된 프로퍼티를 그래픽 요소(예를 들면, E5)로부터 수신한다. 문서 상의 2개의 분리된 별개의 단/페이지 사 각형에 대응하는 2개의 자식 표현자 객체(P8a, P8b)는 그래픽 요소(E8)에 의해 제공된 텍스트를 표시하기 위한 표현자(P5)의 아래에 인스턴스화된다.

하나의 그래픽 요소에 대해 다수의 표현자를 인스턴스화하는 또다른 사례는 장식(예를 들어, 경계, 배경, 프레임 등)이 그래픽 요소에 할당되는 경우에 있게 된다. 체인화된 표현자의 일례는 요소(E4) 내의 데이터 필드에 의해 제공되는 텍스트를 보유하도록 표현자(P4)에 의해 정의된 사각형 주변에 경계를 제공하는 요소(E4)의 체인화된 표현자(Q4)에 의해 제공된다. 표현자(Q4)와 표현자(P4) 모두는 그의 요소 소유자 필드 내에 그래픽 요소(E4)를 지정함으로써 그래픽 요소(E4)에 링크/관련되어 있다. 본 발명의 일 실시예에서, 부모 표현자는 그의 자식 중 하나에 대응하는 요소로부터, 체인화된 표현자가 필요함(예를 들어, 2개의 픽셀의 경계가 그 요소에 대해 지정되어 있음)을 검지한다. 체인화된 표현자(Q4)의 경우, 표현자(P1)가 자식 요소(E4)의 자식 (프록시) 표현자를 생성하기 위해 그 자신의 메소드를 호출할 때, 그 표현자(P1)는 E4에 대한 프로퍼티로부터, 체인화된 표현자(Q4)가 필요하다는 것을 인식한다. 먼저, 자식 프록시/표현자(Q4)가 생성되고 표현자(P1)의 자식 표현자로서 식별된다. Q4는 이어서 자식 프록시/표현자(P4)를 생성한다. P4는 따라서 표현자(Q4)의 자식 표현자이다. 체인 내의 그 다음 표현자(P4)를 식별하는 정보가 체인화된 표현자(Q4)의 자식 프록시 내에 저장된다.

동일한 그래픽 요소에 링크되어 배킹 스토어(208)내의 한 세트의 그래픽 요소에 대한 다수의 뷰 (및 표현자 시스템)를 생성하는 다수의 표현자를 포함하는 예시적인 특정 경우에 대해 기술하였으며, 이제부터는 도 3에 표시된 개체 사이의 관 계에 대해 기술한다. 전술한 바와 같이, 뷰(202a, 202b)는 각각 표현자 시스템(200a, 200b)을 소유한다. 생성된 표현자 시스템(200a)은 표현자 클래스가 기록되어 있는 API를 포함하는 기본 클래스 및 코드를 통해 뷰(202a)의 한 세트의 표현자(302)를 지원한다. 생성된 표현자 시스템(200b)은 뷰(202b)의 한 세트의 표현자(303)를 지원한다.

배킹 스토어(208)내의 그래픽 요소(Ex)와 표현자(Px) 사이의 선으로 나타낸 바와 같이, 표현자(Px)는 대응하는 그래픽 요소(Ex)와 관련되어 있다. 표현자(Px)는 대응하는 그래픽 요소(Ex)의 뷰 상태를 나타낸다. 배킹 스토어(208) 내의 그래픽 요소(Ex)는 일례로서 많은 가능한 방법 중 하나로 애플리케이션에 의해 구축된 트리 구조로 유지된다. 이러한 방법의 일례로는 그래픽 요소 등을 인스턴스화하기 위한 코드를 사용하여 파서를 통해 텍스트 마크업 파일을 실행하는 것이 있다. 한 세트의 표현자(302) 트리 구조는 그의 표현 엔진에 의해 제공되는 인터페이스에 대한 특정 메소드(예를 들면, DoLayout)의 호출에 응답하여 표현자 시스템(200a)에 의해 구축된다. 도 2를 참조하여 전술한 바와 같이, 표현자 객체 트리의 노드는 특정 뷰와 관련된 그래픽 요소 트리의 노드에 의해 결정된다. 뷰 내의 그래픽 요소는 뷰, 그의 자식, 손자 등에 대해 지정된 루트 그래픽 요소에 의해 결정된다.

뷰 1 내의 한 세트의 표현자(302)는 계층 구조로 정렬되어 있다. 루트 표현자(P1)는 2개의 자식 표현자(P2, P4)를 가지고 있다(Q4는 표현자(P4)에 대한 장식 표현자임). 표현자(P2)는 자식을 갖고 있지 않다. 그렇지만, 표현자(P4)는 2개의 자식 표현자(P5, P7)를 갖는다. 표현자(P5)는 이어서 하나의 그래픽 요소(E8)와 관련된 자식 표현자(P8a, P8b)를 갖는다. 2개의 표현자 객체 사이에서의 하나의 그래픽 표현자의 이러한 공유/분할은 일례로서 텍스트 그래픽 요소(E8)가 타입 TextPresenter의 표현자(P5)를 갖는 부모 텍스트 그래픽 요소(E5)를 2개의 단으로 분할할 때 일어난다. E5에 대한 프로퍼티가 E5의 내용(E8)이 2개의 단에 걸쳐 분할되도록 요청하는 것임을 표현자(P5)가 알게 될 때, 그 표현자(P5)는 단 분할 과정(column division process)을 개시한다. 표현자(P8a, P8b)는 그래픽 요소(E8)가 2개의 단으로 나뉘어 그래픽으로 존재하는 부분에 대응한다.

앞서 살펴본 바와 같이, 하나의 그래픽 요소가 다수의 관련된 표현자 객체를 가질 수 있다. 3가지 예시적인 경우가 확인되었다. 도 3에 다수의 뷰(202a, 202b) 및 대응하는 표현자 시스템(200a, 200b)으로 도시한 제1 시나리오에서, 하나의 그래픽 요소(예를 들어, E2)는 뷰(202a, 202b)와 각각 관련된 대응하는 표현자(P2, P2')를 갖는다. 이러한 뷰는 일례로서 사진 이미지 처리 애플리케이션에 의해 생성된 사용자 인터페이스의 서로 다른 영역에 표시되는 사진 이미지(E2)의 썸네일 뷰와 실물 크기 뷰에 대응한다. 이 경우에, 표현자(P2, P2')는 요소를 포함하는 각각의 뷰(202a, 202b) 내의 요소(E2)에 대해 생성된다. 하나의 요소(예를 들면, 텍스트 요소(E8))에 대해 다수의 표현자를 포함하는 제2 시나리오에서, 표현자 요소(P8a, P8b)는 하나의 표현자 요소(P5)에 의해 정의된 사각형 내의 2개의 단에 대응한다. 다른 대안에서, 뷰 내의 다수의 표현자가 동일한 그래픽 요소를 참조하는 이러한 경우는, 예를 들어 부모가 여러 차례 뷰 레이아웃을 시도하고 그 시도를 저장하는 때에 일어난다. 제3 시나리오에서, 다른 표현자(예를 들어, P4)(그래픽 요소(예를 들어, E4)의 데이터 상태와는 반대임)에 종속되는 표현자(예를 들어, Q4)는 나머지 표현자에 체인화되어 있으며, 그에 따라 원래의 표현자에 의해 제공되는 표시 특징을 다채롭게 한다. 표현자 체인화의 일례로는 메인 표현자에 경계 장식을 제공하는 경계 표현자가 있다.

도 2를 참조하여 앞서 살펴본 바와 같이, 자식 프록시 클래스(222)로부터 인스턴스화된 자식 프록시 객체는 부모 표현자 객체의 각각의 자식 표현자 객체에 대한 래퍼이다. 뷰(202a)의 표현자 트리 구조의 도식적 표시에서, 자식 프록시 객체는 부모 표현자를 그의 자식 표현자 객체와 연결하는 선에서 화살표 머리로 표현되어 있다. 자식 프록시 객체는 부모 표현자 객체가 그의 자식 표현자 객체로 액세스 하는 것을 제한한다.

통지 핸들러(Nx)는 대응하는 표현자(Px)에 그의 그래픽 요소(Ex)에 대한 데이터 상태 변동을 통지하는 일을 맡고 있다. 통지 핸들러(Nx)는 표현/레이아웃 관리 시스템의 동작에 필수적인 것은 아니다. 오히려, 통지 핸들러는 뷰 내의 요소에 변동이 있을 때 일부 표현자에 대한 점진적인 갱신이 용이하도록 해준다.

도 4a 및 도 4b를 참조하면, 표현자 기본 클래스는 한 세트의 메소드, 프로퍼티 및 필드를 포함한다. 본 발명의 일 실시예에서, 참조된 특정 표현자 객체에 관한 프로퍼티는 그 객체에 대해 get/set 동작을 호출함으로써 액세스된다. Background 프로퍼티(400)는 표현자 배경에 대한 페인트(paint) 값을 지정한다. Background Opacity 프로퍼티(402)는 배경의 불투명도(opacity)를 지정하는 값을 저장한다. Border 프로퍼티(404)는 표현자의 레이아웃 공간의 가장자리 주변에 드 로잉되는 경계의 두께를 지정하는 값을 저장한다. Border 프로퍼티(404)는 예를 들면 표현자에 할당된 사각형의 윗변, 아랫변, 좌변 및 우변의 경계 폭을 나타내는 4개의 값을 저장한다. Border Color 프로퍼티(406)는 표현자 주변의 경계의 색상을 지정하는 값을 가리킨다. Border Style 프로퍼티(408)는 한 세트의 경계 표시 스타일(border display style) 중 하나를 가리키는 값을 저장한다. 경계 스타일의 일례로는 solid(실선), groove(홈이 파인 실선), ridge(솟아 오른 실선), inset(배경 속으로 패인 모양) 및 outset(배경 위로 튀어 나온 모양)가 있다.

Bounding Box 프로퍼티(410)는 표현자 그래픽(또는 자식)이 드로잉되어 있는 영역(예를 들면, 사각형)을 지정한다. Bounding Box 프로퍼티(410)의 디폴트 크기는 Layout Size 필드(460)에 의해 지정된 크기와 동일하다. 그렇지만, 외곽 상자(bounding box) 크기는 레이아웃 크기(layout size)를 초과할 수 있으며, 그에 따라 표현자는 레이아웃 크기를 벗어나 드로잉하게 될 수 있다.

한편, Clip 프로퍼티(414)가 참(true)으로 설정되면, 표현자 (및 그의 자식 표현자)는 Layout Size 필드(460)에 의해 지정된 사각형을 벗어나 드로잉될 수 없다. Clip 프로퍼티(414)가 참으로 설정되면, Bounding Box 프로퍼티(410)는 레이아웃 크기보다 클 수 없다. 이것은 드로잉된 표현자가 그의 할당된 레이아웃 공간을 벗어나 그래픽을 렌더링하지 않도록 해준다.

Children 프로퍼티(412)는 부모 표현자 내에 내포된 자식 표현자에 대한 참조(예를 들어, 핸들(handle), 포인터(pointer), 직접/간접(direct/indirect) 등)와 부모 표현자의 레이아웃 공간 내에서의 그의 변환된 장소를 저장하는 배열(array) 또는 다른 대안에서는 임의의 다른 적당한 다중 요소 데이터 구조(multi-element data structure)이다. Children 프로퍼티(412)는 표현자에 대한 OnUpdate 메소드 호출(이하에서 기술함)과 관련하여 처음으로 사용될 때 채워진다(populate). "처음으로 사용될 때"란 부모 표현자가 순차적으로 자식 컬렉션을 요청하고 자식 컬렉션이 배킹 스토어(예를 들어, 배킹 스토어(208)) 내의 그래픽 요소의 트리로부터 부모 표현자에 대응하는 그래픽 요소의 자식 그래픽 요소에 대응하는 표현자로 채워질 때를 말한다. Children 프로퍼티(412)는 뷰 내의 표현자에 관한 내포 관계(nested relationship)를 반영하는 계층 구조를 확립/유지하는 것을 용이하게 해준다. 본 발명의 일 실시예에서, 배열 엔트리는 자식 프록시 객체를 참조한다. 자식 프록시 객체는 부모 표현자 객체에 할당된 표시 공간 내에 내포되어 있는 자식 표현자 객체에 대한 래퍼 객체이다. 자식 프록시 객체 래퍼는 캡슐화 및 보안 요건을 만족시킨다(예를 들어, 자식 표현자는 부모 표현자가 그의 내용을 액세스하는 것을 제한한다).

앞서 설명한 바와 같이, Clip 프로퍼티(414)는 표현자의 내용이 클리핑에 의해 Layout Size 필드(460)에 의해 지정된 표현자의 레이아웃 크기로 한정되는지를 제어한다.

한 세트의 프로퍼티는 표현자의 공간 내에서 내용에 할당된 공간을 지정한다. Border 프로퍼티(404)에 추가하여, Padding 프로퍼티(416)는 내용에 의해 채워지지 않는 채로 있는 경계 내의 공간의 양을 지정한다. Content Height 프로퍼티(418)는 표현자 내에서의 내용의 높이, 즉 Border 프로퍼티(404) 및 Padding 프 로퍼티(416)에서 지정된 값을 고려한 후에 남게 되는 표현자의 일부분의 높이를 나타내는 값을 지정한다. Content Width 프로퍼티(420)는 Border 프로퍼티(404) 및 Padding 프로퍼티(416) 치수를 고려한 후 표현자 내의 내용에 할당된 폭을 나타내는 값을 지정한다. Content Height 프로퍼티(418)와 Content Width 프로퍼티(420)는 결합하여 표현자에서 내용이 차지할 수 있는 표현자의 영역을 지정한다.

Height 프로퍼티(422)와 Width 프로퍼티(424)는 표현자의 실제 높이와 폭을 지정하며, 이들 2개의 값은 내용, 패딩 및 경계 치수를 포함한다. Default Height 프로퍼티(426)와 Default Width 프로퍼티(428)는 특정의 표현자 객체에 대해 Height 프로퍼티(422)와 Width 프로퍼티(424)가 제공되지 않을 때 표현자에 할당될 수 있는 디폴트 값을 지정한다. Maximum Width 프로퍼티(430)와 Minimum Width 프로퍼티(432)는 Width 프로퍼티(424)에 할당되는 값의 한계를 지정한다.

표현자에 대한 또하나의 치수 프로퍼티로는 Margin 프로퍼티(434)가 있다. Margin 프로퍼티(434)는 표현자의 경계 밖의 완충 공간(buffer space)을 지정한다. Margin 프로퍼티(434)는 자식 표현자에 의해 지정되며 내포된 표현자의 계층 구조를 포함한 레이아웃을 정렬할 때 그의 부모 표현자에 의해 액세스된다.

Visibility 프로퍼티(436)는 표현자의 가시성 상태(visibility state)를 지정한다. Visibility 프로퍼티(436)는 표현자 및 그의 자식에 대응하는 그래픽 이미지가 어떻게 렌더링되는지(또는 렌더링되는지 여부)를 결정하기 위해 참조된다. 본 발명의 일 실시예에서, 가능한 가시성 상태로는 visible(볼 수 있음), collapsed(중복됨), 및 hidden(은폐됨)이 있다.

다수의 표현자 프로퍼티가 레이아웃/표현 관리 시스템에서 표현자를 다른 엔티티에 링크하는 데 이용된다. Presenter 프로퍼티(438)는 그래픽 요소를 레이아웃 및 렌더링하는 데 사용되는 표현자의 타입을 지정한다. 표현자 타입은 초기에 그래픽 요소에 대해 설정되고, 표현자 시스템(200)은 그래픽 요소로부터 Presenter 프로퍼티(438)를 판독하여 Presenter 프로퍼티(438)에 의해 식별되는 표현자 타입에 대응하는 표현자 객체를 인스턴스화한다. Presenter 프로퍼티(438)는 인스턴스 생성기(instantiator)에 전달되고, 인스턴스 생성기는 이어서 식별된 표현자 타입의 인스턴스를 생성한다. IsMainPresenter 프로퍼티(440)는 표현자가 그래픽 요소 객체와 관련된 한 세트의 체인화된 표현자 내의 1차 표현자(primary presenter)(예를 들면, 최근의 표현자)인지 아니면 유일한 표현자인지를 지정한다. 도 3을 참조하면, 표현자(P4)는 B4와 P4를 포함하는 체인의 메인 표현자이다. 본 발명의 일 실시예에서, IsMainPresenter 프로퍼티(440)는 부울 타입 프로퍼티이다.

Element Owner 프로퍼티(442)는 그에 대한 표현자가 인스턴스화된 그래픽 요소를 식별한다. 다시 도 3을 참조하면, 표현자(Px)를 대응하는 그래픽 요소(Ex)로 연결하는 가상선(ghost line)은 Element Owner 프로퍼티(442)의 내용에 의해 지정되는 관련성을 나타낸다. Layout Context 프로퍼티(444)는 레이아웃 처리 동안 표현자간 메시징(inter-presenter messaging)이 용이하도록 해주는 글로벌 콘텍스트(global context)를 지정한다. Layout Context 프로퍼티(444)에 저장된 값은 표현자가 표현자 시스템(200)에 독립적으로 메시지를 전달할 수 있게 해준다. Notification Handler 프로퍼티(446)는 표현자의 통지 핸들러에 대한 참조를 지정 한다. Notification Handler Type 프로퍼티(448)는 Notification Handler 프로퍼티(446)에 의해 참조되는 통지 핸들러의 타입을 지정한다.

Dirtiness 프로퍼티(450)는 특정 표현자가 변동되었는지와 그에 따라 갱신 처리를 필요로 하는지 여부를 지정한다. 표현자 시스템(200)과 레이아웃 관리 아키텍처의 관련 컴포넌트는 레이아웃의 점진적인 처리를 지원한다. 각각의 표현자에 의해 유지되는 Dirtiness 프로퍼티(450)는 표현자가 갱신될 필요가 있는지 여부를 표현자별로 나타낸다.

계속하여 도 4a를 참조하면, 표현자 기본 클래스의 한 세트의 예시적인 필드가 요약되어 있다. 본 발명의 일 실시예에서, 필드는 CLR(Common Language Runtime, 공통 언어 런타임) 필드(잘 알고 있는 C++ 클래스에서의 멤버 변수와 유사함)이다. 본 발명의 일 실시예에서, 전술한 프로퍼티는 필드와 유사하다. 그렇지만, 그래픽 요소(예를 들면, 그래픽 요소(206))에 관한 프로퍼티는 배킹 스토어(예를 들면, 배킹 스토어(208))에 의해 소유되고 관리된다. 프로퍼티가 변동하면, 배킹 스토어는 표현 엔진에 그 변동을 통지한다. 표현 엔진(예를 들어, 표현자 시스템(200)의 표현 엔진(212))은 이어서 적절한 통지 핸들러(224)에 통지한다. 따라서, 프로퍼티의 경우, 변동 통지는 전술한 통지 핸들러 중 하나를 통해 수신된다. 한편, 필드는 배킹 스토어(208)에 의해 관리되지 않는다(그 대신에 예를 들면 CLR에 의해 관리된다). 따라서, 필드가 변할 때 표현 엔진에 변동 통지가 보내지지 않는다.

Layout Size 필드(460)는 표현자의 할당된 레이아웃 공간의 치수를 유지한 다. LayoutSize 필드(460)는 페이지/사용자 인터페이스 레이아웃에서 이웃하는 표현자를 정렬하는 데 이용된다. Affects Layout 필드(462)는 변동될 때 표현자의 레이아웃에 영향을 주는 표현자의 프로퍼티(예를 들어, 경계, 패딩 등)의 컬렉션이다. Affects Parent Layout 필드(464)는 요소(예를 들면, 요소 A)에 대해 변동될 때 지정된 표현자를 갖는 요소(요소 A)의 제1 부모의 레이아웃을 더티 상태로 만드는(dirty)(즉, 영향을 줄 수 있는) 표현자의 프로퍼티(예를 들면, 여백, 가시성 등)의 컬렉션이다. Affects Render 필드(466)는 표현자의 무효화 및 리렌더링을 트리거하는 통지 메카니즘이다.

이제부터 도 4b에 열거한 표현자 기본 클래스(206)의 메소드를 참조하면, OnUpdate 메소드(470)는 요소의 표현자에 대해 측정 및 배치 작업을 수행한다. 표현자 저작자(presenter author)는 요소의 대응하는 뷰에 대한 커스터마이즈된 레이아웃 크기 조정/배치 거동을 생성/제공하기 위해 기본 클래스 버전의 OnUpdate 메소드(470)를 오버라이트(overwrite)한다.

OnUpdate 메소드(470)의 제1 디폴트 동작은 표현자의 크기 조정이다. OnUpdate 메소드(470)는 전달된 BoxSizeInfo 파라미터로 표현자 크기 치수를 수신한다. OnUpdate 메소드(470)는 지정된 BoxSizeInfo 및 Default Width 프로퍼티(428) 값과 Default Height 프로퍼티(426)의 값에 따라 Layout Size 필드(460)에 지정된 치수를 설정한다. 표현자에 대한 크기 조정/배치 정보의 부가적인 소스는 개시된 표현자 기반의 레이아웃/표현 처리 아키텍처에 포함되며, 이러한 소스는 본 발명의 대체 실시예에서 이용된다.

OnUpdate 메소드(470)의 제2 디폴트 작업은 표현자의 로컬 크기 공간(local dimension space) 내에 자식 표현자를 배치하는 것이다. 기본 클래스 버전의 OnUpdate 메소드(470)는 Children 프로퍼티(412)에서 식별된 자식 표현자의 OnUpdate 메소드(470)를 반복적으로 호출하여 그의 치수 및 자식을 찾아낸다. 자식 표현자를 찾아내어 측정하였으면, 개개의 자식에 대해 변환 메소드(transform method)(이하에서 기술함)를 호출함으로써 부모 표현자 내에 자식이 배치된다. 자식 표현자의 OnUpdate 메소드(470)를 반복적으로 호출하는 것은 표현자에 대해 지정된 자식이 더 이상 없을 때 종료한다. Layout Size 필드(460)에 그의 크기를 등록하고 자식 표현자를 반복적으로 호출/배치하는 것 이외에, OnUpdate 메소드(470)는 OnUpdate 메소드(470)의 호출을 고려하여 리렌더링이 요망되는지 여부를 나타내는 값을 호출자에 반환한다.

Register Atom 메소드(471)는 Layout Context 프로퍼티(444)에 대한 표현자의 문자열 이름은 물론 표현자의 확장자별로 유지되는 것을 포함한 표현자의 임의의 다른 적절한 리스트를 등록한다. Register Atom 메소드(471)는 예를 들면 비표준 방식으로(예를 들면, 표현자 애플리케이션 프로그램 인터페이스에 의해 현재 지원되지 않는 방식으로) 다른 표현자 객체와 통신하기 위해 호출된다. 표현자는 아톰(atom)을 등록한 다음에, 그 아톰을 사용하여 전달하고자 하는 자로 객체를 설정한다. 예를 들어, 자식 표현자는 텍스트 후손(text descent)을 부모 표현자에게 전달하기를 원한다. 자식 표현자는 "후손(Descent)"이라는 라벨/태그가 붙은 아톰을 등록하고 그 아톰에 대한 식별 번호를 수신한다. 자식은 후손을 계산하고 그 값을 상기 식별 번호를 사용하는 아톰에 설정한다. 부모 표현자는 그 다음에 ("후손"을 등록함으로써도 수신되는) 식별 번호를 사용하여 저장된 정보를 검색한다.

OnUpdateBoundingBox 메소드(472)는 표현자의 갱신된 Bounding Box 프로퍼티(410)를 생성한다. OnUpdate 메소드(470)가 리렌더링이 필요함을 나타내는 값(예를 들어, "참")을 반환하면 OnUpdateBoundingBox 메소드(472)가 호출된다. 표현자 기본 클래스에서 제공되는 OnUpdateBoundingBox 메소드(472)의 디폴트 구현은 표현자의 Children 프로퍼티(412)에서 식별된 자식 표현자들을 스캔하고 변환된 자식의 Bounding Box 프로퍼티를 Layout Size 필드(460) 내에 저장된 표현자의 치수와 결합시킨다(즉, 그에 대한 사각형의 수학적 합집합을 수행한다). OnUpdateBoundingBox 메소드(472)의 기본 클래스 구현은 또한 Clip 프로퍼티(414)에도 액세스하고, 그 프로퍼티가 "참"인 경우 자식의 외곽 상자를 무시한다. 그 대신에, 자식 표현자는 그의 부모 표현자의 Layout Size 필드(460) 치수로 클리핑된다. 그의 Layout Size 필드(460) 치수 밖에 드로잉하는 표현자는 이 메소드를 오버라이트한다. 이러한 커스터마이즈된 표현자 클래스는 기본 표현자 클래스를 호출하고 그의 오버라이트 코드에 부가의 "잉크 영역"(ink area)을 추가한다. 본 발명의 일 실시예에서, 표현자는 "잉크 영역"이 실제로 필요한 것보다 더 크다고 추정할 수 있다. Bounding Box 프로퍼티(410) 영역이 그 표현자를 드로잉하는 데 필요한 영역보다 더 작은 경우, 드로잉은 표현자에 대해 지정된 Bounding Box 프로퍼티(410) 치수에 기초하여 클리핑된다.

OnRender 메소드(474)는 리렌더링을 요청/요구하는 표현자에 대해 호출된다. OnRender 메소드(474)는 표현자의 주요 호출(primary call)로서, 표현자와 그의 자식 표현자 중 임의의 것을 리렌더링하기 위한 것이다. OnRender 메소드(474)는 바람직하게는 OnUpdate 메소드(470)가 레이아웃(예를 들어, 화면) 내의 모든 "더티 상태" 표현자에 대해 호출된 후에 호출된다. 본 발명의 일 실시예에서, OnRender 메소드(474)는 표현자 객체의 OnUpdate 메소드(470) 호출이 그 표현자가 리렌더링을 요청함을 나타내는 표시를 반환했는지에 기초하여 표현자 객체에서 호출된다. 본 발명의 일 실시예에서, 기본 클래스의 OnRender 메소드(474)는 표현자에 대해 장치 독립적인 표현/레이아웃 정렬 동작을 수행한다. 그래픽 서브시스템 및 그래픽 장치 드라이버(234)를 포함한 다른 컴포넌트는 표현자의 뷰를 장치 고유 포맷으로 렌더링한다. OnRender 메소드(474)의 커스터마이즈된 파생은 그래픽 문서/사용자 인터페이스 출력을 렌더링하기 위한 컴퓨터 시스템의 그래픽 생성 컴포넌트의 호출을 포함한다.

본 발명의 일 실시예에서, 기본 클래스 버전의 OnRender 메소드(474)는 3개의 레이아웃 처리 단계에서 임의의 자식을 포함한 표현자의 내용을 렌더링한다. OnRenderBeforeChildren 단계 동안, 표현자 객체는 그의 자식 표현자를 처리하기 이전에 처리를 위해 지정된 동작을 호출한다. 본 발명의 일 실시예에서, OnRender 메소드(474)의 기본 클래스 구현은 커스터마이즈(customization)를 위한 후크(hook)를 제공하며 OnRenderBeforeChildren 단계 동안 어떤 사전 처리 동작도 지정하지 않는다. 그렇지만, 이러한 디폴트 거동에 대한 예시적인 커스터마이즈된 대체로는 표현자의 표시 영역에 대한 커스텀 배경을 설정/드로잉하는 것이 있다.

기본 클래스 버전의 OnRender 메소드(474)는 자식 렌더링 단계 동안 Children 프로퍼티(412)에서 식별된 표현자의 자식 표현자들에 액세스한다. OnRender 메소드(474)는 이어서 (OnUpdate 메소드(470)가 수행되었을 때 자식에 의해 요청된 범위까지) 자식 표현자 각각에서 호출된다. 따라서, OnRender 메소드(474)의 최상위 레벨 호출은 자식 표현자로, 또 그의 자식으로, 트리의 하부에 도달할 때까지(즉, 표현자가 자식을 갖지 않을 때까지) 단계적으로 내려간다. 최상위 레벨 호출이 완료되면, 리렌더링을 요청한 트리 내의 모든 자식 표현자가 리렌더링된다.

OnRenderAfterChildren 단계 동안, 표현자 객체는 Children 프로퍼티(412)에서 식별된 자식 표현자의 OnRender 메소드(474)를 호출한 후에 실행되어야 할 동작을 호출한다. 기본 클래스 버전의 OnRender 메소드(474)는 커스터마이즈를 위한 후크를 제공하며 OnRenderAfterChildren 단계 동안 어떤 사후 처리 동작도 지정하지 않는다. 그렇지만, 커스터마이즈 일례로는 주석(annotation), 장식(adornment) 등이 있다.

표현자가 그의 자식을 제외한 어떤 것도 리렌더링하지 않는 경우, 기본 클래스 버전의 OnRender 메소드(474)를 오버라이트할 필요가 없다. 그렇지만, 표현자 자체가 어떤 것이라도 드로잉해야 하는 경우, OnRender 메소드(474)의 기본 클래스는 그 표현자에 할당된 공간 내에 그래픽 데이터를 렌더링하기 위해 오버라이트된다. 대체 코드는 일례로서 애플리케이션(230) 및/또는 그래픽 서브시스템과 그래픽 장치 드라이브의 호출을 포함한다. 체인화된 표현자는 특정의 뷰에 대한 표현자의 트리에 있다. 체인화된 표현자가 리렌더링을 필요로 하는 경우, 그의 OnRender 메소드는 메인 표현자의 OnRender와 유사한 방식으로 표현자 시스템에 의해 호출될 것이다.

본 출원과 관련하여, "히트-테스트"(hit-test)란 어느 표현자가 그래픽 사용자 인터페이스 격자 공간(grid space)의 특정 격자점(grid point)에 해당되는지를 식별하기 위한 프로세스를 말한다. 예를 들어, 히트-테스트는 사용자가 마우스 버튼 중 하나를 선택할 때 마우스 포인터가 어디에 위치하는지(예를 들어, 마우스 포인터가 어느 표현자 상에 위치하는지)를 알아내는 데 사용된다. OnHitTestDetail 메소드(476)는 표현자의 HitTestDetail 구조에 저장된 데이터를 반환한다. 커스터마이즈된 표현자 클래스는 표현자가 히트된 요소 및 표현자 이외의 데이터를 반환할 수 있도록 HitTestDetail 구조를 채우기 위해 OnHitTestDetail 메소드(476)의 기본 클래스 구현을 오버라이트하며, 그에 따라 예를 들면 실제로 히트된 표현자의 일부 등의 표현자에 관한 보다 상세한 정보(예를 들어, 텍스트의 문자 위치)를 제공한다.

OnCreateViewResult 메소드(478)는 뷰 결과 객체(view result object)에 있는 표현자의 계산된 상태를 기술하는 파라미터를 노출시킨다. 사용자는 지정된 뷰와 관련하여 임의의 요소에 대한 뷰 결과 객체를 요청한다. 기본 클래스 버전의 OnCreateViewResult 메소드(478)는 뷰 결과 객체를 통해 표현자의 높이, 폭, 및 좌상 코너 위치를 제공한다. 표현자 내에 몇행의 텍스트가 포함되어 있는지 등의 표현자의 상태에 관한 부가의/대체 정보가 요망되는 경우, 뷰 결과 객체를 통해 원하는 정보를 제공하기 위해 기본 클래스 버전의 OnCreateViewResult 메소드(478)가 재정의된다.

HitTest 메소드(480)는, 서브트리가 지정된 표현자에서 루트될(rooted) 때 히트 테스트를 개시한다. 히트 테스트가 수행되어야 할 (표현자의 로컬 좌표에서) 점의 좌표는 HitTest 메소드(480)에 전달된다. HitTest 메소드(480)는 지정된 점 및 표현자에 대한 히트 테스트의 결과를 포함하는 히트 테스트 데이터를 반환한다. 결과는 그 점에 의해 히트된 모든 비쥬얼(visual)을 포함한다. 비쥬얼은 기본 객체(base object)(예를 들면, 선)로서 표현자는 그로부터 표시 이미지를 파생시킨다. 비쥬얼은 그래픽 표시 출력에 이미지를 실제로 드로잉할 수 있는 기능을 갖는 그래픽 객체이다. 표현자의 OnRender 호출에서, 예를 들어 텍스트, 이미지, 비디오 등을 렌더링하기 위해 몇가지 호출이 비쥬얼의 API로 발행된다.

OnGetBypassList 메소드(482)는 식별된 표현자에 대해 이전에 계산된 자식 표현자의 리스트를 제공한다. 자식 표현자의 리스트는 레이아웃 계산 동안 자식 표현자를 우회하는 일(예를 들어, 새로운 레이아웃 자식을 이전에 계산된 레이아웃 자식 표현자를 비교하여 그 리스트에 있는 것과 일치하는 것이 있는 경우 이전에 계산된 것을 재사용하는 것)을 용이하게 해준다. 표현자가 Children 프로퍼티(412) 컬렉션을 참조함으로써 그의 자식을 발견하면, 표현자는 이 메소드를 재정의할 필요가 없다. 그렇지만, 표현자가 GetChildProxyForElement 메소드(486)(이하에서 설명함)를 사용하는 경우, OnGetBypassList 메소드(482)는 일반적으로 재정의된다.

본 발명을 구현하는 레이아웃 시스템의 애플리케이션에서, GetChildProxyForElement 메소드(486)가 호출되는 경우, OnGetBypassList 메소드(482)는 OnUpdate 메소드(470)보다 앞서 호출되고, 표현자 객체는 배열 리스트를 생성하여 이전의 레이아웃 계산으로부터 캐싱했던 자식 프록시 객체(도 5를 참조하여 이하에서 설명할 것임)로 채워 넣는다. 표현자 객체가 재계산된 자식 프록시 객체를 저장하기 위한 캐시를 갖지 않는 경우, 표현자 객체의 모든 자식 표현자는 표현자에 대해 OnUpdate 메소드(470)를 호출할 때마다 재계산된다.

CalculateBounds 메소드(484)는 식별된 비쥬얼에서 루트되는 서브 그래프의 한계(bound)를 계산하여 반환한다.

자식 프록시 객체는 전술한 바와 같이 특정 그래픽 요소의 자식 표현자와 부모 표현자 사이의 중개자로서 기능하는 래퍼 객체(wrapper object)이다. 특정 표현자 객체의 자식 표현자에 대한 자식 프록시 객체는 표현자 객체의 Children 프로퍼티(412) 내의 컬렉션으로서 참조된다. GetChildProxyForElement 메소드(486)는 부모 표현자 객체의 메소드로서, 지정된 요소에 대한 자식 프록시 객체와 표현자 객체를 생성한다. 지정된 요소가 표현자를 갖지 않는 경우, 이 메소드는 "널"(null)을 반환한다.

OnBeforeBypass 메소드(488)는 표현자 시스템(200)이 특정 표현자를 "우회"하기를(즉, 그 표현자의 OnUpdate 메소드(470)의 호출을 생략하기를) 원할 때 호출된다. 이러한 우회는 예를 들면 표현자가 더티 상태가 아니고 OnUpdate 메소드(470) 호출 입력 표현자 치수 파라미터(BoxSizeInfo)가 표현자에 대한 가장 최근의 OnUpdate 메소드(470) 호출로부터 변경되지 않았을 때 일어난다. OnBeforeBypass 메소드(488)는 레이아웃에 대한 갱신이 수행될 때 (예를 들면, 레이아웃의 단지 작은 일부만이 변동에 의해 영향을 받게 될 때) (GetChildProxyForElement 메소드(486)를 사용하는) 자식 프록시 객체들로 된 그 자신의 커스텀 컬렉션을 갖는 표현자가 그의 자식들의 자식 프록시 객체를 재사용할 수 있게 해주는 성능 향상 메카니즘이다.

OnDisconnectChildren 메소드(490)는 지정된 표현자의 Children 프로퍼티(412)에서 참조된 한 세트의 자식 표현자로부터 모든 자식 표현자 객체를 제거한다. 디폴트 Children 프로퍼티(412)가 표현자 기본 클래스(216)로부터 파생된 표현자 클래스에 대해 재정의되는 경우, OnDisconnectChildren 메소드(490)는 또한 자식 표현자를 적절히 처리하도록 재정의된다.

Min/Max 패스(pass)는 내용에 맞춰 자식의 크기를 조정할 때 분할 표현자(partitioning presenter)(예를 들어, DockPresenter)에 의해 사용되는 특수한 크기 조정 패스(sizing pass)이다. 자식의 최대 및 최소 폭을 알게 되면 부모는 특정 폭 치수를 공유하는 다수의 자식들 간에 공간을 지능적으로 분배할 수 있게 된다. MinMaxPass 함수에 의해 제공된 min/max 정보가 없는 경우, 분할 표현자는 내용에 맞춰 지능적으로 크기를 조정하기 위해 다수의 패스를 필요로 하게 된다. OnMinWidth 메소드(492)는 Min/Max 패스 이후에 호출된다. OnMinWidth 메소드(492)는 MaxWidth 계산의 부산물인 MinWidth 값을 수집한다. 기본 클래스 버전의 OnMinWidth 메소드(492)는 ProposedSize=(0, 무한대)와 양쪽 방향 "NotFixed"를 사용하여 계산 패스(calculation pass)를 호출하는 "무시(I don't care)" 메시지를 발행한다.

Presenter 메소드(494)는 표현자 인스턴스의 생성자 메소드이다. Presenter 메소드(494)는 파라미터를 갖지 않는다. Presenter 메소드(494)는 표현자가 표현자 시스템(200)에 의해 인스턴스화될 때 호출된다. Presenter 메소드(494)는 표현자의 다른 메소드(예를 들어, OnUpdate)를 호출하는 것이 가능하도록 표현자 인스턴스를 셋업한다.

QueryLayoutTask 메소드(496)는 표현자 객체와 관련하여 수행될 지정된 레이아웃 작업을 표현자 시스템(200)에 의해 실행될 레이아웃 작업의 큐에 추가한다. 지정된 레이아웃 작업이 큐의 선두(front)에 도달할 때, 표현자 시스템(200)은 표현자에 대한 통지 핸들러의 OnLayoutTask 메소드(604)(이하에서 기술함)를 호출한다.

OnQueryValue 메소드(498)는 표현자의 지정된 계산값에 대응하는 값을 반환한다.

표현자 기본 클래스(216)에 대해 지금까지 기술하였으며, 도 5에 자식 프록시 클래스(222)의 예시적인 실시예의 프로퍼티 및 메소드의 요약이 제공되어 있다. 앞서 설명한 바와 같이, 본 발명의 일 실시예에서, 자식 프록시 객체는 부모 표현자 객체의 자식인 표현자 객체에 대한 래퍼이며, 부모가 자식 표현자 객체의 자원으로 액세스하는 것을 제한한다. 부모 표현자 객체와 자식 표현자 객체 사이의 모든 통신(요청/응답)은 자식 표현자의 자식 프록시를 통해 라우팅된다. 자식 프록 시 객체는 자식 표현자에 대한 참조를 보유하고 있으며 부모 표현자에 의한 호출/요청을 자식 표현자로 라우팅한다.

표현자 시스템(200)의 일 실시예에서, 자식 프록시 클래스(222)는 자식 프록시의 참조된 표현자와 관련되어 있는 그래픽 요소(206) 내의 요소를 지정하는 Element Owner 프로퍼티(500)를 포함한다.

Transform 프로퍼티(502)는 자식 표현자 객체 (및 그의 관련된 비쥬얼)를 그의 부모 표현자 객체 내부에 배치한다. 변환(transform)은 비쥬얼 객체 기본 클래스의 표준 그래픽 3x3 변환 행렬이다. 변환 행렬이 설정되면, 표현자의 그래픽 요소와 관련된 비쥬얼 객체는 그의 자식을 변환 행렬에 의해 지정된 오프셋에 배치한다.

Bounding Box 프로퍼티(504)는 자식 표현자의 렌더링 한계(rendering bound)를 지정한다. 자식 표현자의 렌더링 한계는 따라서 자식 표현자의 레이아웃 크기와 다를 수 있다.

Dirtiness 프로퍼티(506)는 자식 프록시의 표현자의 더티니스 상태를 지정한다. 표현자 시스템(200)의 일 실시예에서, 더티 상태는 clean(클린), dirty bystander(더티 바이스탠더), 또는 dirty(더티) 중 어느 하나이다. 클린 상태는 가장 최근의 뷰 갱신 이래로 자식 표현자에 어떤 변동도 일어나지 않았음을 나타낸다. 더티 상태는 가장 최근의 뷰 갱신 이래로 자식 표현자에 변동이 일어났음을 나타낸다. 더티 바이스탠더 상태는 자식 표현자 자신의 자식 중 적어도 하나가 더티 상태이지만 자식 표현자 자체는 더티 상태가 아님을 나타낸다. 이러한 상태들 은 부모 표현자가 갱신 동작을 최적화할 수 있도록 해준다.

QueryDefaultSizeInfo 메소드(510)는 자식 표현자의 부모 표현자에 의해 제공되는 디폴트 값에 의거하여 자식 표현자의 치수를 초기화한다.

Update 메소드(520)는 자식 표현자 객체의 OnUpdate 메소드(470)를 호출하도록 자식 프록시에 요청한다. 부모 표현자가 자식 표현자의 레이아웃을 계산하려고 할 때, 부모 표현자는 자식 프록시의 Update 메소드(520)를 호출한다. Update 메소드(520) 호출은 2개의 전달된 파라미터(passed parameter)를 포함한다. 박스 크기 정보는 박스의 치수를 지정하는 데, 자식은 그 박스 안에서 레이아웃을 계산하게 되며, 페이지 분할이 활성화되어 있는 경우, 부모 표현자는 페이지 기술자(page descriptor) 파라미터(이하에서 기술하는 도 10을 참조할 것)로 페이지 정보를 전달한다. 따라서, Update 메소드(520)는 호출자와 자식 표현자 객체 사이에 자식 표현자 객체에 대한 이러한 요청의 스크리닝(screening)/필터링을 가능하게 해주는 계층을 제공한다. Update 메소드(520)는 통상 자식 표현자의 OnUpdate 메소드로 라우팅되는 호출을 우회하는 방법을 제공한다. 예를 들어, Update 메소드(520) 호출은 자식 표현자가 변동되지 않고 입력 파라미터(박스 크기 정보 및 페이지 설명)가 변동되지 않은 경우에 호출된다.

부모 표현자에 의해 자식 프록시로 발행되는 Attach 메소드(530)는 자식 프록시와 관련된 자식 표현자의 OnRender 명령을 호출한다.

Query Value 메소드(540)는 메소드 호출에서 식별된 계산값 타입(프로퍼티)에 대응하는 표현자 값을 제공한다. Query Value 메소드(540) 호출은 자식 표현자 객체의 대응하는 OnQueryValue 메소드(498)에 위임된다.

Query Layout Size 메소드(550)는 계산된 레이아웃 크기 파라미터를 제공한다. Query Layout Size 메소드(550) 호출은 자식 표현자 객체의 대응하는 OnQueryValue 메소드(496)에 위임된다. Compute MinMax 메소드(560)는 자식 표현자의 최소 및 최대폭을 제공한다.

도 6을 참조하면, 표현자 시스템(200)과 관련된 한 세트의 기본 클래스는 통지 핸들러 기본 클래스를 포함한다. 앞서 설명한 바와 같이, 통지 핸들러 객체는 특정의 뷰와 관련된 표현자에 영향을 줄지도 모를 변동에 관한 모든 통지를 수신하고, 더티니스 정보를 누적하며, 관련된 표현자 객체가 갱신을 필요로 하는지 여부를 결정하는 것을 용이하게 한다. 통지 핸들러 기본 클래스의 메소드는 둘다 통지 핸들러와 관련되어 있는 그래픽 요소(예를 들어, 그래픽 요소(206)) 내의 요소로부터 관련 정보를 제공하는 메소드를 포함한 객체를 파라미터로서 수신한다.

통지 핸들러 기본 클래스는 관련된 특정 표현자 객체의 더티니스에 대한 통지를 제공하는 OnNotify 메소드(600)를 포함한다. OnNotify 메소드(600)는 (Dirtiness 프로퍼티 값을 제공하는 디폴트 동작을 재정의함으로써) 통지의 수신에 응답하여 실행되는 부가의 커스터마이즈된 파생 통지 작업을 포함할 수 있다. OnNotify 메소드(600)는 통지를 행하게 한 변동에 관한 정보를 입력 파라미터로서 수신한다. OnNotify 메소드는 통지 핸들러가 그 변동을 단독으로 처리할 수 있는지 여부(또는, 뷰의 표현자 트리 내의 선조 표현자의 통지 핸들러에 통지할 필요가 있는지)를 나타내는 부울 값을 반환한다. 이 메소드는 또한 표현자가 "클린", "더티", 또는 "더티 바이스탠더"인지를 나타내는 더티니스 값도 반환한다.

OnLayoutTask 메소드(602)는 QueueLayoutTask(496)를 통해 관련된 표현자에 의해 이전에 큐잉되어 있는 임의의 작업을 실행한다.

도 7을 참조하면, 표현자 시스템(200)과 관련된 한 세트의 기본 클래스는 통지 핸들러 사이트 클래스(notification handler site class)를 더 포함한다. 통지 핸들러 사이트 클래스는 통지 핸들러가 표현자 시스템(200)에 의해 지원되는 통지 서비스를 호출할 수 있게 해주는 통지 핸들러 객체로 전달되는 사이트 객체(site object)이다.

통지 핸들러 사이트 클래스는 통지 핸들러 사이트 객체와 관련되어 있는 그래픽 요소 객체를 지정하는 Element Owner 프로퍼티(700)를 포함한다.

Register Atom 메소드(702)는 제공된 문자열 이름을 통지 핸들러의 Layout Context(444) 내에 등록한다. Register Atom 메소드(702)의 기능은 표현자 기본 클래스에 대해 전술한 Register Atom 메소드(471)와 유사하다. 따라서, Register Atom 메소드(702)는 통지 핸들러가 요청을 다른 객체(예를 들어, 표현자 객체)로 전달하는 수단이다.

Create Notification 메소드(704)는 새로운 표현자 통지 객체를 생성하고 전달된 파라미터에 기초하여 그의 필드를 초기화한다. 전달된 파라미터는 통지 데이터 및 아톰 타입(표현자 통지 객체 타입을 나타냄)의 식별 번호를 포함한다.

Notify Descendants 메소드(706)는 지정된 표현자 통지를 전달하기 위해 통지 핸들러 사이트와 관련되어 있는 표현자의 후손과 관련된 통지 핸들러의 OnNotify 메소드(600)를 호출한다. Notify Descendants 메소드(706)는 부모 표현자에 대한 임의의 변동(예를 들면, 크기 재조정(re-sizing))을 후손 표현자에 통지하는 기능을 수행한다. 이와 유사하게, Notify Ancestors 메소드(708)는 지정된 표현자 통지를 전달하기 위해 통지 핸들러 사이트와 관련되어 있는 표현자의 선조와 관련된 통지 핸들러의 OnNotify 메소드(600)를 호출한다. 선조는 배킹 스토어(208) 내의 그래픽 요소 트리(도 3을 참조할 것)를 순회함으로써 결정된다. 배킹 스토어에 표현된 그래픽 요소는 그래픽 요소의 부모(직계 선조)를 지정하는 프로퍼티를 포함한다. NotifyAll 메소드(710)는 지정된 통지를 전달하기 위해 뷰에 의해 소유된 표현자 트리 내의 모든 표현자에 대해 통지 핸들러 객체의 OnNotify 메소드(600)를 호출한다. 마지막으로, NotifySelf 메소드(712)는 표현자가 그 자신이 더티 상태임을 표시하기 위해 OnNofity 메소드(600)를 호출하는 수단을 제공한다.

도 8을 참조하면, 예시적인 뷰 객체 클래스가 도시되어 있으며, 뷰(202)는 이로부터 인스턴스화된다. 뷰 객체는 표현자 시스템(예를 들어, 표현자 시스템(200))의 인스턴스를 가지고 있으며, 생성된 표현자 시스템 인스턴스 내에 생성된 모든 비쥬얼의 비쥬얼 루트(visual root)이다. 뷰 객체는 뷰 내의 표현자에 대한 모든 계산을 개시한다. View 메소드(800)는 새로운 뷰 객체를 생성하는 데 사용되는 생성자 메소드이다. 뷰는 그 뷰의 루트 그래픽 요소인 요소에 대한 참조를 전달된 파라미터로서 수신한다. Root Element 프로퍼티(802)는 (상기한 View 메소드(800)를 통해 설정된) 뷰의 루트 그래픽 요소에 대한 참조를 반환한다.

DoLayout 메소드(804)는 뷰의 새로운 표현자 트리를 생성하고 그 새로운 트리에 대한 참조를 반환한다. DoLayout 메소드(804)는 뷰 사각형의 제안된 높이 및 폭은 물론 제안된 치수가 DoLayout 메소드(804) 실행 동안 변경될 수 있는지를 설정하는 2개의 부울 값(FixedWidth와 FixedHeight)을 입력 파라미터로서 수신한다.

View Size 프로퍼티(806)는 뷰의 치수를 설정한다. 기록 전용 프로퍼티(write-only property)인 View Size 프로퍼티(806)는 뷰 객체가 윈도우 내에 호스팅되고 있을 때 이용되며, View Size 프로퍼티(806)는 레이아웃 동작이 수행되는 초기 크기를 나타낸다.

GetViewResult 메소드(808)는 그래픽 요소 참조를 입력으로서 수신하고, GetViewResult 메소드(808)는 그래픽 요소의 결과 뷰를 반환한다. 그래픽 요소가 뷰의 한 세트의 그래픽 요소 내에 없는 경우, 널(null) 값이 반환된다.

HitTest 메소드(810)는 뷰의 좌표계 내의 전달된 점(passed point)에서 히트 테스트를 수행한다. HitTest 메소드(810)는 제1 비투명 히트 테스트 타겟(non-transparent hit test target)을 반환한다. 히트된 그래픽 요소가 없는 경우, 메소드는 "거짓"(false)을 반환한다.

Creat Page 메소드(812)는 BoxSizeInfo(이하에 기술하는 도 9를 참조할 것) 및 Page Descriptor(이하에 기술하는 도 10을 참조할 것)를 입력 파라미터로서 수신한다. Creat Page 메소드(812)는 입력 파라미터에 기초하여 새로운 페이지를 생성하고, 그 페이지의 루트 그래픽 요소에 대응하는 자식 프록시 객체를 반환한다.

도 9를 참조하면, 예시적인 BoxSizeInfo 구조가 도시되어 있다. BoxSizeInfo 구조는 뷰 내의 표현자와 그의 자식 표현자에 대한 한 세트의 치수, 및 이들 치수가 수신측에서 어떻게 처리되어야만 하는지를 지정한다. ProposedSize 프로퍼티(900)는 뷰 내의 자식 표현자의 제안된 크기를 설명한다. 처음에, ProposedSize 프로퍼티(900)의 값은 배킹 스토어 내의 자식 그래픽 요소의 프로퍼티로부터 나온다. 그 값은 자식에게 전달하기 전에 부모 표현자에 의해 수정될 수 있다. ParentSize 프로퍼티(902)는 부모 표현자에 대한 제안된 크기이다. ParentSize 프로퍼티(902)는 일례로서 부모의 퍼센트 값으로부터 자식 표현자의 치수를 계산하는 데 사용된다. BoxSizeInfo 구조는 또한 제공된 치수가 강제된(고정된) 값인지 또는 치수값이 단지 제안된 높이 또는 폭인지를 수신측 표현자에 지시하는 2개의 부울 값 프로퍼티, 즉 FixedWidth(904)와 FixedHeight(906)을 포함한다.

도 10을 참조하면, 예시적인 페이지 기술자 구조의 일부가 도시되어 있다. 페이지 기술자는 PageSize 프로퍼티(1000)를 포함한다. PageSize 프로퍼티(1000)는 페이지의 크기를 지정하는 판독 전용 프로퍼티(read only property)이다. 이 프로퍼티는 페이지 기술자 구조가 생성될 때 초기화된다. BreakRecord 프로퍼티(1002)는 (페이지 분할되고 있는 뷰의 루트인 그래픽 요소에 대해) 그 다음 페이지 상에 있는 현재의 표현자의 첫번째 문자를 식별하는 문자 위치 시작(character position start), 이전의 페이지를 무효화시킬 수 있는 (문자 위치 시작으로부터 거꾸로 카운트한) 문자의 수, 및 브레이크 레코드(break record)(페이지 분할된 그래픽 요소 내의 특정 문자 범위를 포함함)가 배킹 스토어에 대한 변 동으로 무효화되는지를 나타내는 IsDirty 부울 값을 포함하는 구조이다.

페이지 기술자 구조는 또한 AvailableSize 프로퍼티(1004)를 포함한다. 표현자의 OnUpdate 메소드를 시작할 때 표현자가 전체 페이지를 이용할 수 없을지도 모른다. AvailableSize 프로퍼티(1004)는 표현자에 대한 페이지 상에 남아 있는 공간을 나타낸다. AvailableSize 프로퍼티(1004)는 페이지 크기의 값으로 초기화된다.

도 11을 참조하면, 뷰(202)(도 2를 참조할 것)에 의해 생성되는 표현자 시스템(200)의 표현 엔진(212)에 의해 수행되는 한 세트의 메소드가 나타내어져 있다. 표현 엔진(212)의 Constructor 메소드(1100)는 (그래픽 요소(206) 트리에 의해 제공되는) 뷰의 루트 그래픽 요소에 대한 참조를 포함하는 뷰(202)에 액세스한다. DoLayout 메소드(1102)는 폭 및 높이를 뷰(202)의 치수를 나타내는 전달된 파라미터로서 수신하고, 이에 응답하여 그래픽 요소(206)의 내용에 관한 레이아웃 과정을 실행하기 시작한다. UpdateLayout 메소드(1104)는 DoLayout을 실행한 후에 적어도 한번 실행되고, 뷰(202)의 이전에 계산된 레이아웃에 대한 점진적인 변동을 적용하기 시작한다. CreatPage 메소드(1106)는 레이아웃될 페이지의 치수를 포함하는 박스 크기 정보(BoxSizeInfo) 및 특정 페이지를 어떻게 시작하는지에 관한 정보를 포함하는 페이지 기술자(page descriptor)를 입력 파라미터로서 수신한다. CreatePage 메소드(1106)는 뷰(202)의 그래픽 요소(206)의 루트 아래에 있는 모든 내용을 레이아웃하는 것이 아니라 관심있는 하나의 페이지만을 레이아웃한다.

예시적인 레이아웃 처리 아키텍처에 대해 도 1 내지 도 11을 참조하여 기술 하였다. 예시적인 아키텍처는 요소 데이터 상태(그래픽 요소 객체)에 링크된 개별적인 뷰 상태(표현자 객체)를 포함한다. 예시적인 아키텍처는 표현자 기본 클래스(216)를 통해 뷰 레이아웃/표현 기능을 확장하는 일을 용이하게 하는 표현자 시스템(200)을 포함하며, 표현자 기본 클래스(216)로부터 새로운 레이아웃/표현 기능을 구현하는 새로운 표현자 객체 클래스가 파생된다. 본 명세서에 기술되는 시스템 및 아키텍처는 또한 변동에 응답하여 뷰의 일부분을 재계산하는 일을 선택적으로 호출하기 위해 요소를 그의 대응하는 표현자 객체에 링크시키는 통지 메카니즘을 포함한다. 예시적인 객체 기본 클래스는 본 발명을 구현하는 확장성있는 아키텍처를 실행하는 많은 가능한 대체 방법들을 설명하기 위한 것으로서 본 발명의 범위를 제한하는 것으로 보아서는 안된다.

본 발명을 구현하는 예시적인 표현/레이아웃 처리 아키텍처를 구성하는 한 세트의 컴포넌트에 대해 기술하였으며, 이제부터는 도 12를 참조하여 그래픽 표시 요소에 대한 변동을 처리하는 일반적인 과정에 대해 설명할 것이다. 처음에, 단계 1200에서 배킹 스토어(208)가 변동된다. 예를 들어, 애플리케이션(204)은 자신의 그래픽 사용자 인터페이스의 하나 이상의 표시 컴포넌트에 대한 상태 및/또는 내용 변동을 가져오는 동작을 수행한다. 이에 응답하여, 단계 1202에서, 배킹 스토어 내의 그래픽 요소에 대한 변동에 기인하여 일어나는 변동 통지는 표현자 시스템(200)의 표현 엔진(212)에 의해 수신된다.

배경으로서, 단계 1204와 관련하여 표현자 시스템(200)은 요소와 표현자 사이의 연관성을 요소-표현자 정보(element-to-presenter information, EPI)에 유지 하고 있다. 표현자가 그래픽 요소에 대해 생성될 때마다, 그 표현자에 대한 참조가 그 요소에 대해 생성되어 표현자 시스템에 의해 유지되는 EPI에 저장된다. 그래픽 요소가 2개 이상의 표현자를 갖는 경우, 그래픽 요소의 EPI에 다수의 참조(표현자마다 하나씩)가 있게 된다. 그래픽 요소에 관한 프로퍼티가 변동할 때, 이하의 단계가 행해진다.

(a) 배킹 스토어(208)는 그래픽 요소에 관한 변동을 인지한다.

(b) 자신의 프로퍼티 중 하나에 변동을 겪은 그래픽 요소를 참조하여, 배킹 스토어(208)는 표현 엔진(212)에 그 변동을 통지한다.

(c) 표현 엔진(212)은 변동된 그래픽 요소의 EPI를 조사하여(walk) 그래픽 요소에 대해 생성된 표현자를 결정한다.

(d) 표현자가 결정되면, 표현 엔진(212)은 (표현자의 NotificationHandler 프로퍼티(446)를 통해) 표현자의 대응하는 통지 핸들러에 대한 참조를 획득한다.

따라서, 전술한 바를 고려하여, 단계 1204에서, 표현자 시스템(200)의 표현 엔진(212)은 변동 통지가 적용되는 표현자의 식별자를 결정한다. 앞서 설명한 바와 같이, 표현자 시스템은 요소에 대해 인스턴스화된 표현자의 리스트를 그의 EPI에 보관한다. 변동 통지가 적용되는 표현자를 결정한 후에, (이 일례의 경우 요소에 대해 단지 하나의 표현자가 존재하는 것으로 가정하면) 표현자 시스템의 표현 엔진(212)은 식별된 표현자의 NotificationHandler 프로퍼티(446)를 통해 표현자의 통지 핸들러에 대한 참조를 획득한다.

그 후에, 단계 1206 동안에, 표현자 시스템(200)의 표현 엔진(212)은 단계 1204 동안 획득된 참조를 사용하여 변동 통지를 통지 핸들러로 포워딩한다. 본 발명의 일 실시예에서, 단계 1206은 특정 통지 핸들러 객체의 OnNotify 메소드(602)를 호출함으로써 수행된다.

표현자 시스템으로부터 변동 통지를 수신한 후에, 단계 1208 동안 (예를 들어, OnNotify 메소드(602)의 실행 동안) 통지 핸들러는 단계 1200 동안의 배킹 스토어(208) 내의 그래픽 요소에 대한 변동에 응답하여 표현자에 의해 요구되는 동작이 있는 경우 그 동작을 결정한다. 본 발명의 일 실시예에서, 통지 핸들러는 수신된 변동 통지를 고려하여 대응하는 표현자 중 갱신되어야 할 부분이 있는 경우 그곳이 어느 부분인지를 결정한다. 이러한 부분에는 일례로서 표현자의 자식 및 표현자 그 자체가 포함된다.

그 후에, 단계 1210 동안, 통지 핸들러(예를 들면, OnNotify 메소드(602))는 결과를 반환하고, 그 결과에 따라 대응하는 표현자는 단계 1202 동안 표현자 시스템(200)에 의해 수신된 변동 통지를 고려하여 동작을 결정 및 실행할 수 있게 된다. 본 발명의 일 실시예에서, 반환된 결과는 통지 핸들러/표현자 고유의 형태를 갖는다. 어떤 경우, 반환된 결과는 단순히 표현자에 "더티 상태"라고 표시만 하며, 그에 따라 대응하는 표현자의 전체적인 재계산을 호출한다. 다른 경우, 표현자의 뷰 재계산 기능의 일부만을 선택적으로 호출하도록 정보가 제공된다.

본 발명의 일 실시예에서, 단계 1210 동안 표현자 시스템(200)의 표현 엔진(212)은 반환된 결과를 표현자의 통지 핸들러로부터 수신한다. 그 후에, 단계 1212에서 배킹 스토어에 대한 변동이 표현자를 재계산할 필요성을 제기하지 않은 경우, 제어는 결정 블록(1216)으로 넘어간다. 그렇지만, 단계 1212에서 반환된 결과가 표현자가 재계산될 필요가 있음을 나타내는 경우, 제어는 단계 1214로 넘어가, 표현자 시스템(200)은 그 표현자를 재계산을 필요로 하는 한 세트의 "더티" 표현자에 추가한다. 본 발명의 예시적인 실시예에서, 표현자 시스템은 대응하는 표현자의 Dirtiness 프로퍼티(450)(표현자를 재계산할 필요성을 나타냄)를 설정하고 그 표현자를 재계산할 필요가 있는 한 세트의 표현자에 추가한다. 표현자는 또한 Dirtiness 프로퍼티(450)의 설정을 야기한 변동의 범위를 기술하는 정보를 지정한다. 이어서, 제어는 단계 1216으로 넘어간다.

단계 1216에서, 현재 관심이 있는 통지 핸들러와 관련된 표현자에 대해 부모 표현자가 존재하지 않는 경우, 제어는 종료(1218)로 넘어간다. 부모 표현자가 실제로 존재하는 경우, 제어는 단계 1216에서 단계 1220으로 넘어가, 단계 1208로 되돌아가는 점선으로 나타낸 바와 같이 부모 표현자의 통지 핸들러에 대해 통지가 생성된다(또, 그 통지 핸들러로 전달된다)(그 결과 부모의 통지 핸들러가 그 통지를 처리하게 된다).

따라서, 도 12에 도시한 일련의 단계는 표현자 시스템(200)이 문서/사용자 인터페이스의 레이아웃을 최근에 계산한 이후로 배킹 스토어(208)에 대한 변동의 결과로서 "더티" 상태로 된 표현자의 리스트를 누적할 수 있게 해준다.

이제 도 13을 참조하면, 흐름도는 특정 뷰 내의 표현자에 대한 변동에 따라 문서/사용자 인터페이스를 재계산/리렌더링하기 위한 예시적인 프로세스에 대해 기술한 것이다(상기 기술한 도 12를 참조할 것). 본 발명의 일 실시예에서, 애플리 케이션(204)은 그의 뷰(202)에 대한 갱신을 제어하고, 기간 만료, 문서 인쇄 요청 또는 그래픽 사용자 인터페이스의 상태 변동 등의 이벤트에 응답하여 도 13에 요약된 것과 같은 뷰 갱신 프로시저를 호출한다.

먼저, 단계 1300 동안, 표현자 시스템(200), 구체적으로는 표현 엔진(212)은 DoLayout 메소드(1102)(표현 엔진(212) API 설명을 참조하여 전술하였음)의 호출을 수신한다. 애플리케이션(204)에 의한 DoLayout 메소드(1102) 호출을 수신한 것에 응답하여, 표현자 시스템(200)은 최근의 DoLayout 메소드(1102) 호출 이후로 배킹 스토어(208) 내의 요소에 대한 변동에 대처하기 위해 뷰(204) 내에 포함된 표현자 객체를 재계산한다.

뷰의 표현자가 계층 구조로 배열되어 있는 본 발명의 일 실시예(도 3을 참조할 것)에서, 표현자 시스템(200)은 처음에 단계 1302에서 뷰의 루트 표현자를 결정한다. 본 발명의 일 실시예에서, 루트 표현자는 뷰(예를 들어, 뷰(204a)) 및 따라서 표현자 시스템(예를 들어, 표현자 시스템(200a))에 제공되는 루트 요소에 대한 Presenter 프로퍼티에 의해 식별된다. 루트 표현자를 결정한 후에, 제어는 단계 1304로 넘어가, 표현자 시스템(200)은 뷰에 대한 표현자의 트리를 순회하면서 각각의 더티 표현자를 재계산하기 시작한다.

단계 1304 동안에, 표현자 시스템(200)은 뷰 내의 더티 표현자들 각각의 OnUpdate 메소드(470)를 호출한다. 호출된 OnUpdate 메소드(470)는 사각형의 높이와 폭을 전달받으며, 이 사각형 내에서 표현자는 자신의 레이아웃을 재계산하게 된다. 표현자는 그의 레이아웃을 재계산한 후에, 그 결과를 캐싱한다. 따라서, 단 계 1304의 완료 시에, 이전에 더티 상태에 있는 표현자가 재계산되고, 그 결과가 차후의 리렌더링 동안 용이한 액세스를 위해 캐싱된다. 호출된 표현자 각각의 더티 비트(dirty bit)가 클리어된다. 예시적인 OnUpdate 메소드(470) 호출 동안 수행되는 일련의 단계에 대해서 도 14를 참조하여 이하에서 보다 상세히 기술된다.

단계 1304 동안 더티 표현자를 클린 상태로 만드는(clean) 다수의 방법이 있다. 그렇지만, 본 발명의 일 실시예에서, 표현자 시스템(200), 상세하게는 표현 엔진(212) UpdateLayout 메소드(1104)는 단계 1304를 완료할 때 그의 역할을 단순화하기 위해 뷰 내의 표현자 사이의 계층 구조 관계에 영향을 준다. 구체적으로 설명하면, OnUpdate 메소드(470)의 실행 동안, 각각의 호출된 표현자는 호출된 표현자의 모든 자식의 OnUpdate 메소드를 반복적으로 호출한다(또는 다른 대안에서는 그 메소드를 호출하도록 표현자 시스템(200)에 요청한다). 따라서, 표현자 시스템(200)은 루트 표현자의 OnUpdate 메소드(470)(예를 들어, 도 3의 표현자(P1))에서 표현자 트리의 순회를 시작하고, OnUpdate 메소드(470) 호출이 더티 표현자를 재계산하기 위해 계층 구조의 표현자 트리의 브랜치를 순회할 때 자식 표현자의 차후의 호출을 지원한다. 자식 표현자의 OnUpdate 메소드(470)를 반복적으로 호출함으로써 뷰 내의 모든 표현자가 순회되고, 표현자가 더티 상태인 경우, 그 표현자는 재계산된다.

완료 시에, 단계 1304 동안 호출된 각각의 OnUpdate 메소드(470)는 그의 Dirtiness 프로퍼티(450)를 리셋시켜 그 프로퍼티가 재계산되었거나 또는 "클린 상태"로 되었음을 나타낸다. 각각의 OnUpdate 메소드(470)는 또한 표현자가 리렌더 링(즉, 리드로잉(re-drawing))될 필요가 있음을 나타내는 값을 호출자에게 반환한다. 본 발명의 일 실시예에서, 반환된 값은 부울 값이다. "참"인 경우, 리렌더링이 필요하다. "거짓"이 반환된 경우, 리렌더링이 필요하지 않다. 단계 1304 동안 뷰의 더티 표현자 각각을 처리한 후에, 제어는 렌더링 단계 1306으로 넘어가, 리렌더링을 필요로 하는 표현자의 리스트에서 식별되는 표현자가 처리된다.

단계 1306 동안, 표현자 시스템(200)은 리렌더링을 요청하는 표현자의 리스트에서 식별된 표현자 각각에 대해 OnRender 메소드(474)를 호출한다. OnRender 메소드(474)의 예시적인 실시예의 동작에 대해서는 도 14를 참조하여 기술한다. OnRender 메소드(474)의 기본 클래스 구현에서, 표현자는 아무것도 드로잉하지 않으며, 그 대신에 그의 할당된 공간(예를 들어, 사각형)을 채우기 위해 그 자식 및/또는 체인화된 표현자의 OnRender 메소드(474)를 반복적으로 호출한다. 커스터마이즈된 버전의 OnRender 메소드(474)는 애플리케이션(204) 및/또는 그래픽 서브시스템의 API 및 그래픽 장치 드라이버(234)의 호출을 통해 비트맵을 렌더링한다. 단계 1306 동안 리렌더링을 요청하는 모든 표현자를 처리한 후에, 제어는 종료 단계 1308로 넘어가고, 제어는 특정 뷰에 대한 표현 엔진의 DoLayout 메소드 호출(1102)의 호출자에게로 되돌아간다.

도 14를 참조하면, 플로우차트는 뷰의 표현자를 재계산하기 위해 수행되는 OnUpdate 메소드(470)의 단계들을 요약한 것이다. OnUpdate 메소드(470)는 임의의 자식 표현자를 포함한 표현자의 새로운 레이아웃을 계산하고, 그 결과를 리렌더링 단계 동안 액세스하기 위해 캐싱한다. 이하에 제공되는 일례에서, 각각의 표현자 에 대한 OnUpdate 메소드(470) 호출은 표현자의 레이아웃이 차지할 수 있는 뷰 공간(예를 들어, 사각형)의 한계를 지정하는 한 세트의 치수를 전달한다. 한 세트의 치수는 예를 들어 높이와 폭, 그리고 이들 값이 OnUpdate 메소드(470) 호출의 실행 동안 수정될 수 있는지를 지정한다. 그렇지만, 본 발명에서는 레이아웃에 영향을 주는 뷰 공간 치수를 포함한 다양한 전달된 파라미터 중 임의의 하나 이상에 기초하여 표현자를 재계산하는 것을 고려하고 있다.

단계 1400 동안, 표현자는 임의의 자식 표현자의 갱신을 수행하기 위해 (자식 프록시 객체를 통해) 그 자식 표현자를 호출하기 전에 전달된 파라미터를 바탕으로 임의의 필요한 크기 조정 동작을 수행한다. 이러한 작업의 내용은 특정 표현자 타입의 설계에 의존한다. 그 후에, 표현자는 현재 표현자의 자식 표현자를 모두 찾아내어 이를 갱신하도록 표현자 시스템(200)에 요청한다. 사전 처리 단계 동안, 표현자는 새로운 페이지/단을 생성하고 뷰의 새로운 페이지/단을 처리하기 위한 새로운 자식 프록시/표현자를 생성할 필요성을 검지할 수 있다.

다음에, 단계 1402 동안, 현재 부모 표현자의 OnUpdate 메소드(470)는 그의 레이아웃을 갱신하기 위해 호출할 그 다음 자식 표현자를 결정한다. 유의할 점은 이 단계에서 적어도 제1 경우에 부모 표현자가 자식 요소의 존재를 결정하고 대응하는 자식 프록시/표현자를 생성할 필요가 있다는 것이다. 차후의 반복에서, 부모 표현자는 그 다음의 남아 있는(미처리된) 자식 프록시/표현자, 즉 현재 부모 표현자의 OnUpdate 메소드를 반복하고 있는 동안에 아직 호출되지 않은 자식 표현자를 식별하기 위해 그의 Children 필드(412)에서 식별되는 캐싱된 자식 프록시를 사용 할 수 있다.

부모 표현자는 배킹 스토어로부터 응답을 수신하거나, 처리할 자식 표현자가 남아 있는지를 그의 Children 프로퍼티(412)에 의거하여 독자적으로 결정하며, 단계 1404에서 갱신해야 할 미처리된 자식이 남아 있지 않은 경우, 제어는 단계 1420(이하에서 기술함)으로 넘어간다. 그렇지 않고 표현자가 아직 갱신되지 않은 미처리된 자식 표현자를 그의 Children 프로퍼티(412) 내에 가지고 있는 경우, 제어는 단계 1406으로 넘어간다.

단계 1406에서, 표현자는 자식 프록시와 관련되어 있는 자식 표현자의 높이와 폭을 획득하기 위해 부모 표현자와 관심있는 현재의 자식 표현자 사이에 개재되어 있는 반환된 자식 프록시에 대해 Update 메소드(520)를 호출한다. 자식 표현자는 특정 그래픽 요소(그의 Element Owner 필드(442)에 지정되어 있음)와 관련되어 있다.

단계 1410에서, 자식 프록시는 자식 프록시와 관련되어 있는 자식 표현자의 OnUpdate 메소드(470)를 호출한다. OnUpdate 메소드(470)는 자식 표현자의 갱신된 높이와 폭을 (그리고 리렌더링이 필요한지 여부를) 계산한다. 유의할 점은 호출된 자식 표현자가 단계 1402에서 자신이 자식을 가지고 있지 않은 것으로 결정하고 (그의 자식 프록시를 통해) 그의 호출측 부모 표현자로 반환할 때까지 단계 1410 동안 OnUpdate 메소드(470)가 자식 표현자에 의해 반복적으로 호출된다는 것이다. 자식 표현자의 OnUpdate 메소드(470)를 호출한 후에, 제어는 단계 1414로 넘어간다.

따라서, 단계 1414에서, 호출측 부모 표현자(단계 1406 참조)는 식별된 자식 프록시에 대한 Update 메소드 호출(520)에 대한 응답을 수신한다. 이 응답은 반환된 파라미터로서의 자식 표현자의 높이와 폭을 포함하고 있다. 이 응답은 또한 호출된 자식 표현자가 리렌더링을 필요로 하는지도 나타낸다. 다음에, 단계 1416에서, 부모 표현자는 배치 알고리즘/정책에 기초하여 호출된 자식 표현자를 부모 표현자의 할당받은 레이아웃 공간 내에 배치한다. 본 발명의 일 실시예에서, 단계 1416 동안 부모 표현자는 단계 1414 동안 표현자에 의해 수신된 자식 표현자의 높이와 폭 파라미터에 기초하여 자식 표현자를 그의 레이아웃 내에 배치한다.

그 다음에 제어는 단계 1402로 넘어가, 부모 표현자의 OnUpdate 메소드(470)는 (그의 자식 프록시 래퍼 객체를 통해) 남아 있는 자식 표현자를 계속하여 갱신한다.

단계 1404에서 처리/갱신할 자식 (요소 또는 프록시/표현자)이 남아 있지 않은 경우, 제어는 단계 1420으로 넘어간다. 단계 1420에서, 호출된 표현자의 OnUpdate 메소드(470)는 표현자의 레이아웃을 조정하기 위해 자식 표현자에 대해 있을 수 있는 OnUpdate 메소드(470)의 추가 호출을 포함하는 커스터마이즈된 레이아웃 기능을 수행한다.

단계 1422에서, 또는 어쩌면 OnUpdate 메소드(470)에 의해 새로운 정보가 도출되는 임의의 지점에서, 레이아웃 처리의 결과는 나중의 사용을 위해 그래픽 뷰 처리의 리렌더링 단계 동안에 캐싱된다.

호출된 표현자의 모든 자식을 포함한 표현자에 대한 갱신 처리가 완료된 후 에, 단계 1424에서 표현자는 그의 치수는 물론 표현자가 리렌더링될 필요가 있는지를 나타내는 값을 호출자(표현자 시스템(200))에게 반환한다.

당업자라면 그래픽 사용자 인터페이스 디스플레이 또는 프린터 등의 그래픽 출력 장치를 포함한 컴퓨팅 환경 내에서 그래픽 문서/사용자 인터페이스 출력의 레이아웃/표현 처리를 관리하기 위한 새로운 예시적인 플랫폼 및 예시적인 방법에 대해 기술하였음을 잘 알 것이다. 본 발명의 원리들이 적용될 수 있는 많은 가능한 환경과, 소프트웨어 유틸리티 및 툴의 설계 및 실행의 유연성을 고려하면, 본 명세서에 기술된 실시예들은 예시를 위한 것이며 본 발명의 범위를 한정하기 위한 것이 아님을 잘 알 것이다. 본 발명이 적용되는 기술 분야에서 통상의 지식을 가진 자라면 예시된 실시예가 본 발명의 정신을 벗어나지 않고 그 배열 및 상세에 있어서 수정될 수 있음을 잘 알 것이다. 따라서, 본 명세서에 기술된 본 발명은 이하의 청구항 및 그의 균등물의 범위 내에 속할 수 있는 모든 이러한 실시예를 포괄한다.

Claims (51)

1. 컴퓨팅 시스템의 표시 장치상에서 실행되는 프로그램의 그래픽 표시 출력을 정렬 및 유지시키기 위한 그래픽 출력 레이아웃 관리 시스템으로서,

   프로그램의 표시 가능 내용을 나타내는 데이터를 포함하는 그래픽 요소들과,

   상기 그래픽 요소들에 대한 표시 상태를 정의하는 표현자들(presenter)-자신의 자식에 대응하는 요소들을 이용하는 표현자는 상기 표현자가 체인화된(chained) 표현자를 필요로 하는지 여부를 결정할 수 있고, 특정 타입의 표현자는 대응하는 그래픽 요소에 대한 레이아웃 설명(description)을 유지함-과,

   특정 뷰와 관련된 표현자 세트에 영향을 주는(effect) 변경에 관한 통지를 수신하고, 더티니스 정보(dirtiness information)를 누적하고, 상기 표현자 세트가 갱신을 필요로 하는지 여부를 결정하도록 구성된 통지 핸들러 객체와,

   뷰 내에 포함된 그래픽 요소들과 관련된 표현자 세트에 따라, 상기 뷰에 대한 레이아웃을 준비하는 메소드를 포함하는 표현자 호스트 인터페이스를 포함하는 표현자 시스템 -상기 표현자들은 사용자에 의한 선택을 위해 상기 데이터에 복수의 피팅(fitting)을 제공하며, 상기 표현자들은 적어도 하나의 사전 정의된 표현자 클래스와, 상기 적어도 하나의 사전 정의된 표현자 클래스의 표시 상태를 재정의하도록(override) 구성된 적어도 하나의 로컬로 제공되는 외부 표현자 클래스를 포함함-

   을 포함하는, 그래픽 출력 레이아웃 관리 시스템.
2. 삭제
3. 제1항에 있어서, 상기 표현자들은 상기 표현자에 대한 레이아웃 프로퍼티(layout property)를 계산하는 갱신 메소드를 포함하는, 그래픽 출력 레이아웃 관리 시스템.
4. 제3항에 있어서, 상기 표현자들은 상기 컴퓨팅 시스템의 그래픽 출력 서브시스템으로 발행되는 명령어를 생성하는 렌더링(render) 메소드를 포함하는, 그래픽 출력 레이아웃 관리 시스템.
5. 삭제
6. 제1항에 있어서, 상기 표현자들 각각은 그 표현자에 지정된 레이아웃 파라미터 값에 기초하여 대응하는 그래픽 요소에 대한 레이아웃 상태를 계산하는, 그래픽 출력 레이아웃 관리 시스템.
7. 제1항에 있어서, 통지 핸들러가 그래픽 요소에 대한 변동을 처리하여, 대응하는 표현자를 갱신할지 여부를 결정하는, 그래픽 출력 레이아웃 관리 시스템.
8. 제7항에 있어서, 각각의 표현자는 관련된 그래픽 요소에 관한 변동 통지를 특정 표현자에 제공하는 통지 핸들러의 타입을 지정하는, 그래픽 출력 레이아웃 관리 시스템.
9. 제8항에 있어서, 통지 핸들러가 관련된 그래픽 요소에 대한 변동의 견지에서 갱신을 필요로 하는 대응하는 표현자의 일부를 결정하는, 그래픽 출력 레이아웃 관리 시스템.
10. 제7항에 있어서, 상기 표현자 시스템은, 대응하는 그래픽 요소들에 대한 변동에 기초하여 갱신을 필요로 하는 표현자를 상기 통지 핸들러를 통해 등록하는, 그래픽 출력 레이아웃 관리 시스템.
11. 제1항에 있어서, 상기 그래픽 요소들의 그래픽 요소 인스턴스는 다수의 표현자와 관련되어 있는, 그래픽 출력 레이아웃 관리 시스템.
12. 제11항에 있어서, 상기 그래픽 요소 인스턴스와 관련된 상기 다수의 표현자는 동일한 타입을 갖는, 그래픽 출력 레이아웃 관리 시스템.
13. 제12항에 있어서, 상기 다수의 표현자는 동일한 뷰 내의 서로 다른(distinct) 단(column)에 대응하는, 그래픽 출력 레이아웃 관리 시스템.
14. 제12항에 있어서, 상기 다수의 표현자는 하나의 그래픽 요소의 문서 뷰에 있는 서로 다른 페이지들에 대응하는, 그래픽 출력 레이아웃 관리 시스템.
15. 제11항에 있어서, 상기 그래픽 요소 인스턴스와 관련된 상기 다수의 표현자 의 제1 표현자와 제2 표현자는, 각각의 서로 다른 제1 및 제2 뷰와 관련되어 있는, 그래픽 출력 레이아웃 관리 시스템.
16. 제15항에 있어서, 상기 서로 다른 제1 및 제2 뷰는 각각의 제1 및 제2 표현자 시스템에 의해 호스팅되는, 그래픽 출력 레이아웃 관리 시스템.
17. 제1항에 있어서, 상기 뷰는 그래픽 표시 공간 내의 사각형 영역(region)에 대응하는, 그래픽 출력 레이아웃 관리 시스템.
18. 제11항에 있어서, 상기 그래픽 요소 인스턴스와 관련된 상기 다수의 표현자는 서로 다른 타입을 갖는, 그래픽 출력 레이아웃 관리 시스템.
19. 제18항에 있어서, 상기 다수의 표현자 중 하나의 표현자는 메인 표현자(main presenter)에 대한 장식 표현자(adornment presenter)를 포함하는, 그래픽 출력 레이아웃 관리 시스템.
20. 제1항에 있어서, 뷰 내의 표현자들은 자식 표현자들이 대응하는 부모 표현자에 의해 지정된 영역 내에 포함되도록 계층적으로 정렬되어 있는, 그래픽 출력 레이아웃 관리 시스템.
21. 프로그램의 표시 가능 내용을 나타내는 데이터를 포함하는 그래픽 요소를 상기 그래픽 요소에 대한 표시 상태를 정의하는 표현자들을 통해 제공하는 상기 프로그램을 대신하여 레이아웃을 처리하기 위한 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템으로서,

    표현자는 대응하는 그래픽 요소에 대한 레이아웃 설명을 유지하고 있으며, 상기 표현자 시스템은 뷰 내의 그래픽 요소들과 관련된 표현자들을 호스팅 및 정렬하며,

    상기 표현자 시스템은,

    컴퓨팅 시스템의 표시 장치와,

    표현자 기본 클래스-상기 표현자 기본 클래스로부터 표현자 클래스들이 파생되고, 상기 표현자들은 상기 표현자 클래스로부터 인스턴스화되고, 적어도 하나의 표현자 클래스는 적어도 하나의 로컬로 제공되는 외부 표현자 클래스들에 의해 재정의됨-와,

    통지 핸들러 기본 클래스-상기 통지 핸들러 기본 클래스로부터 통지 핸들러 클래스들이 파생되고, 적어도 하나의 표현자의 더티니스(dirtiness)가 결정되고, 상기 적어도 하나의 표현자가 더티하지 않으면, 상기 적어도 하나의 표현자의 자식이 더티한지 여부를 더 결정하고, 상기 더티니스는, 상기 대응하는 그래픽 요소에 대한 변경에 응하여 상기 표현자들의 재계산을 야기시킴-와,

    통지 핸들러 객체 -상기 통지 핸들러 객체는 특정 뷰와 관련된 표현자 세트에 영향을 주는 변경에 관한 통지를 수신하고, 더티니스 정보를 누적하고, 상기 표현자 세트가 갱신을 필요로 하는지 여부를 결정하도록 구성됨-와,

    표현자 호스트 인터페이스-상기 표현자 호스트 인터페이스는 상기 뷰 내의 그래픽 요소들과 관련된 상기 표현자 세트로 구현되는 레이아웃을 준비하는 메소드를 적어도 포함하는 한 세트의 메소드를 구비하고, 다수의 뷰 상태는 그래픽 요소에 대해 독립적으로 지정됨(designated)-

    를 포함하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
22. 제21항에 있어서, 상기 표현자 기본 클래스는 표현자에 대한 레이아웃 프로퍼티를 계산하기 위한 것으로, 파생된 표현자 클래스들에 의해 재정의되는 커스터마이즈가능한 갱신 메소드를 지정하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
23. 제22항에 있어서, 상기 표현자 기본 클래스는 상기 컴퓨팅 시스템의 그래픽 출력 서브시스템으로 발행되는 명령어를 생성하기 위한 것으로, 파생된 표현자 클래스들에 의해 재정의되는 커스터마이즈가능한 렌더링 메소드를 지정하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
24. 삭제
25. 제21항에 있어서, 상기 표현자 기본 클래스는 관련된 표현자에 지정된 레이아웃 파라미터 값에 기초하여 그래픽 요소에 대한 레이아웃 상태를 계산하는 메소드를 지정하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
26. 제21항에 있어서, 통지 핸들러 클래스로부터 인스턴스화된(instantiated) 각각의 통지 핸들러가 뷰 내의 특정 표현자와 관련되어 있고, 통지 핸들러가 그래픽 요소에 대한 변경을 처리하여 대응하는 표현자를 갱신해야 할지를 결정하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
27. 제26항에 있어서, 상기 표현자 기본 클래스는 관련된 그래픽 요소에 관한 변경 통지를 상기 특정 표현자에 제공하는 통지 핸들러의 타입을 지정하는 표현자용 플레이스홀더(placeholder)를 포함하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
28. 제26항에 있어서, 상기 표현자 시스템은 대응하는 그래픽 요소들에 대한 변경에 기초하여 갱신을 필요로 하는 표현자를 통지 핸들러를 통해 등록하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
29. 제21항에 있어서, 상기 표현자 시스템은 루트 그래픽 요소와 할당된 영역에 의해 특징지어지는 뷰와 관련되어 있으며, 상기 할당된 영역 내에 상기 루트 그래픽 요소 및 그의 자식 그래픽 요소를 표시하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
30. 제29항에 있어서, 상기 뷰는 그래픽 표시 공간 내의 사각형 영역에 대응하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
31. 제21항에 있어서, 상기 표현자 호스트 인터페이스는 한 세트의 그래픽 요소를 포함하는 뷰에 대한 표시를 레이아웃하기 위해 상기 표현자 시스템을 인스턴스화하는 생성자(constructor)를 포함하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
32. 제31항에 있어서, 상기 뷰는 적어도 부분적으로 상기 생성자로 전달되는 루트 그래픽 요소에 의해 지정되는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
33. 제21항에 있어서, 상기 표현자 시스템은 제1 표현자가 그래픽 요소와 관련된 제2 표현자에게 장식(adornment)을 제공하도록 다수의 표현자를 체인화하는 것을 지원하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
34. 제21항에 있어서, 상기 표현자 기본 클래스는 자식 표현자들을 지정하기 위한 플레이스홀더를 포함하며, 그에 따라 자식 표현자들이 대응하는 부모 표현자에 의해 지정된 영역 내에 포함되도록 뷰 내의 표현자들의 계층적 트리 구조의 생성을 지원하는, 그래픽 출력 레이아웃 관리 시스템 내에 포함되는 표현자 시스템.
35. 프로그램의 표시 가능 내용을 나타내는 데이터를 포함하는 그래픽 요소들을 상기 그래픽 요소들에 대한 표시 상태를 정의하는 표현자들을 통해 제공하는 상기 프로그램을 대신하여 레이아웃을 처리하기 위한 방법으로서,

    표현자는 대응하는 그래픽 요소에 대한 레이아웃 설명을 유지하고 있으며, 표현자 시스템은 뷰 내의 그래픽 요소들과 관련된 상기 표현자들을 호스팅 및 정렬하고,

    상기 방법은,

    뷰 내의 그래픽 요소들과 관련된 표현자 세트로 구현되는 레이아웃을 생성하는 메소드를 포함하는 표현자 호스트 인터페이스와 표현자 기본 클래스를 구비하는 표현자 시스템을 제공하는 단계와,

    상기 뷰 내의 그래픽 요소들과 관련된 상기 표현자 세트에 영향을 주는 변경에 관한 통지를 수신하는 단계와,

    더티니스 정보를 누적하는 단계 -상기 더티니스 정보는 일어난 변경을 나타냄-와,

    상기 표현자 세트가 갱신을 필요로 하는지 여부를 결정하는 단계-상기 결정은 상기 더티니스 정보에 기초함-와,

    뷰 내의 한 세트의 그래픽 요소들에 대한 레이아웃을 생성하라는 상기 표현자 호스트 인터페이스에 의한 요청을 수신하는 단계와,

    상기 한 세트의 그래픽 요소들에 대해, 적어도 하나의 사전 정의된 표현자 클래스 및 상기 표현자 기본 클래스로부터 파생된 적어도 하나의 사전 정의된 표현자 클래스의 표시 상태를 재정의하도록 구성된 적어도 하나의 로컬로 제공되는 외부 표현자 클래스를 포함하는 한 세트의 표현자 클래스들로부터 대응하는 표현자들을 인스턴스화하고, 각각의 인스턴스화된 표현자에 대해 상기 표현자에 대응하는 그래픽 요소에 대한 레이아웃 상태를 계산하고 상기 표현자가 체인화된 표현자를 필요로 하는지 여부를 결정하기 위해 상기 표현자의 자식에 대응하는 요소들을 사용하는 메소드를 호출하는 단계 -다수의 뷰 상태는 상기 그래픽 요소들에 대해 독립적으로 지정됨-

    를 포함하는, 레이아웃을 처리하기 위한 방법.
36. 제35항에 있어서, 대응하는 그래픽 요소들에 대한 변경에 기초하여 레이아웃의 점진적인 갱신을 용이하게 하는 한 세트의 통지 핸들러에 대한 인터페이스를 지정하는 통지 핸들러 기본 클래스를 제공하는 단계를 더 포함하는, 레이아웃을 처리하기 위한 방법.
37. 제35항에 있어서, 상기 뷰에 대한 상기 표현자를 계층 구조 트리 형태로 구성하는(organize) 단계를 더 포함하는, 레이아웃을 처리하기 위한 방법.
38. 제35항에 있어서, 상기 표현자 시스템의 인스턴스는 뷰에 대한 레이아웃을 생성하기 위한 호출에 응답하여 생성되며, 그에 따라 각 뷰마다 서로 다른 표현자 시스템 및 대응하는 표현자들을 생성하는, 레이아웃을 처리하기 위한 방법.
39. 제35항에 있어서, 상기 표현자 기본 클래스는 특정 그래픽 요소와 관련된 표현자 인스턴스에 대한 레이아웃 프로퍼티를 계산하는 갱신 메소드를 지정하는, 레이아웃을 처리하기 위한 방법.
40. 제35항에 있어서, 상기 표현자 기본 클래스는 그래픽 출력 서브시스템으로 발행되는 명령어를 생성하는 렌더링 메소드를 지정하는, 레이아웃을 처리하기 위한 방법.
41. 삭제
42. 제35항에 있어서, 상기 표현자 클래스는 서로 다른 타입의 그래픽 요소 내용을 레이아웃하는 서로 다른 타입의 표현자에 대응하는, 레이아웃을 처리하기 위한 방법.
43. 제35항에 있어서, 뷰 내의 표현자들은 자식 표현자들이 대응하는 부모 표현자에 의해 지정된 영역 내에 포함되도록 계층 구조로 정렬되는, 레이아웃을 처리하기 위한 방법.
44. 프로그램의 표시 가능 내용을 나타내는 데이터를 포함하는 그래픽 요소들을 상기 그래픽 요소들에 대한 표시 상태를 정의하는 표현자들을 통해 제공하는 상기 프로그램을 대신하여 레이아웃의 처리를 용이하게 하기 위한 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 저장 매체로서,

    표현자는 대응하는 그래픽 요소에 대한 레이아웃 설명을 유지하고 있으며, 표현자 시스템은 뷰 내의 그래픽 요소들과 관련된 상기 표현자들을 호스팅 및 정렬하고,

    상기 컴퓨터 실행가능 명령어는,

    뷰 내의 그래픽 요소들과 관련된 표현자 세트로 구현되는 레이아웃을 생성하는 메소드를 포함하는 표현자 호스트 인터페이스와 표현자 기본 클래스를 구비하는 표현자 시스템을 제공하는 단계와,

    뷰 내의 한 세트의 그래픽 요소에 대한 레이아웃을 생성하라는 상기 표현자 호스트 인터페이스에 의한 요청을 수신하는 단계와,

    상기 뷰 내의 그래픽 요소들과 관련된 상기 표현자 세트에 영향을 주는 변경에 관한 통지를 수신하는 단계와,

    더티니스 정보를 누적하는 단계 -상기 더티니스 정보는 일어난 변경을 나타냄-와,

    상기 표현자 세트가 갱신을 필요로 하는지 여부를 결정하는 단계-상기 결정은 상기 더티니스 정보에 기초함-와,

    상기 한 세트의 그래픽 요소들에 대해, 적어도 하나의 사전 정의된 표현자 클래스 및 상기 표현자 기본 클래스로부터 파생된 적어도 하나의 사전 정의된 표현자 클래스의 표시 상태를 재정의하도록 구성된 적어도 하나의 로컬로 제공되는 외부 표현자 클래스를 포함하는 한 세트의 표현자 클래스로부터 대응하는 표현자들을 인스턴스화하고, 각각의 인스턴스화된 표현자에 대해 상기 표현자에 대응하는 그래픽 요소에 대한 레이아웃 상태를 계산하는 메소드를 호출하는 단계-다수의 뷰 상태는 상기 그래픽 요소들에 대해 독립적으로 지정되고, 상기 표현자 시스템은 적어도 하나의 상기 표현자 세트에 대한 더티니스 프로퍼티를 결정하고, 상기 더티니스 프로퍼티에 기초하여 상기 적어도 하나의 표현자 세트를 재계산하고, 상기 표현자 세트 중 특정 하나가 더티하지 않다면, 상기 표현자 세트 중 상기 특정 하나의 자식이 더티한지 여부를 결정함-

    를 포함하는 방법을 수행하는 것을 용이하게 하는, 컴퓨터 판독가능 저장 매체.
45. 제44항에 있어서, 상기 뷰의 상기 표현자들을 계층 구조 트리 형태로 구성하기 위한 컴퓨터 실행가능 명령어를 더 포함하는, 컴퓨터 판독가능 저장 매체.
46. 제44항에 있어서, 상기 컴퓨터 실행가능 명령어들은 뷰에 대한 레이아웃을 생성하기 위한 호출에 응답하여 상기 표현자 시스템의 인스턴스를 생성하고, 그에 따라 각 뷰마다 서로 다른 표현자 시스템 및 대응하는 표현자들을 생성하는 것을 용이하게 하는, 컴퓨터 판독가능 저장 매체.
47. 제44항에 있어서, 상기 표현자 기본 클래스는 특정 그래픽 요소와 관련된 표현자 인스턴스의 레이아웃 프로퍼티를 계산하는 갱신 메소드를 지정하는, 컴퓨터 판독가능 저장 매체.
48. 제44항에 있어서, 상기 표현자 기본 클래스는 그래픽 출력 서브시스템으로 발행되는 명령어를 생성하는 렌더링 메소드를 지정하는, 컴퓨터 판독가능 저장 매체.
49. 삭제
50. 제44항에 있어서, 상기 표현자 클래스는 서로 다른 타입의 그래픽 요소 내용을 레이아웃하는 서로 다른 타입의 표현자들에 대응하는, 컴퓨터 판독가능 저장 매체.
51. 제44항에 있어서, 상기 표현자 기본 클래스는 자식 표현자들용 플레이스홀더를 지정하며, 그에 따라 자식 표현자들이 대응하는 부모 표현자에 의해 지정된 영역 내에 포함되도록 뷰 내에서 표현자들을 계층적으로 레이아웃하는 것을 용이하게 하는, 컴퓨터 판독가능 저장 매체.

Images