응용 프로그램의 기본 : Windows Presentation Foundation으로 최상의 사용자 인터페이스 빌드 -- MSDN Magazine, 2006년 10월

Michael Weinhardt (영문)

목차
응용 프로그램 유형
창
Page 클래스
Hyperlink 클래스
NavigationWindow
NavigationService
XAML 브라우저 응용 프로그램
프레임
Windows Presentation Foundation 리소스
PageFunction
정리

사용자 환경이란 관련된 콘텐츠 전체와 해당 콘텐츠가 호스팅되는 방식을 함께 일컫는 말로, 이 모든 것에 의해 사용자 환경이 결정됩니다. Windows® Presentation Foundation에서 콘텐츠는 표준 컨트롤, 2D 및 3D 그래픽, 애니메이션, 데이터 바인딩, 레이아웃, 스타일 및 템플릿 지정을 통해 만들어집니다. 그러나 이러한 콘텐츠가 사용자가 눈으로 보고 상호 작용할 수 있는 방식으로 호스팅되지 않는다면 사실상 아무 쓸모없는 것이 됩니다. 콘텐츠는 응용 프로그램 내에 패키지화되어야 하며 창을 통해 표시되어야 합니다. 바로 이것이 응용 프로그램 모델이 편리한 이유입니다.

Windows Presentation Foundation 응용 프로그램 모델은 독립 실행형 응용 프로그램과 브라우저 응용 프로그램이라는 두 가지 응용 프로그램 유형을 구분합니다. 독립 실행형 응용 프로그램에서는 해당 응용 프로그램의 창과 대화 상자, 메시지 상자를 통해 콘텐츠를 표시합니다. 이에 반해 브라우저 응용 프로그램은 브라우저에서 호스팅되는 고유의 페이지로 구성됩니다.

Windows Presentation Foundation은 또한 메뉴 기반 탐색 및 하이퍼링크 기반 탐색이라는 두 가지 유형의 탐색을 구분합니다. 메뉴 기반 응용 프로그램에서 사용자는 기존의 데스크톱 Windows 기반 응용 프로그램과 마찬가지로 메뉴 모음, 도구 모음, 창 및 대화 상자를 통해 콘텐츠와 기능을 탐색하게 됩니다. 하이퍼링크 기반 응용 프로그램에서는 웹 응용 프로그램과 유사한 탐색 환경을 제공합니다.

때문에 독립 실행형 응용 프로그램은 메뉴 기반 탐색을 지원하고, 브라우저 응용 프로그램은 하이퍼링크 기반 탐색을 지원합니다. 그러나 Windows Presentation Foundation 응용 프로그램 모델을 사용하면 이러한 두 가지 요소를 섞어 사용할 수 있습니다. 이러한 경우 하이퍼링크 기반 환경이 부분적으로나 전체적으로, 독립 실행형 응용 프로그램에 통합됩니다. 이와 같은 조합은 반드시 사용자의 이점을 극대화할 수 있는 환경 유형을 기반으로 해야 합니다. 사용할 환경을 결정한 다음에는, Windows Presentation Foundation 응용 프로그램 모델을 통해 이를 빌드할 수 있습니다.

응용 프로그램 유형

그림 1의 샘플 상자 응용 프로그램을 살펴보겠습니다. 이 응용 프로그램은 독립 실행형이며 메뉴 기반 응용 프로그램으로, 상자 목록을 확인하고, 주문하며, 주문 내용을 보고, 상자 주문을 삭제하는 등의 업무를 수행할 수 있습니다. 이러한 사용자 환경을 제공하려면 모든 응용 프로그램 모델의 기본이 되는 응용 프로그램 생성 방법에 대해 알아야 합니다.

그림 1 상자 응용 프로그램 (크게 보려면 이미지를 클릭하십시오.)

Windows 기반 응용 프로그램은 진입점과 메시지 루프를 모두 포함하는 표준 작업으로 구성되어 있으며 다음과 같은 일반적인 응용 프로그램 서비스가 필요할 수도 있습니다.

명령줄 매개 변수 처리
종료 코드 반환
응용 프로그램 범위 상태
처리되지 않는 예외의 검색 및 응답
응용 프로그램 수명 관리

Windows Presentation Foundation을 사용하면 작업 및 서비스를 모두 단일 유형인 System.Windows.Application으로 중앙 집중화할 수 있습니다. 이러한 System.Windows.Application은 태그(XAML), 코드(C# 또는 Visual Basic®) 또는 둘의 조합(태그 및 코드 숨김)을 통해 사용할 수 있습니다. Visual Studio® 2005에서 .NET Framework 3.0(이전의 WinFX®) Windows 응용 프로그램 프로젝트에 새로운 인스턴스를 자동으로 추가하므로 응용 프로그램에는 매우 유용합니다.

<!--App.xaml (markup)-->
<Application 
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="BoxApplicationWindow.App" 
/>

// App.xaml.cs (코드 숨김)
public partial class App : Application { ... }

Windows Forms 및 Win32®와 같은 Windows 프레젠테이션 기술을 이전에 프로그래밍해 본 적이 있다면, 새로운 기능에 더욱 놀라게 될 것입니다. 이번에는 진입점을 비롯하여, 표준 Windows 기반 응용 프로그램 작업을 설정할 때 사용했던 것처럼 원격으로 보이는 코드를 전혀 사용하지 않습니다. 왜냐하면 사용자를 위해 응용 프로그램 작업이 생성되기 때문입니다. 그림 2에서 확인할 수 있듯이, 응용 프로그램 작업은 Visual Studio 2005에서 응용 프로그램 태그 파일을 ApplicationDefinition 빌드 작업으로 구성한 결과물입니다.

그림 2 응용 프로그램 XAML 파일 설정

내부적으로 이 코드에 상응하는 코드가 만들어집니다.

// App.cs
using System; 

public partial class App : Application 
{
  [STAThread]
  public static void Main() 
  {
    // 응용 프로그램 초기화 및 실행
    App application = new App();
    application.Run();
  }
}

정확히 무엇이 만들어지는지는 중요하지 않으므로 사용자는 복잡한 코드를 직접 작성하거나 이해할 필요가 없습니다. 사용자는 최신 Microsoft 프레젠테이션 기술의 가장 완벽한 응용 프로그램 추상화를 지원받고 있으며 이를 이용하면 태그 하나만으로도 실행되는 응용 프로그램을 만들 수 있습니다. 사용자가 수행해야 할 작업은 응용 프로그램 서비스를 사용하는 것뿐입니다. 독립 실행형 응용 프로그램의 경우, 응용 프로그램이 시작될 때 창이 나타납니다.

페이지 맨 위로

창

Windows Presentation Foundation에서 창은 Window 클래스에 해당합니다. 창은 독립 실행형 응용 프로그램의 콘텐츠 호스팅에서 가장 핵심적인 단위입니다. 사용자가 Visual Studio 2005에서 프로젝트 | 새 항목 추가 | WinFX 창을 선택하면 다음과 같은 내용이 생성되며 프로젝트에 창 정의를 추가할 수 있습니다.

<!--MainWindow.xaml (markup)--> 
<Window 
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="BoxApplication.MainWindow"
</Window> 

// MainWindow.xaml.cs (코드 숨김)
using System.Windows;
public partial class MainWindow : Window { ... }

창 정의가 추가되면 Visual Studio 2005에서는 자동으로 페이지에 태그 파일 빌드 유형을 구성합니다. 빌드된 태그는 URI(Uniform Resource Identifier)에 의해서만 식별되는 특별한 유형의 리소스로 변환됩니다. 결과적으로 이러한 과정을 통해 Windows Presentation Foundation은 URI로부터 창을 선언적으로 로드할 수 있으며 사용자는 이러한 기능을 사용하여 응용 프로그램이 시작될 때 창이 자동으로 열리도록 지정할 수 있습니다. 아래와 같이 태그에서 Application.StartupUri 특성을 설정합니다.

  <!--App.xaml (markup)-->
  <Application ... StartupUri="MainWindow.xaml"  />

이렇게 하면 그림 3과 같은 창을 만들고 표시할 수 있습니다. 다른 모든 창과 마찬가지로, Windows Presentation Foundation 창에는 Windows Presentation Foundation 콘텐츠 및 컨트롤이 배치되는 클라이언트 영역이 있으며, 테두리, 제목 표시줄 및 이와 관련한 다양한 항목이 포함된 비클라이언트 영역이 있습니다.

그림 3 창과 그 구성 부분

Application.StartupUri에서 만들어진 창은 모덜리스 유형입니다. 즉, 사용자는 해당 응용 프로그램 내에서 다른 창을 사용해도 전혀 제약을 받지 않습니다. 지금까지 다른 창을 만들어 본 적이 없다면 그다지 실감이 나지 않을 수도 있습니다. 다른 모덜리스 창을 표시해야 한다면 복잡한 응용 프로그램인 경우에도 Window.Show를 간단하게 호출하기만 하면 됩니다.

// MainWindow.xaml.cs (코드 숨김)
public partial class MainWindow : Window 
{ 
  void helpContentsMenuItem_Click(object sender, RoutedEventArgs e) 
  {
    HelpWindow window = new HelpWindow();
    window.Owner = this; // 창을 항상 위에 표시
    window.Show();
  }
  ... 
 }

Windows Presentation Foundation은 모달 창도 지원합니다. 이 경우 응용 프로그램 내에서 다른 창을 사용하려고 하면 제약을 받게 됩니다. 항상 그런 것은 아니지만 모달 창은 주로 대화 상자로 사용되며 새 주문을 생성하는 것과 같은 업무를 진행하는 데 필요한 데이터를 수집하게 됩니다. Windows Presentation Foundation에서 모달 창을 표시하려면 Window.ShowDialog를 호출해야 합니다(그림 4 참조).

Window 클래스는 사용자가 대화 상자를 수락 또는 거절하거나 적절한 처리를 위한 호출 코드에 대해 선택 사항을 반환하는 것과 같은 일반적인 대화 상자 동작을 지원합니다.

메시지 상자는 사용자에게 정보를 표시하거나 질문하기 위한 특별한 유형의 대화 상자이며 Windows Presentation Foundation에서 MessageBox 형식을 통해 지원됩니다.

// MainWindow.xaml.cs (코드 숨김)
public partial class MainWindow : Window 
{ 
  void aboutMenuItem_Click(object sender, RoutedEventArgs e) 
  {
    MessageBox.Show("Box Application, Version 1.0");
  }
  ... 
}

메시지 상자, 대화 상자, 창 및 응용 프로그램 폼은 메뉴 기반의 독립 실행형 응용 프로그램 개발 모델의 핵심 기능입니다. 이러한 기능은 이전의 프레젠테이션 기술을 통해서도 계속해서 지원되어 왔습니다. 그러나 Windows Presentation Foundation에서 이 기능은 콘텐츠 탐색의 기본 단위인 페이지에서 시작하는 하이퍼링크 기반 탐색 지원으로 확장되었습니다.

페이지 맨 위로

Page 클래스

페이지는 Windows Presentation Foundation에서 HTML 웹 페이지와 유사한 부분으로 웹을 대중화하는 데 기여한 요소입니다. 앞서 언급한 바와 같이, Windows Presentation Foundation은 독립 실행형 응용 프로그램과 브라우저 응용 프로그램 모두에 걸쳐 하이퍼링크 기반 탐색을 지원합니다. Windows Presentation Foundation의 하이퍼링크 기반 탐색 환경에서 콘텐츠의 기본이 되는 것은 페이지입니다.

사용자가 Visual Studio 2005에서 프로젝트 | 새 파일 추가 | WinFX 페이지를 선택하면 프로젝트에 태그 및 코드 숨김 페이지 정의를 추가할 수 있습니다. 그림 5와 같은 코드가 생성됩니다.

Page 태그 파일은 Page 빌드 항목으로 구성됩니다. 창과 마찬가지로 페이지도 URI에서 로드되도록 구성됩니다. 즉, 응용 프로그램이 시작될 때 자동으로 페이지를 로드하도록 Application.StartupUri를 구성할 수 있습니다.

<!--App.xaml (markup)-->
<Application ... StartupUri="HomePage.xaml" />

Page 클래스는 창이 아닐 뿐 아니라 Window에서 파생되지 않으므로 스스로 호스팅할 수 없습니다. 특정 페이지가 StartupUri로 설정된 경우 Application 클래스에서 이를 감지하며 이에 따라 응용 프로그램은 페이지를 호스팅할 수 있는 창을 만들게 됩니다.

페이지 맨 위로

Hyperlink 클래스

모든 하이퍼링크 기반 응용 프로그램은 둘 이상의 XAML 페이지를 포함하므로 사용자에게 이러한 페이지를 탐색할 수 있는 방법을 제공해야 합니다. Windows Presentation Foundation을 사용하면 하이퍼링크로 하이퍼링크 기반 탐색을 수행할 수 있습니다. 사용자는 페이지에 다음과 같이 하이퍼링크를 추가할 수 있습니다.

<!--HomePage.xaml (markup)-->
<Page ... >
  ...
      <Hyperlink NavigateUri=          "OrderingGuidelinesPage.xaml">
    Ordering Guidelines
  </Hyperlink>
  ...
</Page>

이 하이퍼링크는 HTML HREF와 동일한 기반 프로그래밍 모델을 사용하여 XAML 페이지를 탐색할 수 있도록 구성되었습니다. 탐색할 URI 및 사용자에게 표시될 텍스트를 지정한 다음 클릭하여 탐색을 시작합니다. 이 문서의 예에서는 URI는 OrderingGuidelinesPage.xaml, 사용자에게 표시할 텍스트는 "Ordering Guidelines"입니다.

HTML 기반 웹 페이지에는 검색 가능한 콘텐츠가 무궁무진하므로 Windows Presentation Foundation과 하이퍼링크를 사용하면 웹 기반의 콘텐츠를 자유롭게 탐색할 수 있습니다. 예를 들어 상자 응용 프로그램의 웹 사이트에 주문 지침이 이미 있는 경우 이를 응용 프로그램 내에서 XAML 페이지로 복제하지 않고 간단히 NavigateUri 속성 값을 변경할 수 있습니다.

<!--HomePage.xaml (markup)-->
<Page ... >
  ...
  <Hyperlink NavigateUri="OrderingGuidelinesPage.html">
    Ordering Guidelines
  </Hyperlink>
  ...
</Page>

페이지 맨 위로

NavigationWindow

이 시점에서 몇 가지 의문 사항이 있을 수 있습니다. 페이지가 창이 아니라면 창은 대체 어디서 호스팅되는 것일까요? 하이퍼링크를 클릭할 경우 실제로 탐색 작업을 처리하는 것은 무엇일까요? 그리고 Windows Presentation Foundation 응용 프로그램에서 HTML 웹 페이지 콘텐츠는 어떻게 표시되는 것일까요? 이러한 모든 것을 바로 NavigationWindow가 처리합니다.

Application.StartupUri를 XAML 또는 HTML 페이지로 설정할 경우, 응용 프로그램(XAML 또는 HTML 페이지에서 자체적으로 창을 제공할 수 없음)은 해당 내용을 호스팅할 NavigationWindow의 인스턴스를 만듭니다. NavigationWindow는 Window에서 파생되었으며 그림 6과 같이 브라우저 모양으로 확장됩니다.

그림 6 NavigationWindow를 통해 생성

사용자가 XAML 페이지에 표시된 하이퍼링크를 클릭하면, 하이퍼링크는 특정 URI를 탐색할 것을 NavigationWindow에 요청합니다. NavigationWindow는 해당 URI에 있는 페이지를 로드하고 이를 호스팅합니다. 로딩된 페이지의 URI 위치는 NavigationWindow.Source 속성에 저장되며 로딩된 페이지 콘텐츠는 NavigationWindow.Content 속성에서 제공합니다.

콘텐츠가 변경되는 경우, 탐색이 이루어진 것으로 간주되므로 탐색 기록에 이전 콘텐츠가 추가됩니다. 이 또한 NavigationWindow에 의해 관리됩니다. 탐색 UI에서는 탐색에 사용할 두 가지 단추와 드롭다운 목록을 제공합니다. NavigationWindow의 기본 크롬에 제한될 필요는 없으며 Windows Presentation Foundation의 스타일 지원을 사용하면 고유한 탐색 UI를 쉽게 만들 수 있습니다.

지금까지 하이퍼링크를 통해 탐색을 수행해야 하는 URI를 구성하는 과정에 태그를 사용하는 방법을 살펴보았습니다. 그러나 선언적으로 탐색을 수행할 수 없는 경우가 있습니다. 예를 들어 주문을 확인하려는 경우 Page의 인스턴스를 만들어 확인할 주문에 전달해야 합니다. 이러한 과정은 선언적으로 이루어지지 않습니다. 그 대신 그림 7과 같이 코드를 사용해야 합니다.

하이퍼링크를 클릭하면 Click 이벤트 처리기가 현재 선택된 주문을 받아 인스턴스화 과정에서 이를 ViewOrderPage에 전달합니다. 그 다음 호스트 NavigationWindow의 Navigate 메서드를 호출합니다. 이 메서드는 URI가 아닌 개체로 페이지를 탐색합니다.

호스트 NavigationWindow에 대한 참조를 가져와야 하는 것이 이상하다고 여겨질 수도 있습니다. 이를 수행해야 하는 이유는 Page를 실제로 호스팅하는 것이 무엇인지에 대한 명시적인 정보가 없기 때문입니다. Page는 고유의 Parent 속성을 사용하여 호스트를 확인할 수 있지만 이러한 Parent 속성은 특정 호스트 형식에 대해 엄격하게 형식이 지정된 참조를 반환하지 않고 DependencyObject에 참조를 반환합니다. 따라서 특정 형식으로 Parent를 캐스팅함으로써 Page를 호스팅하는 것이 무엇인지 알게 되는 것입니다. 그러나 Page의 호스트는 여러 다른 형식일 수 있습니다. 결과적으로 다양한 형식의 호스트에서 Page를 호스팅하려는 경우, 호스트 독립적인 방법으로 프로그래밍 방식의 탐색을 수행해야 합니다.

페이지 맨 위로

NavigationService

Windows Presentation Foundation에서 페이지와 페이지 호스트 간의 독립성은 NavigationService에 의해 설정됩니다. NavigationService는 탐색, 탐색 기록, 탐색 수명, 콘텐츠 및 콘텐츠 조각에 대한 탐색 서비스 검색과 같은 탐색 엔진의 기본적인 메커니즘을 구현하는 역할을 수행합니다. 그림 8에서는 NavigationService 형식의 기본 멤버를 보여 줍니다. NavigationWindow는 실제로 고유의 탐색 엔진을 구현하지 않으며 NavigationService의 고유한 인스턴스를 사용합니다. Page는 GetNavigationService를 사용하여 Page를 호스팅하는 NavigationWindow의 NavigationService에 대한 참조를 얻을 수 있습니다.

// HomePage.xaml.cs (코드 숨김)
public partial class HomePage : Page 
{ 
  void viewHyperlink_Click(object sender, RoutedEventArgs e) 
  {
    // 주문 보기
    ViewOrderPage page = new ViewOrderPage(GetSelectedOrder());
    NavigationService ns = 
      NavigationService.GetNavigationService(this);
    ns.Navigate(page);
  }

  Order GetSelectedOrder() { ... }
  ...
}

이와 같은 방법을 사용할 경우 Page는 호스트에 대한 정보 없이도 탐색을 수행할 수 있습니다. Page에서 특수 도우미 속성인 NavigationService를 제공하도록 하는 이러한 방법은 매우 일반적이며 동일한 결과를 얻을 수 있습니다.

// HomePage.xaml.cs (코드 숨김)
public partial class HomePage : Page 
{ 
  void viewHyperlink_Click(object sender, RoutedEventArgs e) 
  {
    // 주문 보기
    ViewOrderPage page = new ViewOrderPage(GetSelectedOrder());
    this.NavigationService.Navigate(page);
  }
  
  Order GetSelectedOrder () { ... }
  ...
}

그림 9에서는 NavigationWindow, NavigationService 및 Page 간의 관계를 보여 주고 있습니다. 그림에서 확인할 수 있듯이, NavigationWindow는 NavigationService의 Content 속성을 재구현합니다. NavigationWindow는 이러한 방법을 통해 대부분의 NavigationService 멤버를 재구현하며 여기에 멤버를 추가하기도 합니다. 예를 들어 BackStack 및 ForwardStack 속성을 각각 사용하여 탐색 기록 앞뒤에 있는 콘텐츠를 열거할 수 있습니다.

그림 9 관계

NavigationService를 집계하는 고유한 사용자 지정 형식을 만들 수는 없습니다. public 형식이기는 하지만 인스턴스화를 방해하는 내부 생성자가 있습니다. 그 대신 세 개의 Windows Presentation Foundation NavigationService 집계 중 한 가지를 기반으로 콘텐츠를 호스팅해야 합니다. 이러한 것을 통틀어 탐색기(navigator)라고 하며 여기에는 NavigationWindow, 프레임 및 브라우저(Windows Presentation Foundation 1.0 버전용 Internet Explorer® 6 및 7만 사용 가능)가 포함됩니다. 고유한 NavigationService 속성을 사용하여 페이지를 코딩할 경우 그림 10과 같이 세 가지 집계 모두에서 변경 없이 호스팅될 수 있습니다.

그림 10 탐색을 위한 코드 사용

가장 흥미로운 부분은 단일 독립 실행형 응용 프로그램 내에서 페이지를 호스팅할 수 있을 뿐 아니라 Internet Explorer를 사용하여 원하는 위치 어디서든 호스팅할 수 있다는 사실일 것입니다.

페이지 맨 위로

XAML 브라우저 응용 프로그램

NavigationWindow, 페이지 및 하이퍼링크는 독립 실행형 응용 프로그램 내에서 편리한 방식으로 브라우저 스타일의 사용자 환경을 제공합니다. 간단히 말해 NavigationWindow는 현재 우리가 사용하고 있는 브라우저의 즐겨찾기나 검색 탭 등과 같은 보조 기능이 없을 뿐 엄연한 브라우저입니다. 대부분의 사용자는 브라우저 사용에 능숙하기 때문에 동일한 수준의 기능을 제공하는 응용 프로그램이나 브라우저 통합형 응용 프로그램을 사용하는 것에 불편함을 느끼지 않습니다. 브라우저 호스팅 환경 및 하이퍼링크 기반 환경을 사용함으로써 응용 프로그램이 더 많은 혜택을 제공한다면 XBAP(Windows Presentation Foundation XAML Browser Applications)는 바로 그러한 것을 가능하게 하는 프로그램입니다.

샘플 응용 프로그램의 XBAP 버전을 만들려면 Visual Studio 2005에서 새로운 .NET Framework 3.0 웹 브라우저 응용 프로그램을 만드십시오. 그 다음 샘플의 NavigationWindow 버전에서 파일을 복사하면 됩니다(응용 프로그램 정의 제외). Internet Explorer에서 호스팅되어 실행되는 결과 응용 프로그램은 그림 11에서 볼 수 있습니다.

그림 11 Internet Explorer에서 호스팅되는 응용 프로그램

인트라넷이나 인터넷을 통해 XBAP를 웹 서버에 게시할 수도 있고 실행할 수도 있습니다. .NET Framework 3.0에 포함된 ClickOnce 배포를 통해 이러한 작업을 수행할 수 있습니다. MSBuild는 ClickOnce를 사용하기 위해 사용자가 실행하게 될 실행 파일을 만들고, ClickOnce에서 해당 실행 파일을 다운로드 및 실행하는 데 필요한 두 개의 매니페스트 파일도 만듭니다. 이 중 하나가 응용 프로그램 매니페스트이며 파일 확장명은 .xbap입니다. 응용 프로그램 매니페스트는 사용자가 XBAP를 실행하고자 하는 경우 실제로 탐색하게 되는 파일입니다. 실행 프로세스는 자연스럽게 진행됩니다. XBAP 응용 프로그램을 탐색하는 환경은 브라우저에서 다른 응용 프로그램을 탐색하는 것과 다르지 않습니다.

인터넷을 통해 응용 프로그램을 시작하는 경우 보안이 문제가 될 수 있습니다. 그러한 이유로 XBAP는 설치되지 않습니다. 또한 XBAP는 .NET Framework의 CAS(Code Access Security)를 활용하여 강제 보안 샌드박스(security sandbox)를 통해 사용자를 악성 코드로부터 보호합니다. XBAP는 인터넷 영역에서 시작된 응용 프로그램에 대해 허용된 항목만 실행하며 제한된 작업만 수행합니다. XBAP가 인터넷 영역 내에서 사용할 수 없는 기능을 실행하려고 하는 경우에는 예외 오류가 발생하며 해당 응용 프로그램은 실행이 중단됩니다.

인터넷 영역 권한을 설정할 경우 창 표시, SaveFileDialog 사용, 레지스트리 액세스 및 스크립트를 통한 HTML DOM(Document Object Model) 액세스와 같은 Windows Presentation Foundation 1.0의 다양한 기능을 사용할 수 없게 됩니다. 그러나 CAS 보안에 기반을 둔 XBAP 응용 프로그램의 장점을 활용하기 위해 위와 같은 기능의 사용을 포기하는 경우에도, Windows Presentation Foundation의 핵심적인 기능은 사용할 수 있습니다.

페이지 맨 위로

프레임

프레임은 브라우저 스타일의 사용자 환경을 기타 탐색기(독립 실행형 또는 브라우저 기반, 메뉴 또는 하이퍼링크 기반)에 의해 호스팅될 수 있는 콘텐츠로 포함합니다. 이러한 유연성으로 인해 사용자는 원래 의도했던 사용자 환경에 맞춰 이와 같은 기능을 어떤 식으로 사용할지 결정할 수 있습니다.

메뉴 기반의 독립 실행형 응용 프로그램은 도움말 파일과 같은 문서 스타일의 콘텐츠를 통해 탐색하기에는 적합하지 않습니다. 이와 같은 작업에는 하이퍼링크 기반 응용 프로그램이 적합하며 링크는 독립 실행형 응용 프로그램의 창에 쉽게 포함될 수 있습니다. 아래의 그림 12를 참조하십시오. 다음의 태그를 통해 이를 수행할 수 있습니다.

    <!--HelpDialog.xaml (markup)-->
<Window ... >
    <DockPanel>
        <TextBlock 
          Padding="20,20,20,20" 
          DockPanel.Dock="Top" 
          TextWrapping="Wrap" 
          FontSize="15" 
          FontWeight="Bold" >
            Box Application Help
        </TextBlock>
        <Frame Padding="20,0,20,0"           Source="HelpPageContents.xaml" />
    </DockPanel>
</Window>

또는, Windows Presentation Foundation 페이지의 콘텐츠 내에서 호스팅하는 방식으로 프레임을 HTML IFRAME 요소와 같이 사용할 수 있습니다. 그림 13을 참조하십시오. 이에 대한 태그는 다음과 같습니다.

 <!--HelpPage.xaml (markup)-->
 <Page ... >
     <DockPanel>
         <TextBlock 
           Padding="20,20,20,20" 
           DockPanel.Dock="Top" 
           TextWrapping="Wrap" 
           FontSize="15" 
           FontWeight="Bold" >
             Box Application Help
         </TextBlock>
         <Frame ... Source="HelpPageContents.xaml" />
     </DockPanel>
</Page>

그림 12 독립 실행형 창의 검색 가능한 콘텐츠

기본적으로, 프레임이 콘텐츠 내에서 직접 호스팅되거나 다른 탐색기에 의해 간접적으로 호스팅되는 경우 프레임은 부모 탐색기에서 관리하는 탐색 서비스를 사용합니다. 이는 프레임의 탐색 기록이 프레임의 부모 탐색기의 탐색 기록과 함께 저장되어 있다는 것을 의미합니다. 따라서 부모 탐색기의 탐색 기록을 탐색하기 전에 프레임의 탐색 기록을 앞뒤로 모두 탐색해야 합니다. 부모 탐색기가 여러 페이지에서 공유할 수 있는 콘텐츠를 호스팅하는 경우에는 이 방법도 나쁘지 않습니다. 이는 ASP.NET의 마스터/자식 콘텐츠의 상황과 일정 부분 유사합니다.

그림 13 콘텐츠 내에서 호스팅되는 프레임 (크게 보려면 이미지를 클릭하십시오.)

반면 한 개의 프레임의 여러 페이지가 단일 논리 콘텐츠 집합을 구성하는 탐색의 경우에는 이 같은 방식이 사용자에게 고역일 수 있습니다. 이러한 예로 한 개 이상의 도움말 페이지가 아닌 단일 도움말 파일을 들 수 있습니다. 사용자가 도움말로 들어가 적절한 도움말 페이지를 탐색할 경우, 지금까지 찾아본 모든 도움말 페이지를 뒤로 돌아가 탐색하지 않고 이전 부모 페이지로 바로 돌아가고 싶을 것입니다. 이런 경우 JournalOwnership 속성을 다음과 같이 설정하여 프레임에서 고유한 탐색 기록을 사용하도록 할 수 있습니다.

<Page ... >
  ...
  <Frame ... JournalOwnership="OwnsJournal" />
  ...
</Page>

JournalOwnership은 프레임이 어떤 “기사”를 사용할지(내부 기사 형식은 탐색 기록을 Windows Presentation Foundation 내에 캡슐화) 결정하도록 설정하는 속성으로 JournalOwnership의 열거 값 중 하나가 될 수 있습니다.

enum JournalOwnership 
{
  Automatic,        // Frame 또는 NavigationWindow에서 호스팅하는 경우 
                    // "UsesParentJournal", 그렇지 않은 경우 
                    // "OwnsJournal"(기본값)
  OwnsJournal,      // Frame에서 탐색 기록 관리
  UsesParentJournal // Frame의 호스트에서 탐색 기록 관리}

프레임이 고유의 탐색 기록을 갖게 되면 그림 14와 같이 그 차이를 명확히 보여 주는 프레임 고유의 탐색 사용자 인터페이스를 표시하게 됩니다.

그림 14 프레임 고유의 탐색 기록 (크게 보려면 이미지를 클릭하십시오.)

페이지 맨 위로

Windows Presentation Foundation 리소스

지금까지 응용 프로그램 어셈블리에 포함되는 페이지에 대해 알아 보았습니다. 콘텐츠는 다양한 위치로부터 로드될 수 있습니다. 코드는 코드를 사용하는 어셈블리에 포함될 수도 있고, 참조 어셈블리에 포함될 수도 있습니다. 아니면 어떤 어셈블리에도 포함되지 않는 느슨한 콘텐츠(loose content) 파일로 구성될 수도 있습니다. 느슨한 콘텐츠는 로컬 디스크나 파일 공유, 또는 웹 사이트에 위치할 수 있습니다. 콘텐츠 조각은 포함된 것이든 느슨한 것이든 관계없이 페이지가 아닙니다. 콘텐츠에는 이미지, 동영상, 오디오와 같은 다양한 미디어가 포함될 수 있습니다. 또한 콘텐츠는 특정 응용 프로그램에 속할 필요도 없습니다. 다른 웹 응용 프로그램에 속하는 HTML 페이지 역시 마찬가지입니다.

이러한 유연성으로 인해 개발자들은 더욱 쉽게 다양한 종류의 시나리오를 처리할 수 있습니다. 하나의 응용 프로그램에 특화된 콘텐츠가 있을 수 있습니다. 또한 그에 반해 해당 응용 프로그램은 이러한 콘텐츠에 매우 독립적일 수 있습니다. 이런 경우 해당 콘텐츠를 어셈블리에 적절하게 포함하는 방법으로 응용 프로그램과 함께 배포합니다. 콘텐츠가 정기적으로 변경되어 새로운 콘텐츠를 다시 배포하기 위해 지속적으로 어셈블리를 다시 빌드해야 하는 응용 프로그램의 경우에는 느슨한 콘텐츠를 지원하기도 합니다. 느슨한 콘텐츠는 공용 위치에 존재하므로 인터넷 및 인트라넷 기반의 XBAP 응용 프로그램은 불필요한 어셈블리를 다운받지 않아도 됩니다. 또한 여러 응용 프로그램에서 콘텐츠를 공유하는 경우도 있습니다. 그러나 이 경우 가용성이 보장되어야 합니다.

이러한 유연성을 활용하기 위해 Windows Presentation Foundation에서는 고유 식별 및 리소스 로드를 위한 특수 메커니즘을 통합했습니다. 이 메커니즘에서는 콘텐츠가 어디에 위치하는지, 콘텐츠가 포함된 것인지 아니면 느슨한 콘텐츠인지 하는 것은 아무런 문제가 되지 않습니다. 이 메커니즘의 기초는 고유 URI를 사용하여 응용 프로그램 리소스를 확인할 수 있는 확장 가능한 구성표인 Pack URI 구성표입니다. Windows Presentation Foundation은 Pack URI 구성표를 사용하여 콘텐츠 로딩과 관련한 여러 가지 일반적인 시나리오를 지원합니다.

이 기사 전체에 걸친 샘플 코드에서는 Application.StartupUri 및 Hyperlink.NavigateUri가 사용될 때마다 Pack URI를 사용하여 창 및 페이지를 확인하고 로드하였습니다.

<!--App.xaml (markup)-->
<Application ... StartupUri="HomePage.xaml" />

이 예는 사용자의 입력 작업을 간소화시켜 주는 것으로, 상대 Pack URI가 사용되었습니다. 이 상대 Pack URI를 절대 Pack URI로 표시하면 다음과 같습니다.

pack://application:,,,/HomePage.xaml

절대 Pack URI는 구성표(pack://), 인증 기관(application:), 경로(,/HomePage.xaml)의 세 가지 주요 부분으로 구성되어 있습니다. 인증 기관은 리소스가 있는 컨테이너의 유형을 나타내며, 경로는 컨테이너에 상대적인 리소스의 위치를 나타냅니다. "application:" 컨테이너는 실제 어셈블리이며 경로는 해당 어셈블리의 루트에 상대적인 리소스의 위치입니다.

절대 Pack URI 또는 상대 Pack URI 중 하나를 사용할 때 콘텐츠는 어셈블리 내에 포함되거나 응용 프로그램 실행 파일에 상대적인 위치에 저장되는 XAML 사용 완화 파일로 존재하게 됩니다. 응용 프로그램 실행 파일과 동일한 폴더 내에 존재하는 XAML 사용 완화 페이지의 경우 Pack URI는 다음과 같습니다.

pack://application:,,,/HomePage.xaml

XAML 사용 완화 파일에 대한 Pack URI는 동일한 이름의 포함된 파일에 대한 Pack URI와 같습니다. 이 둘을 구분하기 위해 Windows Presentation Foundation에서는 기본 확인 메커니즘을 사용하여 어셈블리 내에서 느슨한 리소스를 찾기 전에 먼저 포함된 리소스를 찾습니다.

Pack URI는 참조된 어셈블리 내에 포함된 Windows Presentation Foundation 리소스에 액세스할 때에도 사용할 수 있으며 다음과 같이 약간 다른 구문으로 표시됩니다.

pack://application:,,,/BoxApplicationLibrary;component/HomePage.xaml

이에 해당하는 상대 Pack URI는 다음과 같습니다.

/BoxApplicationLibrary;component/HomePage.xaml

Pack URI를 사용하면 응용 프로그램 원본 위치(응용 프로그램이 시작된 위치)의 리소스를 찾아 로드할 수 있습니다. XBAP 응용 프로그램이 웹 서버에서 시작된 경우 콘텐츠를 최신으로 유지하는 것은 새 콘텐츠를 해당 응용 프로그램의 게시 위치에 끌어 놓는 것만큼 간단합니다. 원본 위치의 느슨한 리소스에 액세스하려면 절대적으로 사용될 수 있는 특수한 형식의 다른 Pack URI를 사용해야 합니다.

pack://siteoforigin:,,,/HomePage.xaml

포함된 페이지 또는 느슨한 페이지와 같은 모든 페이지에 대해 해당 페이지의 조각에 대한 탐색을 사용할 수 있습니다. 웹 스타일 조각 탐색과 같은 방법을 사용하면 됩니다. 다음과 같이 XAML 요소에 Name 특성을 부여함으로써 페이지 조각을 정의할 수 있습니다.

<Page ... >
   <TextBlock Name="Paragraph1" TextWrapping="Wrap">
     ...
   </TextBlock>
</Page>

페이지 조각을 탐색하려면 다음과 같이 페이지 URI에 접미사 "#XAMLElementName"을 추가한 특수한 Pack URI를 사용해야 합니다.

HelpPage3.xaml#Paragraph3

페이지 맨 위로

PageFunction

다양한 위치의 하이퍼링크 기반 응용 프로그램에서 파생된 콘텐츠는 여러 다른 위치에 대한 탐색을 허용하므로 작업을 완료하는 것이 어려울 수 있습니다. 하이퍼링크 기반 응용 프로그램에서는 사용자가 특정 페이지를 탐색하는 것을 제한하는 것이 어렵기 때문입니다. 응용 프로그램에서 많은 하이퍼링크를 제공한다 해도 사용자는 브라우저의 주소 표시줄을 통해 가고자 하는 곳으로 이동할 수 있습니다. 결과적으로 사용자는 작업 완료 여부와 관계없이 작업이 시작된 페이지를 그대로 두고 다른 페이지로 이동할 수도 있는 것입니다. 웹에서는 세션 상태 등을 기반으로 하여 웹 페이지에 대한 대화 상자와 유사한 스타일의 동작을 만들 수 있는 여러 가지 방법이 있습니다. 그러나 이러한 방법은 많은 비용이 듭니다. 대화 상자를 통해 문제를 해결할 수 있지만 보안 문제로 인해, 부분적으로 신뢰하는 인터넷 영역에서 실행되는 XBAP와 같은 응용 프로그램에서는 창을 인스턴스화할 수 없습니다.

그러나 Windows Presentation Foundation은 Page 함수를 사용하여 모달 대화 상자 스타일의 메커니즘을 지원합니다. 이는 Page에서 간접적으로 파생되는 generic PageFunction 형식에 캡슐화됩니다. PageFunction은 Page와 유사한 형태이며 유사한 스타일로 빌드됩니다. 그림 15를 참조하십시오.

이러한 Page 함수의 용도는 주문에 의해 캡슐화되는 새 주문 정보를 수집하는 것입니다. 대부분의 작업에서 데이터를 이러한 방식으로 처리하므로 PageFunction은 generic이며 특정 데이터 부분(태그에 대한 특수한 x:TypeArguments 특성)에 대해서만 작동하도록 선언됩니다. x:TypeArguments 값과 generic PageFunction의 형식 인수가 일치하지 않는 경우 컴파일 오류가 발생합니다.

PageFunction을 호출하려면 호출 페이지는 PageFunction을 인스턴스화하고 이를 수동으로 탐색해야 합니다.

// HomePage.cs (코드 숨김)
public partial class HomePage : Page 
{
  void orderHyperlink_Click(object sender, RoutedEventArgs e) 
  {
    OrderABoxPageFunction pageFunction = new OrderABoxPageFunction();
    pageFunction.Return += new ReturnEventHandler<Order>(
      OrderABoxPageFunction_Returned);
    this.NavigationService.Navigate(pageFunction);
  }
  ...
}

그 다음, PageFunction은 호출 페이지에 결과를 반환하기 전에 사용자가 페이지에 대한 작업을 완료할 수 있도록 해야 합니다.

// OrderABoxPageFunction.cs (코드 숨김)
public partial class OrderABoxPageFunction: 
  PageFunction<Order>
{
  void orderHyperlink_Click(object sender, RoutedEventArgs e) 
  {
    // 주문 반환
    this.OnReturn(new ReturnEventArgs<Order>(this.order));
  }
  void cancelHyperlink_Click(object sender, RoutedEventArgs e) 
  {
    // 주문 취소
    this.OnReturn(null);
  }
  ...
}

generic ReturnEventArgs의 인스턴스를 전달하기 위해 PageFunction.OnReturn이 호출되어 반환됩니다. 작업이 수행되면 여기에 PageFunction이 작동하는 인스턴스 형식이 포함됩니다. 그렇지 않은 경우 null 값으로 나타납니다. PageFunction의 반환을 감지하고, ReturnEventArgs 및 해당 데이터를 얻기 위해 호출 페이지는 PageFunction.Returned를 처리해야 합니다. 그림 16을 참조하십시오. 반환된 데이터는 Returned 이벤트 처리기 ReturnEventArgs의 Result 속성에 포함됩니다.

작업이 완료된 후 PageFunction이 탐색 기록에서 제거되었는지 확인하고 싶을 것입니다. 아주 간단한 구성을 통해 이를 알아볼 수 있습니다.

<!--OrderABoxPageFunction.xaml (markup) -->
<PageFunction RemoveFromJournal="True" ... >
  ...
  <!--Content-->
  ...
<PageFunction>

탐색 기록에서 Page 함수를 제거하면 사용자가 Page 함수로 다시 돌아와 탐색하는 것을 막을 수 있습니다. 이렇게 하는 것이 중요한 이유는 사용자가 Page 함수에 액세스하여 데이터를 변경한 다음 다시 데이터를 편집할 가능성이 있기 때문입니다. 이 경우 데이터의 일관성이 손실될 우려가 있습니다.

하나의 작업이 여러 콘텐츠 페이지로 구성되는 경우도 있습니다. 이는 마법사 스타일의 사용자 환경에서 일반적으로 볼 수 있습니다. 이 경우에도 PageFunction을 사용할 수 있습니다. PageFunction은 하나의 Page 함수를 사용할 때와 동일한 방식으로 여러 Page 함수를 처리할 수 있습니다.

페이지 맨 위로

정리

Windows Presentation Foundation 응용 프로그램 모델은 유연성이 대단히 뛰어납니다. 기본적으로, 메뉴 기반 탐색과 하이퍼링크 기반 탐색을 모두 지원하는 독립 실행형 응용 프로그램과 브라우저 호스트 응용 프로그램을 모두 사용할 수 있습니다. 또한 응용 프로그램 콘텐츠는 응용 프로그램 어셈블리 또는 참조된 어셈블리에 패키지화될 수 있으며 여러 위치의 느슨한 파일로 지정될 수도 있습니다. 결국 Windows Presentation Foundation 응용 프로그램 모델 내에서 만들어지는 모든 사용자 환경은 사용자가 무엇을 선택하느냐에 따라 그 범위가 정해지게 되는 것입니다.

페이지 맨 위로