수안이의 컴퓨터 연구실

4 Articles, Search for 'WPF'

2008/01/20 눈길가는 블로그 아티클 [1월 셋째주]
2008/01/04 어도비 플렉스 (Adobe Flex)
2007/07/23 Windows Presentation Foundation으로 최상의 사용자 인터페이스 빌드
2007/07/23 Windows Presentation Foundation 소개

Webdizen/Blog2008/01/20 23:49

눈길가는 블로그 아티클 [1월 셋째주]

MySQL, Sun에 팔리다.
Sun이 MySQL을 산답니다!
Sun Microsystems, MySQL AB 10억 달러에 인수
Sun이 MySQL을 사버렸군요!
Sun의 오픈소스 진영으로의 변화에 이어서 정말 놀라운 일이 계속 일어나네요.

결국, BEA Oracle 에 인수 되버리다
Oracle... BEA... 엄청난 액수에 인수해버리는군요.

2007년 인상깊은 건축물 Top 100
이런 건축물들을 볼때마다 사람들의 무한한 능력을 다시 느끼게 된답니다.

음악 치료에 응용되는 음악
평소 클래식 음악을 즐겨 듣는 편입니다. 다들 들었을 베토벤과 모짜르트 음악이죠;
이런 정보도 괜찮네요. 한번 찾아서 들어봐야겠습니다.

매일 아침 고구마 한개 껍질째 드세요
고구마를 좋아해서 아침마다 쪄 먹고 그랬는데; 껍질째 먹으라네요; ㅋㅋ
껍질 깨끗이 씻고, 통째로 먹어야 겠습니다.

에어론 의자 (Herman Miller, Aeron Chair)
구름 위에 앉은 걸까?
사실 연구실에 의자들을 모두 바꿔보려고 의자를 찾아보다가...
이럴수가; 100만원이 넘는 놈이네요; 에어론 의자! 돈만 있다면 사고 싶어지네요;

25 Beautiful Minimalistic Website Designs
정말 아름다운 웹 사이트 25개이네요. 웹 디자인에도 관심이 많아서; ㅋㅋ

Ruby on the Rails를 닮은 PHP 프레임워크, CakePHP
저번에 Web Framework에 대해서 조사하다가 잠깐 봤었던 CakePHP Framework 였는데...
멋진 기능들이 상당하네요... 나중에 한번 써봐야겠습니다.

사이클로이드(cycloid) 블로깅
억지로 해서 안되는 일도 시간이 지나면 저절로 해결되는 경험은 누구나 가지고 있을 것입니다. 아무리 머리를 짜내도 떠오르지 않던 해답이 어느 순간 저절로 생각나는 경우도 있었을 것입니다. 밤새워가며 한일인데 한숨자고 일어나 다시 보니 헛점투성이라서 당황했던 기억이 있을 것입니다. 시간이라는 기한에 쫓겨서 서두른 일은 늘 빈틈을 남기고, 오히려 그르친 결과로 이어지기도 합니다. 급할수록 돌아가라는 말은 이런 일상의 경험에서 나온 격언이기도 하지만 매우 과학적인 근거를 가지고 있습니다. 시작과 끝을 연결하는 최단거리의 직선보다 끝지점에 더 빨리 도착하는 사이클로이드(cycloid)는 더 긴 거리를 지닌 곡선입니다.

저는 이와 같은 경험을 많이 가지고 있었는데... 과학적인 근거가 확실히 있었군요.

카지노에서 돈 따는 법
일단 Las Vegas에 갈때를 위한 단순 참고용

리눅스 커널(kernel)에 심각한 보안 결함 발견
이거 커널 업데이트 해야 할 서버가 한두개가 아닌데; 큰일이네요;
그 전에 보안 결함 이용하는 방법 좀 알고 싶어지네요;

웹 개발자 VS 웹 서비스 기획자
흥미있는 글입니다.

WPF를 이용한 멋진 '뉴스리더' 체험해 보세요
오호! 재미있습니다.

내 블로그의 정보를 파해친다!! IWEBTOOL.COM
이거 유용하네요. ^^

"Blog" 카테고리의 다른 글

Posted by webdizen

No Trackback No Comment

Leave your greetings.

Web/Flex2008/01/04 23:49

어도비 플렉스 (Adobe Flex)

출처 : http://ko.wikipedia.org/

어도비 플렉스(Adobe Flex) 는 2004년 3월 매크로미디어에 의하여 만들어진 소프트웨어 개발 키트(Software development kit|software development kit) 와 개발자들을 위한 IDE 이다. (다만 현재는 어도비 시스템즈에서 개발되고 있다.) 그들이 가지고 있는 어도비 시스템즈 플래시 플랫폼 기반으로 리치 인터넷 어플리케이션을 크로스플랫폼에서 개발하고 배포할 수 있도록 지원한다.

2007년 4월 어도비는 플렉스 3 SDK 에 대한 플렉스 오픈소스 계획을 발표했다. 하지만 실행 환경에서 플렉스 응용 프로그램을 보기 위한 어도비 플래시 플레이어와 플렉스 응용 프로그램을 개발하기 위한 IDE 인 플렉스 빌더는 여전히 독점적이고 상업적으로 남아 있다.

개요

전통적인 응용 프로그램 개발자들이 플래시 플랫폼으로 만드는 애니메이션을 적용하기에는 어려움이 있었다. 플렉스는 이러한 과정의 어려움을 최소화하고 응용 프로그램 개발자들에게 익숙한 개발 모델을 제시하였다.

플렉스는 초기에는 J2EE 응용 프로그램 또는 JSP 태그 라이브러리를 통해서 동적으로 MXML 과 액션스크립트(ActionScript) 코드를 플래시 응용 프로그램(SWF 파일)으로 컴파일하는 것만 가능하였다. 그리고 이후 버전부터 서버 라이선스 없이 프로그램 코딩 후 파일을 컴파일 할 수 있도록 하고 온라인에 배포 할 수 있도록 지원하기 시작한다.

플렉스의 목적은 응용 프로그램 개발자들에게 빠르고 쉽게 리치 인터넷 응용 프로그램을 개발할 수 있도록 하는 것이다. n계층모델에서 플렉스 응용은 프레젠테이션 계층을 제공한다.

플렉스의 특징은 MXML 이라고 불리우는 XML 기반 언어를 사용하여 GUI 개발을 가능하게 한다. 이것은 웹서비스, 원격객체, 드래그 앤 드롭, 컬럼 정렬, 챠트, 그래픽 객체, 애니메이션 효과 등을 구현하기 위한 다양한 구성요소와 기능들로 이루어져 있다. 그리고 이들의 상호 간의 통신 또한 간단하게 구성할 수 있다. 사용자가 한번 호출하면 작업마다 서버에서 템플릿을 실행하는 것을 요청하는 versus HTML, 기반의 응용(PHP,ASP,JSP,CFMX)보다 훨씬 향상된 응용 작업 흐름을 플렉스의 언어와 파일 구조는 디자인으로부터 응용 로직을 분리하도록 이루어져 있다.

플렉스 서버는 또한 사용자가 XML 웹서비스와 원격 객체(CFCs 나 Class 그리고 AMF 를 지원하는 그 밖의 다른 객체)를 가지고 통신하는 것을 허용하는 게이트웨이로 동작한다.

일반적으로 플렉스를 대체하는 것들을 언급할 때 오픈라즐로, Ajax, XUL, JavaFX 그리고 실버라이트와 같은 WPF 기술을 이야기한다.

라이브사이클 데이터 서비스

LiveCycle Data Services (이전에는 플렉스 데이터서비스(FDS) 였음) 는 플렉스 SDK 와 플렉스빌더와 함께 플렉스 제품군 중 하나로 서버측 지원을 담당한다. 자바 엔터프라이즈 응용으로 배치될 때 LDS 는 플렉스 응용 프로그램에 추가적인 기능을 지원한다.

리모팅, 플렉스클라이언트 응용 프로그램이 직접 자바 서버 객체와 연결될 수 있도록 한다. 마치 RMI(Java remote method invocation)와 비슷한 기능이다. 원격에서 데이터 마샬링을 자동으로 다룰 수 있고 이진 데이터를 전송 포맷으로 사용한다.
메시징에서 구독/배포의 디자인패턴의 목적으로 배포를 제공한다. 플래시 클라이언트는 서버에서 설정한 배포 이벤트에 대하여 메시지 서비스로부터 배포되는 이벤트를 구독할 수 있다. 대표적인 예가 금융 데이터 또는 시스템 상태 정보와 같은 실시간 데이터 스트리밍이다.
플렉스 클라이언트로 다운로드된 데이터를 자동적으로 관리하는 개발 모델을 제공하는 데이터 관리 서비스이다. 서버로부터 데이터가 한 번 로드된 뒤에 변경되는 사항은 자동적으로 검사가 되고 응용 프로그램의 요청으로 서버와 동기화된다. 클라이언트는 또한 서버 측에서 데이터가 변경되는 것을 바로 확인할 수 있다.
서버에 특정 위치에 저장된 클라이언트 데이터 또는 이미지와 함께 PDF 문서를 만들어낼 수 있는 API 를 제공합니다.

오픈소스 리모팅 기능으로 PHP 를 사용한다면 AMFPHP 를 대신 사용할 수 있다.

플렉스 응용 프로그램 개발 과정

아래의 자료들은 플렉스 2 베타 3 도움말에서 가져온 내용이다.

UI 컴포넌트(폼, 버튼 등)을 사용하여 어플리케이션 양식의 태그를 정의한다.
사용자 인터페이스 디자인안에 정의된 컴포넌트를 사용한다.
시각적 디자인을 정의하기 위하여 스타일나 테마를 사용한다.
동적인 행동을 추가한다.(응용 프로그램이 다른 요소들과 상호작용)
필요에 따라 데이터 서비스와 연결하는 부분을 정의한다.
소스코드를 빌드하고 플래시 플레이어에서 작동할 수 있도록 SWF 파일을 만든다.

- 참고할만한 사이트

Adobe - Flex Developer Center
http://www.adobe.com/devnet/flex/

Flex.org
http://flex.org/

Adobe Labs - Adobe Flex
http://labs.adobe.com/technologies/flex/

Adobe Flex2 Component Explorer
http://examples.adobe.com/flex2/inprodu ··· rer.html
이거 상당히 흥미로운 예제이다. ㅋㅋ

철수네 소프트웨어 세상 3 - 오만한 Flex
http://charlz.wordpress.com/2007/05/24/ ··· uttal%2F

"Flex" 카테고리의 다른 글

어도비 플렉스 (Adobe Flex) (0)2008/01/04

Posted by webdizen

Tags Adobe, Ajax, Flex, Flex 2, JavaFX, MXML, WPF, XML, XUL

No Trackback No Comment

Leave your greetings.

Programming/WCF/WPF2007/07/23 09:44

Windows Presentation Foundation으로 최상의 사용자 인터페이스 빌드

사용자 환경이란 관련된 콘텐츠 전체와 해당 콘텐츠가 호스팅되는 방식을 함께 일컫는 말로, 이 모든 것에 의해 사용자 환경이 결정됩니다. 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 응용 프로그램 모델 내에서 만들어지는 모든 사용자 환경은 사용자가 무엇을 선택하느냐에 따라 그 범위가 정해지게 되는 것입니다.

"WCF/WPF" 카테고리의 다른 글

Windows Presentation Foundation으로 최상의 사용... (0)2007/07/23
Windows Presentation Foundation 소개 (0)2007/07/23
Windows Communication Foundation과의 관계로 보... (0)2007/07/23
WCF(Windows Communication Foundation) 아키텍처... (0)2007/07/23

Posted by webdizen

Tags Windows Presentation Foundation, WPF, 인터페이스

No Trackback No Comment

Leave your greetings.

Programming/WCF/WPF2007/07/23 09:43

Windows Presentation Foundation 소개

David Chappell
Chappell & Associates

2006년 9월

적용 대상:
Windows Vista
Windows Presentation Foundation
Microsoft .NET Framework 3.0

요약: WPF(Windows Presentation Foundation)의 기본적인 목표는 개발자가 세련되고 편리한 사용자 인터페이스를 만들 수 있도록 돕는 것입니다. 이 문서에서는 WPT 통합 플랫폼을 사용하여 디자이너가 사용자 인터페이스 개발 작업에 보다 적극적으로 참여하는 방법과 독립 실행형 응용 프로그램 및 브라우저 응용 프로그램을 만들기 위한 공통적인 프로그래밍 모델을 제공하는 방법에 대해 설명합니다.

Windows Presentation Foundation 설명

기본적으로 기술은 주로 전문가들이 중요하게 생각하는 부분으로 대부분의 소프트웨어 전문가들은 응용 프로그램과 사용자 간의 상호 작용 방식보다는 응용 프로그램의 작동 방식에 훨씬 더 많은 관심을 가집니다. 그러나 응용 프로그램을 구입하는 실제 사용자에게는 사용자 인터페이스가 매우 중요합니다. 응용 프로그램의 인터페이스는 해당 소프트웨어에 대한 전체적인 사용자 환경에서 중요한 부분을 차지하며, 사용자에게 이러한 환경은 응용 프로그램 '그 자체'를 의미합니다. 더 나은 인터페이스를 통해 향상된 사용자 환경을 제공하면 생산성을 높이고 우수 고객을 더 많이 확보할 수 있으며 웹 사이트에서의 매출을 늘리는 등 다양한 효과를 얻을 수 있습니다.

이전에는 문자 기반 인터페이스만으로 충분했지만 오늘날의 사용자들은 그래픽 인터페이스에 익숙해졌으며 사용자 인터페이스에 대한 요구 사항은 계속해서 증가하고 있습니다. 그래픽과 미디어가 더욱 광범위하게 사용되고 있으며 웹의 발전은 소프트웨어와의 편리한 상호 작용을 기대하는 사용자 계층을 형성하게 되었습니다. 사용자들이 응용 프로그램을 사용하는 시간이 늘어날수록 해당 응용 프로그램의 인터페이스는 더욱 중요해집니다. 이렇듯 점점 높아지는 인터페이스 요구 사항에 부응하기 위해서는 사용자 인터페이스를 만드는 기술도 함께 발전해야 합니다.

WPF(Windows Presentation Foundation)의 목표는 Windows에 바로 이러한 고급 기능을 제공하는 것입니다. Microsoft .NET Framework 버전 3.0에 포함된 WPF를 사용하면 문서, 미디어, 2차원 및 3차원 그래픽, 애니메이션, 웹 특성 등을 포함하는 인터페이스를 만들 수 있습니다. WPF는 .NET Framework 3.0의 모든 구성 요소와 마찬가지로 Windows Vista, Windows XP 및 Windows Server 2003에서 사용할 수 있으며 Windows Vista와 함께 출시될 예정입니다. 이 백서에서는 WPF를 소개하고 WPF의 다양한 구성 요소에 대해 설명하며 이 기술을 통해 해결할 수 있는 문제점과 WPF가 제공하는 솔루션에 대해 살펴봅니다.

문제점 예시

병원에서 환자를 진료하고 모니터링하는 데 사용할 새 응용 프로그램을 만든다고 가정해 보겠습니다. 새로 만들 응용 프로그램에는 다음과 같은 사용자 인터페이스가 필요할 수 있습니다.

환자에 대한 이미지와 텍스트 표시
심장 박동수, 혈압 등 환자의 활력 징후를 보여 주는 2차원 그래픽 표시 및 업데이트
환자 정보에 대한 3차원 보기 및 오버레이 제공
초음파 또는 기타 진단 비디오를 표시하고, 가능한 경우 의사나 간호사가 메모를 추가할 수 있는 기능 제공
병원 직원이 환자 및 환자 상태에 대한 기록을 읽고 메모를 추가할 수 있는 기능
병원 직원이 모든 기능을 사용할 수 있도록 Windows 응용 프로그램으로 실행되고 다른 위치에 있는 의사가 인터넷을 통해 제한적인 방식으로 액세스할 수 있도록 엄격한 보안이 유지되는 웹 브라우저 응용 프로그램으로도 실행

이러한 요구 사항은 야심적이기는 하지만 충분히 실현 가능합니다. 필요한 정보를 적시에 적절한 방법으로 제공하는 사용자 인터페이스는 업무상 중요한 가치를 지닙니다. 앞에서 설명한 의료 응용 프로그램의 예에서는 적절한 사용자 인터페이스가 생명을 구할 수도 있습니다. 온라인 상점 또는 기타 고객 지향 응용 프로그램과 같은 일반적인 시나리오의 경우 강력한 사용자 환경을 제공하면 회사의 서비스를 경쟁사의 서비스와 차별화하여 매출 증진은 물론 회사의 브랜드 가치를 높일 수 있습니다. 중요한 점은 많은 수의 최신 응용 프로그램에서 그래픽, 미디어, 문서 및 기타 최신 사용자 환경의 요소를 통합하는 인터페이스를 제공함으로써 다양한 이점을 누릴 수 있다는 것입니다.

2006년 현재의 기술로 Windows에 이러한 유형의 인터페이스를 만들 수도 있지만 이러한 작업은 다음과 같은 주요 장애 요인으로 인해 실현하기 매우 어렵습니다.

그래픽, 이미지 및 비디오로 작업하는 데 서로 다른 여러 기술이 사용됩니다. 이러한 다양한 기술을 활용하기 위해 유능한 개발자를 찾는 것은 이러한 개발자가 만드는 응용 프로그램을 유지 관리하는 것만큼 어렵고 비용도 많이 듭니다.
이러한 모든 기능을 사용자에게 효과적으로 제공하는 인터페이스를 디자인하는 일은 도전적인 과제입니다. 소프트웨어 개발자의 기술만으로는 이러한 인터페이스를 디자인할 수 없기 때문에 전문 디자이너가 필요하지만 여기에서 설명한 모든 기능을 갖춘 인터페이스를 개발하기 위해 디자이너와 개발자가 공동으로 작업하는 데는 많은 제약이 따릅니다.
모든 기능을 갖춘 인터페이스를 독립 실행형 Windows 응용 프로그램 버전과 브라우저에 호스팅되는 버전의 두 가지 형식으로 제공하려면 서로 다른 두 가지 분야의 기술을 사용하여 각 버전을 개별적으로 구현해야 합니다. Windows 데스크톱 응용 프로그램은 Windows Forms 및 기타 기본적인 Windows 기술을 사용하여 구현하고 브라우저에 호스팅되는 응용 프로그램은 HTML 및 JavaScript를 사용하여 구현할 수 있습니다. 이 경우 서로 다른 두 분야의 기술을 갖춘 두 개의 개발자 그룹이 필요합니다.

강력한 기능을 제공하는 최신 사용자 인터페이스를 만드는 작업을 복잡하게 생각할 필요는 전혀 없습니다. 공통적인 기반을 사용하면 이러한 모든 문제를 해결하고 개발자에게 단일화된 접근 방식을 제공하는 동시에 디자이너도 작업에서 중요한 역할을 담당하도록 할 수 있습니다. 이것이 바로 WPF의 목표이며, 자세한 내용은 다음 섹션에서 설명합니다.

문제점 해결: Windows Presentation Foundation의 기능

WPF가 제공하는 가장 중요한 세 가지 특징은 최신 사용자 인터페이스를 제공하기 위한 통합 플랫폼, 개발자와 디자이너가 공동으로 작업할 수 있는 환경, 그리고 Windows 사용자 인터페이스와 웹 브라우저 사용자 인터페이스를 개발하기 위한 공통의 기술입니다. 이 섹션에서는 이러한 세 가지 특징에 대해 설명합니다.

개발자와 디자이너가 공동으로 작업할 수 있는 환경

모든 기능을 갖춘 사용자 인터페이스를 만들기 위한 통합된 기술 기반을 제공하는 것은 매우 바람직합니다. 그러나 개발자가 외부의 도움 없이 이러한 강력한 기능을 제대로 활용하여 이해하기 쉽고 사용이 편리한 인터페이스를 만들 수 있을 것이라고 기대하는 것은 무리입니다. 특히 앞에서 설명한 병원 사례와 같이 포괄적이고 유용한 사용자 인터페이스를 만들기 위해서는 대부분의 소프트웨어 전문가들이 갖추지 못한 인터페이스 디자인 기술이 필요합니다. 소프트웨어 전문가들이 많은 수의 응용 프로그램을 단독으로 개발하고 있지만 최상의 사용자 인터페이스를 구현하기 위해서는 전문 인터페이스 디자이너의 도움이 필요합니다.

그러나 개발자와 디자이너는 업무 진행 방식이 서로 다르기 때문에 두 분야의 전문가가 공동으로 작업하는 데는 여러 가지 문제가 있습니다. 일반적으로 디자이너는 그래픽 도구를 사용하여 응용 프로그램에 표시할 화면 레이아웃의 정적 이미지를 만듭니다. 그런 다음 이러한 이미지를 개발자에게 전달하고, 개발자는 해당 이미지를 구현하는 코드를 작성합니다. 그러나 디자이너는 만들기 쉽더라도 개발자는 구현하기 어렵거나 전혀 구현할 수 없는 이미지도 있습니다. 예를 들어 개발자는 기술적인 한계, 촉박한 일정, 기술 부족, 사소한 오해 또는 단순한 의견 차이로 인해 디자이너의 의도를 완벽하게 구현하지 못할 수 있습니다. 따라서 최상의 인터페이스를 만들기 위해서는 독립적인 두 분야의 전문가가 인터페이스의 품질을 떨어뜨리지 않으면서 공동으로 작업할 수 있는 환경이 필요합니다.

WPF는 이러한 공동 작업이 가능하도록 XAML(eXtensible Application Markup Language)을 사용합니다. XAML은 사용자 인터페이스의 모양을 정확하게 정의하기 위해 Button, TextBox, Label 등 여러 XML 요소의 집합을 정의합니다. 일반적으로 XAML 요소는 다양한 옵션을 설정할 수 있도록 특성도 포함합니다. 예를 들어 다음의 간단한 XAML 코드는 "아니요"라는 단어가 표시되는 빨간색 단추를 만듭니다.

<Button Background="Red">
 아니요
</Button>

각 XAML 요소는 WPF 클래스에 해당하고 요소의 각 특성은 클래스의 해당 속성이나 이벤트를 갖습니다. 예를 들어 다음과 같은 C# 코드를 사용하여 동일한 빨간색 단추를 만들 수 있습니다.

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "아니요";

XAML로 표현할 수 있는 모든 것을 코드를 사용하여 동일하게 작성할 수 있다면 XAML을 사용할 필요가 없다고 생각할 수도 있습니다. 그러나 XML 기반의 설명을 생성하고 사용하는 작성 도구를 사용하면 코드를 사용하여 동일한 작업을 할 때보다 훨씬 쉽게 작업할 수 있습니다. XAML은 사용이 편리한 도구 방식으로 사용자 인터페이스를 설명하기 때문에 개발자와 디자이너가 더 효율적으로 함께 작업할 수 있습니다. 다음 그림은 이러한 작업 과정을 보여 줍니다.

그림 4. 디자이너와 개발자의 공동 작업을 돕는 XAML

디자이너는 Microsoft Expression Interactive Designer와 같은 도구를 사용하여 사용자 인터페이스의 모양과 상호 작용 방식을 지정할 수 있습니다. 이 도구는 WPF 인터페이스의 모양과 느낌을 정의하는 용도로 사용되며 해당 인터페이스에 대한 설명을 XAML 표현으로 생성합니다. 예제로 사용된 간단한 단추만 포함하더라도 이 설명은 실제로 위에 나온 코드 조각보다 훨씬 복잡합니다. 개발자는 이 XAML 설명을 Microsoft Visual Studio와 같은 도구로 가져옵니다. 이렇게 하면 디자이너가 만든 정적 이미지를 토대로 인터페이스를 처음부터 다시 만들 필요 없이 인터페이스 정의 자체를 그대로 가져올 수 있습니다. 그런 다음 개발자는 이벤트 처리기와 같이 인터페이스에 필요한 코드 및 응용 프로그램에 필요한 기타 기능에 해당하는 코드를 작성합니다. 또한 응용 프로그램 인터페이스에 전체적으로 적용할 수 있는 스타일을 만들 수도 있으며, 이러한 스타일은 나중에 필요에 따라 사용자 지정할 수 있습니다.

디자이너와 개발자가 이러한 방식으로 함께 작업하면 디자이너가 만든 이미지를 토대로 개발자가 인터페이스를 구현할 경우 발생할 수 있는 변환 오류를 줄일 수 있을 뿐만 아니라 이러한 두 분야의 전문가가 반복 작업을 신속하게 수행하고 효과적으로 의견을 교환하면서 동시에 작업을 진행할 수 있습니다. 또한 두 환경 모두에서 동일한 빌드 시스템을 사용하므로 두 개발 환경 간에 WPF 응용 프로그램을 주고 받을 수도 있습니다. 3차원 인터페이스 요소를 만들기 위한 Electric Rain의 ZAM 3D와 같이 XAML로 정의된 인터페이스를 디자인하는 데 사용할 수 있는 특수한 도구도 있습니다.

더 나은 인터페이스를 사용하면 생산성을 높일 수 있을 뿐만 아니라 여러 가지 측면에서 업무상 매우 유용합니다. 그러나 효과적인 인터페이스를 만드는 데는 특히 WPF가 제공하는 다양한 환경의 경우 디자이너의 역할이 가장 중요합니다. XAML 및 XAML을 지원하는 도구의 기본적인 목표는 디자이너의 작업을 돕는 것입니다.

Windows 사용자 인터페이스와 웹 브라우저 사용자 인터페이스를 개발하기 위한 공통의 기술

Windows 응용 프로그램에 사용할 효과적인 사용자 인터페이스를 만드는 것도 중요하지만 웹 기반 응용 프로그램에 사용할 효과적인 인터페이스를 만드는 것도 그만큼 중요합니다. 기본적으로 이러한 인터페이스는 웹 브라우저에서 제공합니다. 인터페이스를 만드는 가장 간단한 방법은 브라우저에 전달되는 모든 HTML을 브라우저가 수동적으로 표시하도록 하는 것입니다. 응답 성능이 더 뛰어난 브라우저 인터페이스에서는 대개 AJAX(Asynchronous JavaScript And XML)를 사용하여 JavaScript로 실행되는 논리를 제공합니다. Adobe Flash Player 또는 몇 가지 다른 기술을 사용하여 애니메이션, 비디오 등을 인터페이스에 사용할 수도 있습니다. 이와 같이 기능이 다양한 인터페이스 유형을 제공하는 웹 소프트웨어를 '다기능 인터넷 응용 프로그램'이라고도 합니다. 이 웹 소프트웨어를 사용하면 사용자 환경을 크게 향상시킬 수 있을 뿐만 아니라 더 많은 사용자의 참여를 유도하는 웹 응용 프로그램을 만들어 상당한 비즈니스 가치를 얻을 수 있습니다.

일반적으로 이러한 유형의 인터페이스를 구현하기 위해서는 기본적인 Windows 인터페이스에 사용되는 것과는 완전히 다른 기술을 사용해야 합니다. 결과적으로 개발자는 서로 다른 두 가지 작업, 즉 Windows 인터페이스를 개발하는 작업 또는 웹 인터페이스 개발하는 작업 중 하나에 초점을 두고 작업해야 합니다. 그러나 Windows에서 액세스할 다기능 인터넷 응용 프로그램을 만드는 데 이러한 양분된 방식으로 작업할 필요는 없으며 기본적인 Windows 인터페이스와 웹 브라우저 인터페이스 모두에 동일한 기술을 사용하지 못할 이유도 없습니다.

WPF를 사용하면 동일한 기술을 사용하여 Windows 인터페이스와 웹 브라우저 인터페이스 모두를 만드는 것이 가능합니다. 개발자는 WPF를 사용하여 Internet Explorer에서 실행되는 XBAP(XAML Browser Application)를 만들 수 있습니다. 실제로 동일한 코드를 사용하여 독립 실행형 WPF 응용 프로그램과 XBAP를 만들 수 있습니다. 예를 들어 아래의 화면에서는 독립 실행형 Windows 응용 프로그램으로 실행되는 재무 서비스 응용 프로그램을 보여 줍니다. 앞에서 설명한 병원 응용 프로그램과 마찬가지로 이 응용 프로그램도 텍스트, 이미지 및 다양한 종류의 그래픽을 함께 사용합니다. 이 화면에서는 시계 등의 가젯 및 응용 프로그램 창 주위에 반투명 테두리를 사용하는 Aero 테마가 적용된 Windows Vista 바탕 화면도 볼 수 있습니다.

그림 5. 재무 서비스 응용 프로그램을 독립 실행형 WPF 응용 프로그램으로 실행할 수 있습니다.

다음 그림에서는 이 인터페이스를 Internet Explorer에서 XBAP로 실행할 때의 모양을 보여 줍니다.

그림 6. 동일한 응용 프로그램을 XBAP로도 실행할 수 있습니다.

이 경우 인터페이스가 자체 창에서 실행되는 대신 브라우저에서 실행된다는 점만 다를 뿐 모든 기능은 동일합니다. 두 경우 모두에 동일한 코드를 사용하면 두 가지 유형의 인터페이스를 개별적으로 만드는 데 소요되는 것보다 작업량을 줄일 수 있습니다. 동일한 코드를 사용한다는 것은 동일한 개발자를 투입할 수 있음을 의미합니다. WPF를 사용하면 개발자를 Windows 인터페이스 개발자 또는 웹 인터페이스 개발자라는 분리된 두 개의 그룹으로 구분할 필요 없이 하나의 개발 리소스를 두 작업 모두에 활용할 수 있습니다.

동일한 기술을 사용하여 Windows 인터페이스와 웹 인터페이스를 만들면 응용 프로그램 작성자가 응용 프로그램의 인터페이스 유형을 미리 결정하지 않아도 된다는 또 하나의 장점이 있습니다. 즉, 대상 클라이언트가 XBAP를 실행하는 데 필요한 요구 사항을 충족하기만 하면 응용 프로그램에서는 거의 동일한 코드를 사용하여 Windows 인터페이스나 웹 인터페이스 또는 두 가지 인터페이스 모두를 제공할 수 있습니다.

XBAP는 필요할 때 웹 서버에서 다운로드되기 때문에 독립 실행형 Windows 응용 프로그램에 비해 더욱 엄격한 보안 요구 사항이 적용됩니다. 이러한 이유로 XBAP는 .NET Framework의 코드 액세스 보안에서 제공하는 보안 샌드박스(Security Sandbox)에서 실행됩니다. 또한 XBAP는 WPF가 설치되어 있는 Windows 시스템에서 Internet Explorer 버전 6 및 7에서만 실행됩니다. 이러한 요구 사항이 충족되면 인터넷 응용 프로그램이 독립 실행형 Windows 응용 프로그램과 동일한 기반을 활용하는 것이 가능합니다.

Windows Presentation Foundation 사용

WPF로 해결할 수 있는 문제점만 알고 있어도 도움이 되지만 WPF가 이러한 문제점을 해결하는 방법을 이해한다면 더 큰 도움이 됩니다. 이 섹션에서는 WPF 기술 자체를 자세하게 살펴본 후 Windows 데스크톱 응용 프로그램, XBAP 및 XPS 문서에 WPF 기술이 적용되는 다양한 방식에 대해 알아봅니다.

Windows Presentation Foundation의 기술

WPF는 사용자 인터페이스를 만들기 위한 통합된 기반을 제공하지만 WPF에 포함된 기술을 문서, 이미지, 그래픽, 애니메이션 등과 같은 개별 단위로 나누어 살펴볼 수 있습니다. 이러한 모든 개별 단위는 다음에 설명할 WPF의 기본 응용 프로그램 모델에 의존합니다.

응용 프로그램 모델

.NET Framework의 다른 구성 요소와 마찬가지로 WPF의 기능은 System.Windows 네임스페이스에 포함된 네임스페이스 그룹으로 나뉩니다. 모든 WPF 응용 프로그램의 기본 구조는 어느 기능을 사용하는지에 관계없이 거의 동일합니다. 일반적으로 응용 프로그램은 독립 실행형 Windows 응용 프로그램이나 XBAP에 관계없이 XAML 페이지 집합과 이들 페이지에 연결된 코드로 구성됩니다.

기본적으로 모든 응용 프로그램은 WPF의 표준 Application 클래스에서 상속됩니다. 이 클래스는 모든 응용 프로그램에서 유용하게 사용할 수 있는 공통 서비스를 제공하며, 여기에는 전체 응용 프로그램에 필요한 상태를 유지하는 서비스 및 응용 프로그램을 시작하는 Run, 응용 프로그램을 종료하는 Shutdown 등의 표준 메서드를 제공하는 서비스가 포함됩니다.

Application 개체는 Application 요소를 통해 XAML을 사용하여 만들거나 Application 클래스를 통해 코드를 사용하여 만들 수 있습니다. 이러한 특징은 사실상 WPF의 모든 요소에 적용되지만 이 문서에서는 간단히 설명하기 위해 XAML을 사용하는 방식만을 소개할 것입니다. 다음은 간단한 XAML을 보여 줍니다.

<Application xmlns=   
    "http://schemas.microsoft.com/winfx/2006/xaml/presentation"
              xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
     StartupUri="Page1.xaml"
     x:Class="Example.SimpleApp">
. . . 
</Application>

이 정의에서는 먼저 WPF 네임스페이스를 이 요소의 기본값으로 지정한 다음 XAML 네임스페이스의 접두사를 정의합니다. XAML은 WPF에만 사용되는 것이 아니므로 이 두 네임스페이스는 서로 다릅니다. 다음으로 StartupUri 특성을 사용하여 응용 프로그램을 시작했을 때 로드하고 표시할 XAML 페이지의 이름을 나타냅니다. 마지막 특성인 Class는 이 Application과 관련된 코드가 들어 있는 클래스를 식별하는 데 사용됩니다. 앞에서 살펴본 것처럼 일반적으로 WPF 응용 프로그램에는 C# 또는 Visual Basic으로 작성된 코드와 XAML이 모두 들어 있으므로 이 클래스의 코드는 '코드 숨김' 파일에 저장됩니다. 여는 Application 태그 다음에는 이 응용 프로그램을 정의하는 데 필요한 나머지 XAML이 위치하고(여기에서는 생략됨), 마지막으로 Application 요소의 닫는 태그가 위치합니다.

모든 WPF 응용 프로그램은 동일한 루트 클래스에서 파생되지만 개발자는 다양한 옵션을 선택할 수 있습니다. 그 중 가장 중요한 옵션은 응용 프로그램에 일반적인 대화 상자 형식의 인터페이스를 사용할지 아니면 탐색 형식의 인터페이스를 사용할지 결정하는 것입니다. 대화 상자 형식의 인터페이스는 Windows 사용자라면 누구나 익숙한 단추 및 기타 요소를 제공합니다. 반면 탐색 형식의 인터페이스는 브라우저와 동작 방식이 거의 유사합니다. 예를 들어 탐색 형식의 인터페이스를 사용하면 대화 상자가 새 창에서 열리는 대신 새 페이지가 로드됩니다. 이와 같은 인터페이스는 페이지 그룹으로 구현되며, 각 페이지는 XAML에 정의된 사용자 인터페이스와 프로그래밍 언어로 표현된 논리로 구성됩니다. HTML로 정의된 브라우저 페이지와 마찬가지로 XAML은 페이지를 서로 연결하는 데 사용할 수 있는 Hyperlink 요소를 제공합니다. 사용자는 웹 기반 응용 프로그램의 페이지를 탐색할 때와 같은 방법으로 기록 목록을 통해 앞으로 또는 뒤로 이동하면서 여러 페이지를 탐색할 수 있습니다. 그러나 이것은 Windows 응용 프로그램이므로 혼동하지 말아야 합니다. 일반적으로 XBAP에서 이러한 유형의 인터페이스를 사용하지만, 필요에 따라 독립 실행형 Windows 응용 프로그램에서도 탐색 형식의 인터페이스를 통해 사용자와 상호 작용할 수 있습니다. 어떤 방식을 사용할지는 응용 프로그램을 만드는 개발자의 선택에 달려 있습니다.

응용 프로그램에서 어떤 인터페이스 스타일을 사용하든지 여부에 관계없이 응용 프로그램은 일반적으로 하나 이상의 창을 표시합니다. WPF는 창을 표시하기 위한 몇 가지 옵션을 제공합니다. 기본 Window 클래스에서는 창을 표시하고 숨기고 닫는 등의 기본적인 창 기능을 제공합니다. 일반적으로 탐색 형식의 인터페이스를 사용하지 않는 WPF 응용 프로그램에서 이 클래스를 사용합니다. NavigationWindow 클래스는 탐색 형식의 인터페이스를 사용하는 응용 프로그램에서 사용하며 기본 Window 클래스에 탐색 기능이 추가됩니다. 추가적인 탐색 기능으로는 응용 프로그램에서 새 페이지로 이동하는 데 사용할 수 있는 Navigate 메서드, 사용자의 탐색 기록을 저장하는 추적 정보 및 다양한 탐색 관련 이벤트가 있습니다.

레이아웃 및 컨트롤

WPF 응용 프로그램에서는 인터페이스의 다양한 요소를 구성하기 위해 '패널'을 사용하여 레이아웃을 지정합니다. 각 패널에는 단추, 텍스트 상자 등의 '컨트롤' 및 다른 패널이 자식 요소로 포함될 수 있습니다. 패널 종류마다 서로 다른 레이아웃 옵션을 제공합니다. 예를 들어, 이름에서 알 수 있듯이 DockPanel을 사용하면 자식 요소를 패널 가장자리에 도킹하여 배치할 수 있고, Grid를 사용하면 자식 요소를 눈금 위에 정확하게 배치할 수 있습니다. 이때 개발자는 눈금의 행 및 열 개수를 정의한 다음 자식 요소를 배치할 정확한 위치를 지정해야 합니다. Canvas를 사용하면 패널 경계 내의 아무 곳에나 자식 요소를 자유롭게 배치할 수 있습니다.

WPF는 다른 사용자 인터페이스 기술과 마찬가지로 다양한 컨트롤 집합을 제공합니다. 개발자는 사용자 지정 컨트롤을 만들 수도 있습니다. 표준 컨트롤 집합에는 Button, Label, TextBox, ListBox, Menu, Slider 및 기타 일반적인 사용자 인터페이스 디자인 요소가 포함됩니다. 또한 SpellCheck, PasswordBox, 잉크(예: Tablet PC)로 작업하는 데 필요한 컨트롤 등 보다 복잡한 컨트롤도 사용할 수 있습니다.

WPF 응용 프로그램에서는 일반적인 그래픽 인터페이스와 마찬가지로 마우스 이동 및 키 누르기 동작과 같이 사용자가 생성하는 이벤트를 컨트롤을 통해 포착하고 처리할 수 있습니다. 컨트롤 및 기타 사용자 인터페이스 요소는 XAML을 사용하여 완벽하게 지정할 수 있지만 이벤트는 코드에서 처리해야 합니다. 예를 들어 다음 XAML에서는 Canvas에 간단한 Button을 정의합니다.

<Canvas xmlns=
   "http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="Example.CodeForCanvas">
  <Button Click="Button_Click">
   여기를 클릭하십시오.
  </Button>
</Canvas>

여는 Canvas 태그는 일반적인 WPF 및 XAML 네임스페이스 정의로 시작됩니다. 다음으로 이 XAML과 관련된 코드를 .NET Framework 네임스페이스 Example에 들어 있는 CodeForCanvas 클래스에서 찾을 수 있음이 지정되고, 그 다음에 "여기를 클릭하십시오."라는 화면 표시 텍스트를 지정하는 Button이 정의됩니다. 여는 Button 태그의 Click 특성은 이 단추의 click 이벤트가 Button_Click이라는 메서드를 사용하여 처리됨을 나타냅니다. 다음은 이 메서드의 코드입니다.

namespace Example {
  public partial class CodeForCanvas : Canvas  {
    void Button_Click(object sender, RoutedEventArgs e)    {
      Button btn = e.Source as Button;
      btn.Background = Brushes.Purple; 
    }
  }
}

네임스페이스 및 클래스의 이름은 위의 Canvas 태그에 지정된 것과 일치합니다. CodeForCanvas 클래스는 WPF에서 제공하는 기본 Canvas 클래스에서 상속되며 partial 클래스로 정의됩니다. Partial 클래스는 .NET Framework 버전 2.0에 새로 추가된 요소로서 개별적으로 정의된 코드를 단일 클래스로 결합하는 데 사용됩니다. 이 경우 XAML로 정의한 Canvas에서 생성되는 partial 클래스와 이 코드의 partial 클래스가 결합됩니다. 그 결과 단추가 포함된 캔버스를 표시하고 해당 단추의 이벤트도 처리할 수 있는 완전한 클래스가 생성됩니다.

이벤트를 처리하는 Button_Click 메서드는 CodeForCanvas 클래스 안에 선언됩니다. 이 메서드는 일반적인 .NET Framework 규칙에 따라 이벤트를 처리하지만 이벤트의 인수는 WPF로 정의된 RoutedEventArgs 클래스를 사용하여 전달됩니다. 이 클래스의 Source 속성은 이벤트를 생성한 Button에 대한 참조를 포함하며 메서드는 이 정보를 사용하여 단추의 색을 보라색으로 변경합니다.

이러한 간단한 예제에서 볼 수 있는 것처럼 WPF 사용자 인터페이스의 요소는 시각적 트리 형식으로 구성됩니다. 이 예제에서는 트리가 Canvas와 유일한 자식 요소인 Button으 로 구성되지만 실제 WPF 응용 프로그램에서는 일반적으로 트리가 훨씬 더 복잡해집니다. 화면 표시 인터페이스를 실제로 만들려면 이 시각적 트리를 렌더링해야 합니다. WPF는 가능한 한 하드웨어 렌더링을 사용함으로써 응용 프로그램의 컴퓨터에 설치되어 있는 그래픽 카드를 통해 작업을 처리합니다. 그러나 컴퓨터의 그래픽 하드웨어로 작업을 처리할 수 없는 경우 WPF는 자체 소프트웨어를 사용하여 인터페이스를 렌더링합니다. 이러한 결정은 런타임에 WPF에서 내리기 때문에 개발자는 별도의 작업을 할 필요가 없습니다.

렌더링을 하드웨어 또는 소프트웨어에서 처리하는지 여부에 관계없이 WPF는 항상 유지 모드 그래픽이라는 방식을 사용합니다. 응용 프로그램 작성자가 일반적으로 XAML과 코드를 조합하여 시각적 트리의 모양을 정의하면 WPF 자체에 이 트리의 정보가 유지됩니다. 예를 들어 사용자가 창을 표시할 경우 응용 프로그램에서 창 전체 또는 일부를 다시 그릴 필요 없이 WPF에서 이 작업을 자체적으로 처리합니다. 트리를 구성하는 요소는 화면에 픽셀로 저장되지 않고 개체로 저장되기 때문에 WPF는 이러한 유형의 렌더링을 처리하는 데 충분한 정보를 항상 유지합니다. 창과 창에 포함된 컨트롤의 크기를 조정하는 경우에도 WPF는 자체적으로 모든 렌더링을 다시 수행할 수 있습니다. WPF는 선, 타원 등의 그래픽 형태를 파악하고 비트맵이 아니라 벡터 그래픽을 사용하기 때문에 이와 같은 충분한 정보를 사용하여 새로운 크기로 인터페이스를 다시 만들 수 있습니다.

스타일 및 서식 파일

몇 가지 사용자 인터페이스 요소의 모양을 한 번 정의한 다음 그 모양을 여러 번 다시 적용하면 편리한 경우가 있습니다. 예를 들어 HTML 페이지에서는 CSS(Cascading Style Sheet)를 사용하여 이러한 작업을 수행할 수 있습니다. WPF에서는 '스타일'이 이와 유사한 기능을 합니다. 이미 널리 사용되고 있는 CSS 스타일시트의 경우에서 볼 수 있듯이 스타일을 정의하는 기능을 매우 유용하게 사용할 수 있습니다. 예를 들어 스타일을 사용하면 디자이너와 개발자의 작업 영역을 보다 명확하게 구분할 수 있기 때문에 디자이너가 인터페이스에 일관된 모양을 만들면 개발자는 이러한 세부 사항에 신경쓰지 않아도 됩니다.

WPF 응용 프로그램 작성자는 XAML의 Style 요소를 사용하여 특정 항목의 모양에 대한 특징을 하나 이상 정의한 후 해당 스타일을 반복적으로 적용할 수 있습니다. 예를 들어 ButtonStyle이라는 스타일을 다음과 같이 정의할 수 있습니다.

<Style x:Key="ButtonStyle">
  <Setter Property="Control.Background" Value="Red"/>
  <Setter Property="Control.FontSize" Value="16"/>
</Style>

이 스타일을 사용하여 정의하는 모든 단추에는 빨간색 배경이 사용되고 글꼴 크기가 16으로 지정됩니다. 예를 들면 다음과 같습니다.

  <Button Style="{StaticResource ButtonStyle}">
   여기를 클릭하십시오.
  </Button>

이 예제에 나와 있는 "StaticResource"의 형태에서 알 수 있듯이 일반적으로 WPF 스타일은 리소스로 정의됩니다. 리소스는 응용 프로그램 코드와는 별도로 정의되는 데이터입니다.

스타일은 이 예제에서 설명한 것보다 훨씬 다양한 기능을 제공합니다. 예를 들어 다른 스타일에서 스타일을 파생시킬 수 있습니다. 이 경우 원래의 설정을 상속하거나 필요에 따라 재정의할 수 있습니다. 스타일을 사용하면 대화형 동작의 일반적인 측면을 지정하는 '트리거'를 정의할 수도 있습니다. 예를 들어 마우스로 단추를 가리키면 단추 배경이 노란색으로 바뀌도록 스타일을 지정할 수 있습니다.

WPF는 '서식 파일' 기능도 지원합니다. 서식 파일은 스타일과 유사하며, 다음과 같은 두 가지 유형으로 나뉩니다.

데이터 서식 파일: XAML의 DataTemplate 요소를 사용하여 데이터 표시 방법에 대한 특성 그룹을 지정할 수 있습니다. 데이터 서식 파일에 색, 정렬 방식 등의 특성을 정의한 후 응용 프로그램의 사용자 인터페이스에 자유롭게 사용할 수 있습니다.
컨트롤 서식 파일: XAML의 ControlTemplate 요소를 사용하여 컨트롤의 모양을 정의할 수 있습니다.

응용 프로그램의 인터페이스 모양을 간단하게 정의할 수 있는 방법을 제공하면 응용 프로그램 작성자가 작업하는 데 큰 도움이 될 수 있습니다. WPF에서는 기본적으로 스타일과 서식 파일을 통해 인터페이스 모양을 보다 쉽게 정의할 수 있습니다.

텍스트

대부분의 사용자 인터페이스에는 적어도 어느 정도의 텍스트가 표시되고, 다른 특성은 거의 없이 텍스트만 표시되는 사용자 인터페이스도 있습니다. 그러나 대다수의 사용자들은 화면에서 텍스트를 읽는 것보다 인쇄된 페이지를 읽는 것을 더 선호합니다. 사람들은 책이나 잡지에서 일반적으로 볼 수 있는 고품질의 문자 모양과 글자에 익숙해져 있기 때문에 화면에 표시되는 텍스트를 읽을 때는 왠지 모르게 불편함을 느끼는 것이 사실입니다.

WPF는 인쇄된 페이지를 읽는 것처럼 화면 표시 텍스트도 편하게 읽을 수 있도록 이러한 차이를 줄이는 것을 목표로 합니다. 이러한 목표의 일환으로 WPF에서는 기존 글꼴 라이브러리를 사용할 수 있도록 산업 표준의 OpenType 글꼴은 물론 최근에 정의된 ClearType 기술도 지원합니다. ClearType은 최신 모니터에서 각 픽셀을 구성하는 하위 요소를 개별적으로 다듬는 기법인 하위 픽셀 위치 조정을 통해 텍스트를 보다 매끄럽게 표시하는 기술입니다. WPF는 또한 Glyphs 클래스를 통한 텍스트 렌더링 기능을 부분적으로 지원합니다. 이 클래스는 XPS 문서에서 문자를 나타내는 데 사용되며, 자세한 내용은 이 문서의 뒷부분에서 설명합니다.

WPF는 가독성을 높이기 위해 문자 그룹을 연결된 단일 이미지로 대체하는 합자 방식도 지원합니다. 예를 들어 "ffi"라는 문자 그룹은 일반적으로 인쇄 페이지에서는 이 세 문자가 들어 있는 연결된 단일 합자로 대체됩니다. 이 합자를 화면 표시 텍스트에 사용하면 사용자는 사용된 세부적인 기술은 눈치채지 못한 채 인쇄된 페이지를 보는 것처럼 텍스트를 편하게 읽을 수 있습니다.

문서

텍스트는 단추, 목록 및 사용자 인터페이스의 다른 여러 요소에 표시되므로 텍스트의 가독성을 높이는 것은 매우 바람직합니다. 그러나 텍스트는 문서에서와 같이 더 긴 단락 형식으로 표시되는 경우에 그 기능이 더 중요합니다. 따라서 화면 표시 가독성을 높이기 위해서는 문서가 표시되는 방법도 함께 개선해야 합니다. 이를 위해 WPF에서는 두 가지 유형의 문서, 즉 '고정' 문서와 '동적' 문서를 지원합니다.

고정 문서는 화면에서 렌더링할 때나 인쇄할 때의 모양이 동일합니다. 일부 양식, 법률 문서, 기타 출판물 유형 등 문서 모양을 항상 일관되게 유지해야 하는 경우에는 고정된 형식의 문서를 사용하는 것이 좋습니다. WPF에서 지원하는 고정된 형식의 문서는 XPS로 정의됩니다. XPS에 대한 자세한 내용은 이 문서의 뒷부분에서 설명합니다. 고정 문서의 내용은 XAML의 FixedDocument 요소를 사용하여 지정할 수 있습니다. 이 간단한 요소에는 PageContent 요소의 목록만 포함되고, 각 PageContent 요소에는 고정 문서에 포함된 각 페이지의 이름이 들어 있습니다. WPF에서는 DocumentViewer 컨트롤을 사용하여 고정 문서를 표시합니다. 이 컨트롤은 XPS 문서를 읽기 전용 모드로 표시하고, 사용자는 문서에서 뒤로 또는 앞으로 이동하거나 특정 텍스트를 검색하는 등의 작업을 할 수 있습니다.

고정 문서가 화면과 인쇄 용지 모두에서 사용할 수 있는 문서 유형이라면 동적 문서는 화면 표시 전용 문서입니다. 동적 문서는 문서 내용의 가독성을 최대한 높이기 위해 창 크기와 기타 요인에 따라 텍스트와 그래픽을 자동으로 조정하여 표시합니다. 고정 문서에 대한 설명을 통해 예상할 수 있듯이 동적 문서는 FlowDocument라는 XAML 요소를 사용하여 정의됩니다. 다음은 간단한 예제입니다.

  <FlowDocument 
    ColumnWidth="300" 
    IsColumnWidthFlexible="True" 
    IsHyphenationEnabled="True">
      <Paragraph FontSize="12">
       <Bold>WPF 설명</Bold>
      </Paragraph>
      <Paragraph FontSize="10">
       WPF는 .NET Framework 3.0을 위한 사용자 인터페이스 
       기술입니다. WPF는 문서, 2차원 및 3차원 그래픽, 미디어 등을 
       지원할 뿐만 아니라 최신 사용자 인터페이스를 만들기 위한 
       통합된 기반을 제공합니다. 또한 동일한 방법과 동일한 코드를 
       사용하여 독립 실행형 Windows 응용 프로그램 및 브라우저 
       내에서 실행되는 응용 프로그램을 만들 수 있도록 
       지원합니다.
      </Paragraph>
  </FlowDocument>

이 문서는 너비가 300이상인 열에 표시되도록 지정됩니다. 이때 너비는 각 픽셀이 1/96인치인 '장치 독립적 픽셀' 단위로 측정됩니다. 그러나 문서 작성자는 바로 다음 줄에 IsColumnWidthFlexible 속성을 true로 설정하여 이 너비를 변경 가능하도록 설정했습니다. 이 설정은 이 문서를 표시하는 데 사용되는 열의 개수와 너비를 WPF에서 변경할 수 있도록 허용합니다. 예를 들어 이 문서가 표시되는 창의 너비를 사용자가 변경하면 WPF에서는 문서의 텍스트를 표시하는 데 사용되는 열의 개수와 너비를 적절하게 늘리거나 줄일 수 있습니다.

다음으로 이 문서에서는 하이픈을 사용하도록 IsHyphenationEnabled 속성이 true로 설정되었습니다. 바로 아래에는 이 문서에 포함된 두 개의 단락이 나옵니다. 각 단락의 텍스트는 글꼴 크기가 서로 다르게 설정된 두 개의 Paragraph 요소 안에 각각 들어 있고 첫 번째 단락의 텍스트는 굵게 표시되도록 설정되었습니다.

WPF에서는 가독성을 높이기 위한 몇 가지 FlowDocument 옵션을 추가적으로 정의합니다. 예를 들어 IsOptimalParagraphEnabled 속성을 true로 설정하면 WPF는 단락 전체에서 공백을 가능한 한 균등하게 사용합니다. 이 속성을 사용하면 가독성을 떨어뜨리는 "연속적인" 공백이 나타나는 것을 방지할 수 있습니다. 이 방법은 인쇄된 문서에 일반적으로 사용됩니다. 동적 문서에는 일반 텍스트나 잉크(Tablet PC에 해당)에 노트를 추가하는 것과 같이 메모를 사용할 수도 있습니다. 각 메모는 문서에서 메모가 연결되어 있는 내용을 식별하는 '앵커(anchor)'와 메모 내용 자체가 들어 있는 '카고(cargo)'로 구성됩니다.

WPF에서는 다음과 같은 몇 가지 컨트롤을 사용하여 FlowDocument를 표시할 수 있습니다.

FlowDocumentPageViewer: 문서에서 한 번에 한 페이지씩 이동할 수 있습니다. 이 컨트롤은 앞으로/뒤로 단추 및 문서 크기를 조정하는 데 사용할 수 있는 확대/축소 컨트롤을 제공합니다.
FlowDocumentScrollViewer: 페이지 오른쪽에 있는 스크롤 막대를 사용하여 문서를 스크롤하는 일반적인 보기 형식으로 FlowDocument를 표시합니다.
FlowDocumentReader: FlowDocumentPageViewer와 FlowDocumentScrollViewer의 기능을 결합한 형식으로 문서를 표시합니다. 이 컨트롤을 사용하면 사용자가 동적 문서의 페이지 단위 보기(두 페이지씩 보기 포함)와 스크롤 보기 사이를 전환할 수 있습니다.

디지털 방식으로 전달되는 정보가 증가함에 따라 화면 표시 가독성도 점차 그 중요성이 높아지고 있습니다. WPF는 동적 문서를 통해 정보를 보다 효과적으로 표시함으로써 더욱 편리한 Windows 사용자 환경을 제공합니다.

이미지

회사 로고, 노을 사진 등 이미지는 많은 사용자 인터페이스의 기본 요소입니다. WPF에서 이미지는 일반적으로 Image 컨트롤을 사용하여 표시됩니다. 예를 들어 JPEG 파일을 표시하려면 다음과 같은 XAML을 사용할 수 있습니다.

<Image 
 Width="200" 
 Source="C:\Documents and Settings\All Users\Documents\
  My Pictures\Ava.jpg" />

이 예제에서는 이미지 너비를 200으로 설정합니다. 이 경우에도 장치 독립적 픽셀 단위가 사용됩니다. Source 특성은 이미지가 들어 있는 파일을 식별합니다.

이미지 파일에는 키워드, 사용자가 지정한 등급 등 이미지에 대한 정보를 나타내는 메타데이터가 들어 있으며 WPF 응용 프로그램에서는 이 정보를 읽고 기록할 수 있습니다. 회전하는 3차원 개체에 그림을 그리는 것처럼 더 재미있는 방법으로 이미지를 사용할 수도 있습니다. 이 문서에 포함된 간단한 예제에서는 가장 일반적인 이미지 사용 방법을 보여 주지만 WPF에서 이미지를 사용하는 방법은 이보다 훨씬 다양합니다.

WPF의 Image 컨트롤은 JPEG, BMP, TIFF, GIF, PNG 등의 다양한 형식뿐만 아니라 Windows Vista에 새롭게 추가된 Microsoft Windows Media Photo(WMPhoto) 형식의 이미지도 표시할 수 있습니다. 이미지 형식에 관계없이 WPF는 WIC(Windows Imaging Component)를 사용하여 이미지를 생성합니다. WIC는 위에서 언급한 모든 이미지 형식에 대한 코더/디코더(일반적으로 '코덱'이라고 함)뿐만 아니라 타사 코덱을 추가할 수 있는 프레임워크도 제공합니다.

비디오 및 오디오

네트워크 및 프로세서 속도가 빨라짐에 따라 비디오는 사용자가 소프트웨어와 상호 작용하는 방식에서 중요한 부분을 차지하게 되었습니다. 또한 사용자들은 컴퓨터에서 음악이나 기타 오디오를 듣는 데 많은 시간을 보내기도 합니다. 이러한 요구에 부응하기 위해 WPF는 비디오 및 오디오 기능을 기본적으로 제공합니다.

비디오 및 오디오 기능은 MediaElement 컨트롤을 통해 제공됩니다. 다음은 이 컨트롤을 사용하는 간단한 XAML 예제입니다.

<MediaElement 
 Source="C:\Documents and Settings\All Users\Documents\
  My Videos\Ruby.wmv" />

이 컨트롤은 WMV, MPEG 및 AVI 비디오와 다양한 형식의 오디오를 재생할 수 있습니다.

2차원 그래픽

지난 20년 동안 Windows용 2차원 그래픽 작성자들은 GDI(Graphics Device Interface)와 그 후속 버전인 GDI+를 사용해왔습니다. 그러나 2차원 그래픽은 사용자 인터페이스 기술에 통합되어 있지 않기 때문에 Windows Forms 응용 프로그램에서도 별도의 네임스페이스를 통해 이 기능에 액세스해야 합니다. 3차원 그래픽의 경우에는 완전히 다른 기술인 Direct3D를 사용해야 하기 때문에 작업이 더 번거로웠습니다. 그러나 WPF를 사용하면 대부분의 응용 프로그램에서 이러한 복잡한 작업 과정을 단순화할 수 있습니다. 즉, 2차원 그래픽과 3차원 그래픽 모두를 XAML에서 직접 만들거나 WPF 라이브러리를 사용하여 프로시저 코드에서 만들 수 있습니다. 이러한 작업에 사용되는 요소는 WPF의 다른 모든 요소와 마찬가지로 응용 프로그램의 시각적 트리의 일부입니다.

2D 그래픽의 경우 WPF는 응용 프로그램에서 이미지를 만드는 데 사용할 수 있도록 다음과 같은 '모양' 그룹을 정의합니다

Line: 두 지점 사이에 직선을 그립니다.
Elllipse: 타원을 그립니다.
Rectangle: 사각형을 그립니다.
Polygon: 서로 연결된 직선의 그룹으로 정의되는 닫힌 모양을 그립니다.
Polyline: 서로 연결된 직선의 그룹으로 정의되는 열린 모양을 그립니다.
Path: 임의의 경로로 표시되는 모양을 그립니다. 열린 모양이나 닫힌 모양을 사용할 수 있으며 경로에는 직선이나 곡선을 사용할 수 있습니다. Path를 사용하면 실제로 선, 타원, 사각형, 다각형, 다중선 등을 모두 그릴 수 있기 때문에 다른 모든 모양은 편의를 위해서만 제공됩니다.

이 클래스를 사용하면 간단한 그래픽을 쉽게 만들 수 있습니다. 예를 들어 다음 XAML은 빨간색 타원을 그립니다.

<Ellipse Width="30" Height="10" Fill="Red" />

모양을 채우려면 '브러시'를 사용합니다. 위의 예제에서는 기본값인 단색 브러시를 사용하지만 WPF에서는 몇 가지 다른 옵션도 제공합니다. 예를 들어 다음 예제에서는 가로 방향으로 빨간색에서 노란색으로 바뀌는 색 그라데이션으로 채워진 사각형을 정의합니다.

<Rectangle Width="30" Height="10" 
 Fill="HorizontalGradient Red Yellow" />

이 외에도 이미지, 비트맵 등을 사용하여 그리는 브러시, 수직 그라데이션 및 방사형 그라데이션을 비롯하여 여러 가지 다른 브러시를 사용할 수 있습니다. 이 문서에서 다루지는 않지만 모양에 '펜'을 사용하여 윤곽선의 색, 너비 및 스타일을 지정할 수도 있습니다.

WPF에서는 모든 요소가 공통의 기반에서 구현되므로 서로 다른 요소를 간단하게 결합할 수 있다는 점을 기억해 두십시오. 예를 들어 응용 프로그램에서는 Rectangle 안에 Image를 표시하고, Button 안에 Ellipse를 배치하는 등 다양한 방법으로 요소를 결합할 수 있습니다. 따라서 2D 그래픽을 3D 그래픽 및 다른 인터페이스 요소에 결합하는 것 역시 매우 간단합니다.

WPF는 모양 외에도 2차원 그래픽 작업에 사용할 수 있는 다른 클래스 그룹도 제공합니다. '기하 도형'이라고 하는 이러한 클래스는 모양과 여러모로 비슷합니다. Line, Rectangle, Ellipse 및 Path 같은 옵션을 제공하는 모양과 마찬가지로 이 클래스도 LineGeometry, RectangleGeometry, EllipseGeometry 및 PathGeometry 같은 옵션을 제공합니다. 일반적으로 모양은 실제 이미지를 그리는 데 사용되고 기하 도형은 주로 영역을 정의하는 데 사용된다는 것이 이 두 클래스 간의 가장 중요한 차이점입니다. 예를 들어 정사각형 이미지를 원 안에 맞추기 위해 잘라야 할 경우 EllipseGeometry 클래스를 사용하여 원의 경계를 지정할 수 있습니다. 마찬가지로 응용 프로그램에서 마우스 클릭이 감지된 영역과 같이 적중 테스트 영역을 정의해야 하는 경우에는 해당 영역에 기하 도형을 지정하면 됩니다.

이 섹션에서 설명한 모든 내용은 실제로 '시각적 레이어'라는 하위 수준의 인터페이스를 기반으로 구현된다는 점을 알아야 합니다. 이 레이어를 직접 사용하여 그래픽, 이미지 및 텍스트를 만들 수도 있습니다. 간단한 고성능 그래픽을 만들 때와 같이 레이어를 직접 사용하는 방법이 유용할 때도 있지만 대부분의 응용 프로그램에서는 WPF가 제공하는 모양 및 다른 상위 수준의 추상화를 사용합니다.

3차원 그래픽

2차원 그래픽은 Windows 인터페이스의 일반적인 요소이기 때문에 WPF에서는 2차원 그래픽과 관련된 다양한 기술을 제공합니다. 반면, 3차원 그래픽은 뛰어난 데이터 시각화, 3D 차트, 제품 렌더링 등의 다양한 기능을 통해 상당한 가치를 제공할 수 있음에도 불구하고 아직까지는 2차원 그래픽만큼 일반화되지 않았습니다. 이전에는 3D로 작업하기 위해 주로 게임 개발자나 기타 전문 집단에서만 사용하는 고유한 기술을 사용해야 했습니다. 그러나 WPF는 3D 그래픽 기능을 표준 환경에 통합함으로써 이전과는 다른 새로운 작업 환경을 제공합니다.

WPF가 없는 경우 Windows 플랫폼에서는 Direct3D API를 사용하여 3D를 개발해야 합니다. WPF의 다른 요소와 마찬가지로 WPF의 3D 그래픽 기능은 기본적으로 Direct3D에 기반을 두고 있지만 개발자의 실제 작업 환경은 훨씬 단순해졌습니다. 이 문서의 뒷부분에서 설명하는 것처럼 WPF보다는 Direct3D를 사용하는 것이 더 적합한 경우도 있지만, Microsoft의 목표는 Windows 인터페이스에 사용할 대부분의 3D 작업에 WPF를 사용하도록 하는 것입니다.

WPF에서는 응용 프로그램에 Viewport3D 컨트롤을 사용하여 3D 그래픽을 표시합니다. 이 컨트롤은 기본적으로 응용 프로그램에서 나타내는 3차원 공간에 창을 제공합니다. Viewport3D 컨트롤은 WPF 인터페이스의 아무 곳에나 사용할 수 있기 때문에 3D 그래픽을 원하는 위치에 표시하는 것이 가능합니다.

3D 그래픽을 만들 경우 개발자는 하나 이상의 '모델'을 정의한 다음, 이러한 모델에 적용할 조명과 보기 방식을 지정합니다. 이 경우에도 XAML이나 코드 또는 두 방법을 함께 사용하여 모든 옵션을 지정할 수 있습니다. WPF에서는 모델의 모양을 정의할 수 있는 GeometryModel3D 클래스를 사용하여 모델을 정의합니다. 모델을 정의한 후에는 다양한 종류의 '재질'을 사용하여 모델의 모양을 제어할 수 있습니다. 예를 들어 SpecularMaterial 클래스는 표면에 광택 효과를 적용하지만 DiffuseMaterial 클래스는 이 효과를 적용하지 않습니다.

사용한 재질에 관계없이 다양한 방법으로 모델에 조명 효과를 적용할 수 있습니다. DirectionalLight 클래스는 특정 방향의 광원을 제공하고 AmbientLight 클래스는 전체적으로 균일한 조명을 제공합니다. 마지막으로 모델을 보는 방식을 정의하는 '카메라'를 지정합니다. 예를 들어 PerspectiveCamera를 사용하면 모델을 보는 거리와 원근감을 지정할 수 있고, OrthographicCamera를 사용하면 원근감만 제외하고 동일한 옵션을 지정할 수 있습니다. 즉, 이 경우에는 카메라에서 멀리 떨어진 개체도 더 작게 표시되지 않습니다.

XAML 또는 코드에서 직접 복잡한 3D 화면을 만드는 것은 쉽지 않습니다. 3D를 사용하는 대부분의 WPF 응용 프로그램에서 개발자는 그래픽 도구를 사용하여 필요한 정의를 생성하는 경우가 많습니다. 어떤 방법을 사용하든지 표준 사용자 인터페이스에 3D 그래픽을 사용하면 사용자에게 표시되는 화면의 품질을 크게 향상시킬 수 있습니다.

변환 및 효과

WPF에서는 개발자가 모양 및 기타 요소를 정의할 수 있을 뿐만 아니라 회전, 크기 변경 등의 작업을 통해 요소를 변환할 수도 있습니다. XAML에서는 RotateTransform 및 ScaleTransform 같은 요소를 사용하여 이러한 작업을 할 수 있습니다. 이러한 변환은 모든 사용자 인터페이스 요소에 적용할 수 있습니다. 다음은 변환 작업을 보여 주는 간단한 예제입니다.

</Button>
  <Button Content="여기를 클릭하십시오.">
   <Button.RenderTransform>
    <RotateTransform Angle="45" />
   </Button.RenderTransform>
  </Button>

RotateTransform 요소는 단추를 45도 회전시킵니다. 이 방법으로 단추를 회전시키는 것은 그다지 유용하지 않지만 이러한 기능이 있다는 것만으로 WPF 디자인의 다양성을 짐작할 수 있습니다. 사용자 인터페이스의 여러 요소는 동일한 기술에 기반을 두고 있기 때문에 여러 가지 방법으로 결합될 수 있습니다.

WPF는 몇 가지 미리 정의된 효과를 제공합니다. 변환과 마찬가지로 이러한 효과도 Buttons, ComboBoxes 등 사용자 인터페이스의 다양한 요소에 적용할 수 있습니다. 미리 정의된 효과로는 인터페이스 요소를 흐릿하게 표시하는 흐리게 효과, 요소를 빛나게 만드는 외부 글로우 효과, 인터페이스 요소 뒤에 그림자를 추가하는 그림자 효과 등이 있습니다.

애니메이션

인터페이스의 요소를 움직이게 만드는 애니메이션을 사용하면 여러 가지로 매우 유용합니다. 예를 들어 단추를 클릭할 때 단추가 실제로 눌린 것처럼 아래로 내려갔다가 다시 올라오면 훨씬 실감나는 인터페이스를 연출할 수 있습니다. 이보다 복잡한 애니메이션을 사용하여 사용자의 주의를 끌거나 이야기를 들려주는 방법으로 사용자의 참여를 유도하는 인터페이스를 만들 수 있습니다. WPF의 애니메이션 기능은 이러한 모든 효과를 지원합니다.

변환과 마찬가지로 애니메이션을 단추, 모양, 이미지 등 사용자 인터페이스의 다양한 요소에 적용할 수 있습니다. 애니메이션은 시간 흐름에 따라 개체의 속성 중 하나 이상의 속성 값을 변경하여 만듭니다. 예를 들어 Ellipse의 Height 속성 값을 2초 동안 조금씩 줄이면 타원이 천천히 찌그러지는 것처럼 보일 수 있습니다.

서로 관련된 애니메이션 그룹을 정의하면 유용할 수 있습니다. WPF에서 제공하는 Storyboard 클래스를 사용하면 이러한 작업을 할 수 있습니다. 각 Storyboard는 하나 이상의 '시간 표시 막대'를 포함할 수 있고, 각 시간 표시 막대는 하나 이상의 애니메이션을 포함할 수 있습니다. 제공되는 다양한 시간 표시 막대를 사용하면 애니메이션을 순차적으로 실행하거나 병렬로 실행할 수 있습니다. 다음은 Ellipse를 찌그러뜨리는 애니메이션을 보여 주는 간단한 XAML 예제입니다.

    <Ellipse Width="100" Height="50" Fill="Blue"
     Name="EllipseForSquashing">
     . . . 
     <Storyboard>
      <DoubleAnimation
       Storyboard.TargetName="EllipseForSquashing" 
       Storyboard.TargetProperty="Height"
        From="50" To="25" Duration="0:0:2" />
       </Storyboard>
       . . . 
    </Ellipse>

앞에서 살펴본 예제에서와 마찬가지로 이 예제 역시 먼저 Ellipse를 정의합니다. 이 예제에서는 Name 속성도 함께 사용하여, 나중에 이 이름으로 Ellipse를 참조할 수 있도록 했습니다. 이 예제에는 몇 가지 세부 사항이 생략되었지만 XAML로 애니메이션을 정의하려면 Storyboard 요소가 반드시 있어야 합니다. 이 경우에는 Ellipse의 Height 속성이 Double 형식이기 때문에 Storyboard에 DoubleAnimation 요소가 들어 있습니다. 이 요소는 애니메이션을 만들 Ellipse의 이름, 변경할 속성 및 변경할 내용을 지정합니다. 이 예제에서는 Height의 값을 2초 동안 50에서 25로 변경합니다.

이 예제보다 훨씬 복잡한 애니메이션을 만들 수 있습니다. 예를 들어 애니메이션을 마우스 클릭 같은 이벤트를 통해 트리거하거나, 일시 중지했다가 다시 재생하거나, 지정한 횟수만큼(또는 계속) 반복하는 등 복잡한 애니메이션도 만들 수 있습니다. 애니메이션을 통해 개발자는 더 실감나고 사용하기 쉬우면서 보다 많은 기능을 제공하는 사용자 인터페이스를 만들 수 있습니다.

데이터 바인딩

대부분의 사용자 인터페이스는 특정한 유형의 데이터를 표시합니다. 인터페이스 개발자는 데이터 바인딩을 통해 데이터를 더 쉽게 표시할 수 있습니다. 데이터 바인딩을 사용하면 WPF 컨트롤에 표시되는 요소를 해당 컨트롤 외부에 있는 데이터와 직접 연결할 수 있습니다. 예를 들어 WPF TextBox 컨트롤의 Text 속성 값을 이 응용 프로그램의 비즈니스 논리의 일부인 Employee 개체의 Name 속성에 바인딩할 수 있습니다. 두 속성 중 하나가 변경되면 바인딩된 다른 한 속성에 해당 변경 내용이 반영됩니다. 예를 들어 사용자가 TextBox에서 값을 변경하면 Employee 개체의 Name 속성에도 변경된 값이 적용되고, 그 반대의 경우도 마찬가지로 적용됩니다.

두 개체의 속성 간에 이러한 연결을 만들려면 WPF Binding 클래스를 사용해야 합니다. 다음은 이러한 바인딩을 보여 주는 간단한 XAML 예제입니다.

<TextBox . . . >
 <TextBox.Text>
  <Binding Path="Name" />
 </TextBox.Text>
</TextBox>

이 예제에서는 Binding 요소의 Path 특성을 사용하여 TextBox의 Text 속성을 바인딩할 대상 속성을 식별합니다. Path는 이 속성이 속해 있는 개체(런타임에 지정됨)가 C# 또는 Visual Basic 등의 언어로 정의된 CLR(공용 언어 런타임) 개체인 경우에 사용됩니다. WPF의 데이터 바인딩 기능을 사용하면 CLR 개체는 물론 Binding의 XPath 속성을 사용하여 XML 데이터에 직접 연결할 수도 있습니다. 이 옵션은 지정한 데이터를 참조하는 XML 문서에서 하나 이상의 노드를 선택하는 XPath 쿼리를 만듭니다.

더 복잡한 데이터 바인딩 옵션을 사용할 수도 있습니다. 예를 들어 목록 바인딩을 사용하면 표준 IEnumerable 인터페이스를 구현하는 CLR 개체를 통해 ListBox 컨트롤에 내용을 채울 수 있습니다. 필요한 경우 데이터를 표시하기 전에 필터링 또는 정렬을 적용할 수도 있습니다. WPF에서는 ADO.NET Dataset에 바인딩할 수 있지만 관계형 데이터베이스 관리 시스템의 데이터에 직접 바인딩하는 기능은 지원하지 않습니다. 어떤 데이터 바인딩 옵션을 사용하는지에 관계없이 기본적으로 데이터 바인딩은 최대한 간단하게 사용자 인터페이스에 데이터를 표시하는 데 필요한 기능입니다.

사용자 인터페이스 자동화

WPF 인터페이스의 가장 일반적인 사용자는 당연히 사람입니다. 그러나 사용자 인터페이스를 작동하는 주체가 사람이 아니라 다른 소프트웨어인 경우도 있습니다. WPF의 UI(사용자 인터페이스) 자동화를 사용하면 이러한 방식으로 인터페이스를 작동할 수 있습니다.

예를 들어 개발자가 인터페이스를 실행하는 자동화된 스크립트를 만들어야 한다고 가정해 보겠습니다. 이 경우 개발자는 UI 자동화 기능이 제공하는 프로그래밍 방식의 액세스를 통해 사람이 실행하는 것처럼 인터페이스를 작동시키는 스크립트를 만들 수 있습니다. UI 자동화는 인터페이스의 다양한 요소를 음성으로 읽어 주는 도구와 같은 내게 필요한 옵션 도구를 만드는 데도 유용합니다. UI 자동화를 사용하면 이러한 요소가 들어 있는 트리에서 각 요소를 프로그래밍 방식으로 하나씩 실행할 수 있기 때문에 이러한 종류의 도구를 만들 수 있는 것입니다.

WPF에서는 UI 자동화를 사용하기 위해 UI 자동화 트리를 만듭니다. 이 트리는 인터페이스의 각 요소를 나타내는 일련의 AutomationElement 개체로 구성됩니다. 이 트리의 루트는 Desktop이고, 열려 있는 각 응용 프로그램은 이 루트의 자식이 됩니다. 트리는 각 응용 프로그램으로 세분화되고 각 WPF 컨트롤은 AutomationElement 개체 하나로 표시되거나, 경우에 따라 둘 이상의 개체로 표시됩니다. 이 경우 프로그래밍 방식으로 인터페이스에 액세스할 수 있도록 사용자가 상호 작용할 수 있는 모든 요소가 고유한 AutomationElement로 나타납니다. 예를 들어 단추가 여러 개 포함된 컨트롤에는 컨트롤 자체와 각각 고유한 AutomationElement 개체로 표시되는 단추가 모두 있습니다. 이와 같이 세분화된 UI 자동화 트리를 만들면 테스트 스크립트, 내게 필요한 옵션 도구 등의 클라이언트 응용 프로그램이 인터페이스의 각 구성 요소를 사람이 실제 사용하는 것처럼 액세스할 수 있습니다.

UI 자동화가 WPF의 핵심적인 기능은 아니며 대다수의 일반 사용자들은 이 기능을 거의 사용하지 않을 수도 있습니다. 그러나 소프트웨어 테스트 담당자나 움직임이 불편한 사용자와 같이 이를 필요로 하는 사용자들에게는 '없어서는 안 될' 중요한 기능입니다. 다수의 사용자들이 사용하는 기능만 중요한 것은 아닙니다.

Windows Presentation Foundation 적용

WPF에는 방대한 양의 기술이 포함되어 있습니다. 이러한 모든 기술이 사용자와의 상호 작용과 관련이 있지만 가장 많이 적용되는 세 가지 영역으로는 독립 실행형 WPF 응용 프로그램, XBAP 및 XPS 문서가 있습니다. 이 섹션에서는 이 세 가지 영역을 자세하게 살펴봅니다.

독립 실행형 WPF 응용 프로그램

WPF를 사용하는 가장 일반적인 방법은 독립 실행형 응용 프로그램에 사용하는 것입니다. 독립 실행형 WPF 응용 프로그램은 다른 일반적인 Windows 응용 프로그램처럼 실행되며 웹 브라우저를 사용하지 않습니다. 이러한 이유로 독립 실행형 응용 프로그램에는 완전한 신뢰 수준이 부여되고 WPF의 모든 기능을 사용할 수 있습니다. 완전 신뢰란 독립 실행형 WPF 응용 프로그램이 컴퓨터에 설치되어 있는 WCF(Windows Communication Foundation) 등의 다른 서비스를 자유롭게 사용할 수 있음을 의미합니다.

다른 Windows 응용 프로그램과 마찬가지로 독립 실행형 WPF 응용 프로그램을 로컬 디스크 또는 네트워크 서버에서 설치할 수 있으며 .NET Framework의 기능인 ClickOnce를 사용하여 설치할 수도 있습니다. ClickOnce는 사용자가 Internet Explorer를 통해 Windows 응용 프로그램(WPF 응용 프로그램 포함)을 다운로드하여 설치한 후 해당 응용 프로그램의 업데이트가 릴리스될 때 이를 자동으로 설치할 수 있게 해 주는 간단한 방법을 제공합니다.

XAML 브라우저 응용 프로그램: XBAP

독립 실행형 WPF 응용 프로그램이 대부분의 기능을 제공하지만 모든 경우에 적합한 것은 아닙니다. 클라이언트를 Windows 응용 프로그램으로 실행하는 것보다 웹 브라우저에서 실행하는 것이 더 적절한 경우도 많이 있습니다. WPF는 이러한 클라이언트에서도 최신 사용자 인터페이스를 사용할 수 있도록 XBAP를 제공합니다.

다음 그림에서 볼 수 있는 것처럼 XBAP는 Internet Explorer에서 실행됩니다. XBAP는 ASP.NET, JSP(JavaServer Pages) 및 기타 웹 기술을 사용하여 만든 웹 응용 프로그램의 클라이언트로 동작합니다. XBAP는 HTTP 또는 SOAP를 사용하여 이러한 웹 응용 프로그램과 통신할 수 있습니다. XBAP는 서버 플랫폼에 관계없이 항상 ClickOnce를 통해 로드되며 이 과정에서 사용자에게 대화 상자나 메시지를 전혀 표시하지 않고 일반적인 웹 페이지처럼 로드됩니다. 이러한 이유로 XBAP는 시작 메뉴나 프로그램 추가/제거에 표시되지 않습니다.

그림 7. Internet Explorer에서 실행되는 XBAP

일반적으로 XBAP는 탐색 형식의 인터페이스를 제공하지만 이는 선택 사항입니다. 탐색 형식의 인터페이스를 사용하면 사용자에게 익숙한 기존의 웹 클라이언트처럼 응용 프로그램을 실행할 수 있습니다. Internet Explorer 7에서는 XBAP가 브라우저의 기본 앞으로/뒤로 단추를 사용하고, 사용자가 액세스하는 XAML 페이지는 브라우저의 기록 목록에 나타납니다. 그러나 Internet Explorer 6에서는 XBAP가 자체적인 앞으로/뒤로 단추와 별도의 기록 목록을 사용합니다. XBAP는 현재의 실행 환경을 자동으로 파악하여 적절한 방식으로 동작하기 때문에 개발자는 개별 브라우저별로 버전을 만들지 않아도 됩니다.

XBAP는 웹에서 로드되어 브라우저에서 실행되기 때문에 .NET Framework의 코드 액세스 보안 기능이 부여하는 제한된 신뢰 수준에서만 실행됩니다. 이러한 이유 때문에 독립 실행형 WPF 응용 프로그램에서 사용할 수 있는 기능 중 일부를 XBAP에서는 사용하지 못할 수 있습니다. 예를 들어 인터넷 영역에서 배포된 XBAP에서는 다음과 같은 기능을 사용할 수 없습니다.

독립 실행형 창 만들기
응용 프로그램에서 정의한 대화 상자 표시
XBAP 자체에서 시작한 저장 대화 상자 표시
제한적으로 사용할 수 있는 격리된 저장소 영역 이외의 파일 시스템에 액세스
UI 자동화 클라이언트로 동작
WCF 사용. WCF 응용 프로그램을 사용하려면 완전 신뢰 수준이 필요하기 때문에 인터넷에서 배포된 XBAP는 이 응용 프로그램을 사용할 수 없습니다. 대신에 ASMX라고 하는 ASP.NET 웹 서비스를 사용하여 원래 로드된 위치의 웹 응용 프로그램과 통신할 수 있습니다.
Windows Forms, MFC(Microsoft Foundation Class) 또는 Win32 직접 호출을 통해 만든 사용자 인터페이스 코드 사용. 다음 섹션에서 설명하는 것처럼 독립 실행형 WPF 응용 프로그램은 이러한 모든 이전 기술과 상호 운용될 수 있지만 신뢰 수준이 제한된 XBAP 환경에서는 여기에 나열된 기술 중 어떤 것도 사용할 수 없습니다.
비관리 코드 사용

앞에서 살펴본 것처럼 독립 실행형 WPF 응용 프로그램 및 XBAP 모두에 동일한 코드 베이스를 사용할 수 있습니다. 이를 위해 개발자는 XBAP에서 사용할 수 없는 모든 기능을 ifdef에 래핑하여 조건부 컴파일을 사용할 수 있습니다. XBAP 버전에서는 문서 표시, 2차원 및 3차원 그래픽 사용, 비디오와 오디오 재생 등 독립 실행형 응용 프로그램 버전에서 사용할 수 있는 대부분의 기능을 동일하게 수행할 수 있을 뿐만 아니라 XBAP가 실행되고 있는 컴퓨터의 그래픽 하드웨어를 활용할 수도 있습니다.

Internet Explorer에는 XBAP뿐만 아니라 순수 XAML 페이지도 직접 표시할 수 있습니다. 'XAML 사용 완화'라고 하는 이러한 페이지는 브라우저에 정적 페이지를 표시할 때 유용합니다. 그러나 이벤트를 처리하려면 코드를 사용해야 하므로 결과적으로 XBAP를 만들어야 합니다.

개발자는 XBAP를 사용하여 브라우저 응용 프로그램에서 WPF 기능의 대부분을 사용할 수 있습니다. 또한 XBAP를 사용하면 독립 실행형 응용 프로그램과 브라우저 응용 프로그램에 코드가 거의 유사한 공통적인 프로그래밍 모델을 사용할 수 있습니다. 해당 클라이언트가 최신 Windows 플랫폼에서 실행되도록 디자인된 웹 응용 프로그램의 경우에는 XBAP를 사용하는 것이 좋습니다.

XPS 문서

XPS 문서는 WPF 환경에 사용되는 고정된 형식의 문서로, 사용자 인터페이스에서 매우 중요한 역할을 합니다. 앞에서 살펴본 것처럼 WPF는 DocumentViewer 컨트롤을 사용하여 XPS 문서를 표시합니다. 이 컨트롤을 WPF에 포함해야 하는 이유는 쉽게 이해할 수 있지만 XPS 자체를 WPF의 일부로 간주해야 하는 이유는 납득하기 어렵습니다. 실제로 XPS 사양에는 고정된 형식의 문서를 정의하기 위한 상당히 구체적인 방법이 명시되어 있으며, 이러한 문서는 다양한 방법으로 사용될 수 있습니다. 반면, WPF의 다른 모든 기능은 사용자 인터페이스를 만드는 데만 초점이 맞춰져 있습니다. 이와 같은 특징을 고려할 때 사용 범위가 더 넓은 XPS를 WPF라는 틀 안에 포함하는 것에 의문이 생길 수 있습니다.

XPS를 WPF의 일부로 보는 한 가지 중요한 이유는 XPS 문서가 XAML을 사용하여 정의된다는 점입니다. 레이아웃을 지정하는 Canvas 요소, 텍스트를 나타내는 Glyphs 요소, 2차원 그래픽을 만드는 Path 요소 등을 포함하여 XAML의 일부만 제한적으로 사용되지만 사실상 모든 XPS 문서는 XAML 문서입니다. 이 점을 고려하면 XPS를 WPF의 일부로 볼 수도 있습니다.

그러나 화면 표시 사용자 인터페이스는 XPS가 제공하는 핵심적인 기능과는 여전히 거리가 멉니다. Windows Vista부터는 XPS가 Windows의 기본 인쇄 형식으로 사용됩니다. XPS는 페이지 설명 언어로 사용되기 때문에 XPS를 지원하는 프린터에서 XPS 문서를 직접 렌더링할 수 있습니다. 따라서 화면 작업에서 프린터 작업에 이르는 모든 과정에서 XAML이라는 단일 설명 형식을 사용할 수 있습니다. 또한 XPS는 Windows에서 사용하던 기존의 GDI 기반 인쇄 방식을 향상시키므로 투명도 및 그라데이션과 같은 고급 그래픽 효과를 보다 정확하게 인쇄할 수 있습니다.

XPS 문서에는 XAML을 비롯하여 다양한 형식의 이미지(JPEG, PNG, TIFF 및 WMPhoto), 글꼴 데이터, 문서 구조에 대한 정보 등의 이진 데이터가 포함될 수 있습니다. 또한 필요한 경우 W3C XML 서명 정의 및 X.509 인증서를 사용하여 XPS 문서에 디지털 서명을 추가할 수도 있습니다. 모든 XSP 문서는 어떤 정보를 포함하는지에 관계없이 OPC(Open Packaging Convention)에서 정의하는 형식으로 저장됩니다. OPC는 XPS나 XAML 문서뿐만 아니라 XML 문서를 구성하는 여러 요소 간의 관계 및 이들 요소가 표준 ZIP 형식으로 저장되는 방법 등을 지정합니다. Microsoft Office 2007에서는 XML 형식에도 OPC를 사용하기 때문에 이 두 가지 형식의 문서 간에는 어느 정도의 공통점이 존재합니다.

앞에서 설명했듯이 WPF 응용 프로그램 사용자는 WPF DocumentViewer 컨트롤을 통해 XPS 문서를 볼 수 있습니다. Microsoft에서는 다음 그림에서 볼 수 있는 것처럼 DocumentViewer 컨트롤을 기반으로 하는 XPS 뷰어 응용 프로그램도 제공합니다. 이 응용 프로그램을 사용하면 컨트롤과 마찬가지로 문서에서 한 페이지씩 이동하고, 텍스트를 검색하는 등의 작업을 할 수 있습니다. XPS 문서는 사용 범위가 Windows로 제한되지 않기 때문에 Microsoft에서는 Apple Macintosh 같은 다른 플랫폼에서도 사용할 수 있는 XPS 뷰어를 제공할 예정입니다.

그림 8. XPS 뷰어를 사용하면 XPS 문서를 한 번에 한 페이지씩 읽을 수 있습니다.

WPF는 개발자가 XPS 문서를 만들고 로드하고 조작하는 데 사용할 수 있는 API 집합을 제공합니다. WPF 응용 프로그램에서도 OPC 수준의 문서를 사용할 수 있기 때문에 일반화된 방식으로 XPS 문서, Office 2007 문서 등에 액세스할 수 있습니다. Microsoft Windows Workflow Foundation을 사용하여 만든 응용 프로그램에서도 이러한 API를 통해 XPS 문서를 사용하는 워크플로를 만들 수 있습니다.

WPF는 응용 프로그램에서 고정된 형식의 문서를 표시하고 사용할 수 있도록 허용함으로써 최신 사용자 인터페이스의 구성 요소를 WPF가 지향하는 일관된 환경에 통합합니다. Windows Vista에서는 이와 동일한 형식으로 문서를 인쇄할 수 있기 때문에 화면에 표시되는 내용과 인쇄된 용지에 표시되는 내용 간의 일관성이 향상됩니다. XSP 문서 형식이 사용자 인터페이스에서 가장 중요한 기술은 아닐 수도 있지만 광범위하게 사용되는 XPS를 통해 WPF 기술이 얼마나 포괄적으로 사용되는지 그 범위를 단적으로 알 수 있습니다.

Windows Presentation Foundation 도구

WPF는 개발자가 유용하게 사용할 수 있는 다양한 기능을 제공합니다. 아무리 강력한 기술도 유용한 도구가 없다면 효용성이 떨어질 수 있습니다. Microsoft에서는 WPF를 사용하는 개발자와 디자이너에 각각 맞추어 최적화된 도구를 제공합니다. 이 섹션에서는 이 두 가지 도구에 대해 간략하게 설명합니다.

개발자용: Visual Studio

Visual Studio는 소프트웨어 개발자를 위한 Microsoft의 주력 응용 프로그램입니다. WPF의 최초 릴리스에는 개발자가 WPF 응용 프로그램을 만드는 데 사용할 수 있는 Visual Studio 2005 확장 기능이 함께 제공될 예정입니다. Visual Studio의 다음 릴리스(코드 이름: "Orcas")에는 Visual Designer for WPF(코드 이름: "Cider") 등의 다른 기능도 추가될 것입니다. 개발자는 이 비주얼 도구를 사용하여 WPF 인터페이스를 그래픽 방식으로 만든 후 기본적인 XAML을 자동으로 생성시킬 수 있습니다. 공식 릴리스 날짜는 아직 발표되지 않았지만 Orcas는 2007년 중에 출시될 예정입니다.

디자이너용: Expression Interactive Designer

앞에서 살펴본 것처럼 WPF의 기본적인 목표는 사용자 인터페이스를 만드는 작업에 디자이너가 적극적으로 참여할 수 있는 작업 환경을 만드는 것입니다. 이와 같은 목표는 XAML을 통해 실현할 수 있지만 새 작업 환경에서 디자이너가 작업하는 데 사용할 수 있는 도구가 필요합니다. 이를 위해 Microsoft에서는 Expression Interactive Designer를 만들었습니다.

아래의 스크린 샷에서 볼 수 있는 것처럼 Expression Interactive Designer는 사용자가 편리하게 작업할 수 있도록 가장 일반적인 디자인 도구 인터페이스를 제공합니다. 그러나 Designer는 WPF 응용 프로그램용 인터페이스를 만드는 데만 초점을 두어 설계되었습니다. 실제로 이 도구의 인터페이스도 WPF를 사용하여 만든 것입니다. 예를 들어 아래 화면에서 오른쪽 상단에 표시되는 WPF 컨트롤 목록과 맨 아래의 그래픽 시간 표시 막대가 이러한 인터페이스에 해당됩니다. 이러한 모든 특징은 이 문서의 앞부분에서 설명한 WPF 기능을 그대로 구현한 것으로, 인터페이스 디자이너가 자유롭게 사용할 수 있도록 설계되었습니다. 이 도구를 사용하면 애니메이션은 물론 변환, 효과 등의 다양한 기능을 그래픽 방식으로 만들 수 있습니다. 디자이너의 작업 결과는 자동으로 생성되는 XAML 파일 형식으로 저장되어 나중에 Visual Studio로 가져올 수 있습니다.

그림 9. 디자이너는 Expression Interactive Designer에서 WPF 인터페이스(그림 8)를 만들 수 있습니다.

Expression Interactive Designer는 Microsoft Expression 제품군의 세 가지 제품 중 하나입니다. 나머지 두 제품은 표준 기반 웹 인터페이스를 만드는 도구인 Expression Web Designer와 벡터 및/또는 비트맵 이미지를 만드는 도구인 Expression Graphic Designer입니다. 이 세 가지 응용 프로그램 중에서 Expression Interactive Designer만 WPF 응용 프로그램용 사용자 인터페이스를 만드는 데만 초점을 두어 설계되었습니다. Expression Graphic Designer에서 인터페이스의 GIF 이미지를 만드는 것처럼 나머지 두 제품을 사용하여 사용자 인터페이스의 구성 요소를 만들 수도 있지만 이 둘은 WPF 전용 도구가 아닙니다. 날짜는 아직 발표되지 않았지만 모든 Expression 도구는 WPF의 릴리스 이후에 출시될 예정입니다.

Windows Presentation Foundation 및 기타 Microsoft 기술

대부분의 Microsoft 신기술과 마찬가지로 WPF는 Windows 작업 환경의 다른 영역에 영향을 줍니다. 그러나 WPF 기술이 다른 영역에 미치는 영향을 살펴보기 전에 알아야 할 것은 시스템에 WPF를 설치해도 Windows Forms, MFC 등과 같이 기존의 다른 기술을 사용하는 소프트웨어와의 충돌이 발생하지 않는다는 점입니다. 즉 .NET Framework 3.0을 지원하는 시스템용으로 작성하는 새 응용 프로그램의 인터페이스는 대부분 WPF를 사용하여 만들지만 이전 기술을 사용하는 응용 프로그램도 이전과 마찬가지로 계속 실행할 수 있습니다.

Windows Presentation Foundation과 Windows Forms

.NET Framework의 최초 릴리스 이후 Windows Forms는 수많은 응용 프로그램을 만드는 데 사용되어 왔으며 WPF가 릴리스된 이후에도 일부 응용 프로그램에는 Windows Forms가 계속 사용될 것입니다. 예를 들어 이전 버전의 Windows와 같이 WPF를 사용할 수 없는 시스템에서 실행해야 하는 모든 구성 요소의 사용자 인터페이스는 Windows Forms를 사용하여 만들게 됩니다. Windows Forms가 제공하는 광범위한 컨트롤 집합을 사용하려는 경우와 같이 새 응용 프로그램에서도 필요에 따라 WPF 대신 Windows Forms를 사용할 수도 있습니다.

WPF를 사용하여 만든 응용 프로그램에서도 Windows Forms의 기능 중 일부를 활용하는 것이 유용할 수 있습니다. 예를 들어 Windows Forms는 WPF에 비해 더 많은 수의 컨트롤 집합을 제공합니다. .NET Framework 버전 2.0에 포함된 DataGridView 컨트롤의 경우 WPF에는 이 컨트롤을 대체할 수 있는 컨트롤이 없으며, 타사에서 다른 여러 가지 용도로 만든 Windows Forms 컨트롤도 상당히 많습니다. 경우에 따라서는 WPF 응용 프로그램에 이러한 기존 컨트롤을 사용해야 할 수도 있습니다. 이와는 반대로 WPF에도 3D 그래픽, 애니메이션 등 Windows Forms에서는 제공하지 않는 많은 기능이 있습니다. 이 경우에는 기존의 Windows Forms 응용 프로그램에 WPF의 기능을 통합하는 것이 좋습니다.

이러한 상호 보완은 충분히 가능합니다. 즉, WPF 응용 프로그램에서 Windows Forms 컨트롤을 호스팅하고 Windows Forms 응용 프로그램에서 WPF 컨트롤을 호스팅할 수 있습니다. 이렇게 하면 사용자는 한 응용 프로그램에서 WPF 대화 상자 및 Windows Forms 대화 상자를 별다른 불편 없이 사용할 수 있습니다.

WPF 응용 프로그램에서는 WPF의 WindowsFormsHost 컨트롤을 사용하여 Windows Forms 컨트롤을 호스팅합니다. 컨트롤의 이름에서 알 수 있듯이 이 컨트롤은 Windows Forms 컨트롤을 호스팅하여 WPF 응용 프로그램에서 Windows Forms 컨트롤을 사용할 수 있게 해 줍니다. 이 컨트롤은 ActiveX 컨트롤도 호스팅할 수 있기 때문에 이전 기술을 사용하여 만든 기존의 대규모 라이브러리를 WPF 응용 프로그램에서 액세스할 수 있습니다. 마찬가지로 Windows Forms 응용 프로그램에서는 WPF 컨트롤, 패널 및 기타 요소를 호스팅할 수 있는 Windows Forms 컨트롤인 ElementHost 컨트롤을 사용합니다. 이러한 각각의 기술을 구현하는 도구에서도 Windows Forms와 WPF용으로 작성된 소프트웨어를 모두 사용할 수 있습니다. 즉 WPF용 Visual Designer를 사용하여 Windows Forms 컨트롤을 배치하고, 마찬가지로 Windows Forms 디자이너를 사용하여 WPF 컨트롤을 배치할 수 있습니다.

그러나 WPF와 Windows Forms를 함께 사용할 경우 몇 가지 제한 사항도 있습니다. 예를 들어 WPF 컨트롤을 Windows Forms 컨트롤 위에 배치할 수는 없습니다. Windows Forms 컨트롤은 항상 최상위 계층에서 사용됩니다. WPF의 투명 효과나 변환 기능은 Windows Forms 컨트롤에 사용할 수 없습니다. 또한 WindowsFormsHost 및 ElementHost 컨트롤을 사용하려면 완전한 신뢰 수준이 필요하기 때문에 이러한 컨트롤을 사용하는 WPF 응용 프로그램을 XBAP로 실행할 수 없습니다. 그러나 대부분의 Windows 응용 프로그램의 사용자 인터페이스는 WPF와 Windows Forms를 함께 사용하여 만들 수 있습니다.

Windows Presentation Foundation과 Win32/MFC

2002년 .NET Framework가 출시되기 전에는 일반적으로 Windows 개발자가 Win32 API를 직접 호출하거나, 이 API를 래핑할 수 있는 C++ 래퍼를 제공하는 MFC를 사용하여 사용자 인터페이스를 만들었습니다. 따라서 이 방식으로 만든 인터페이스의 코드는 지금까지도 많이 사용되고 있습니다. WPF 환경에서는 이 코드가 어떻게 사용될까요?

이 질문에 대한 대답은 Windows Forms의 경우와 유사합니다. 즉, 기존 Win32/MFC 코드에서 WPF 컨트롤을 호스팅하는 것이 가능하고, WPF에서 기존 Win32/MFC 컨트롤을 호스팅하는 것도 가능합니다. 실제로 WPF와 Windows Forms 간의 상호 운용에 사용되는 기능은 Win32/MFC 상호 운용성 서비스를 기반으로 만들어졌습니다. WPF에서는 WPF 환경에서 Win32/MFC 컨트롤을 사용하는 데 필요한 HwndHost 클래스와 Win32/MFC 응용 프로그램에서 WPF 컨트롤을 사용하는 데 필요한 HwndSource 클래스를 제공합니다. 각 클래스는 필요에 따라 두 기술을 매핑합니다. 예를 들어 HwndHost는 Win32/MFC 컨트롤을 참조하는 데 사용되는 hWnd를 WPF 컨트롤인 것처럼 표시하고, 반대로 HwndSource는 WPF 컨트롤을 hWnd인 것처럼 표시합니다.

그러나 Windows Forms의 경우와 마찬가지로 이 두 환경을 함께 사용하는 경우에도 몇 가지 제약이 따릅니다. 실제로 Windows Forms 상호 운용성은 HwndHost 및 HwndSource를 기반으로 하기 때문에 레이어 및 투명 효과에 대한 제약 등과 같이 앞에서 Windows Forms 컨트롤에 대해 설명한 모든 제한 사항이 이 경우에도 동일하게 적용됩니다. 또한 Windows Forms와는 달리 WPF와 Win32/MFC 코드를 함께 사용하는 응용 프로그램에서는 WPF의 관리 코드 환경과 Win32의 비관리 코드 환경 간의 상호 운용으로 인한 문제도 발생합니다. 이와 같은 모든 이유 때문에 Win32/MFC 코드를 사용하는 WPF 응용 프로그램은 XBAP로 실행할 수 없습니다. 그러나 앞에서 설명한 것과 마찬가지로 중요한 것은 Windows 응용 프로그램에서 WPF와 Win32/MFC를 함께 사용할 수 있다는 사실입니다. 즉, WPF를 사용하더라도 응용 프로그램의 기존 사용자 인터페이스 코드를 모두 버릴 필요는 없습니다.

Windows Presentation Foundation과 Direct3D

Direct3D는 Microsoft DirectX API 제품군의 일부로, 3차원 그래픽을 만드는 Windows 개발자들이 주로 사용하는 제품으로서 WPF가 출시된 이후에도 독자적인 가치를 제공할 것입니다. 앞에서 설명한 것처럼 실제로 WPF는 Direct3D를 통해 모든 렌더링 작업을 수행합니다. WPF의 출시 이후에 달라지는 것은 이제는 WPF에서도 3D 그래픽을 만들 수 있기 때문에 3D 개발자들이 둘 중 하나를 선택해야 한다는 점입니다.

그러나 이러한 결정은 비교적 쉽게 내릴 수 있을 것입니다. 고도의 과학적 시각화가 요구되는 3D 중심의 기술적인 응용 프로그램, 게임 등과 같이 3D를 집중적으로 개발해야 하는 경우에는 Direct3D를 사용하는 것이 좋습니다. WPF는 이러한 유형의 소프트웨어를 개발하기 위해 디자인된 플랫폼이 아니므로 적어도 WPF의 초기 릴리스는 이러한 용도로 사용하기에 적합하지 않습니다.

대신 WPF를 사용하면 전문적인 지식이 없는 일반 사용자들도 비교적 쉽게 3D 그래픽을 만들 수 있습니다. 또한 WPF 환경에서는 XBAP를 통해 웹에서 3D 그래픽을 사용할 수 있을 뿐만 아니라 2차원 그래픽과 문서를 비롯하여 응용 프로그램 사용자 인터페이스의 다른 여러 요소에 3D 그래픽을 통합할 수 있습니다. 앞에서 살펴본 HwndHost 클래스를 통해 WPF 응용 프로그램에서 Direct3D 코드를 호스팅할 수도 있습니다. WPF와 Direct3D는 각자 독자적인 가치를 제공하며 앞으로도 Windows 플랫폼에서 중심적인 기능을 할 것입니다.

Windows Presentation Foundation과 AJAX/"Atlas"

개발자는 AJAX를 사용하여 응답 성능이 뛰어난 브라우저 클라이언트를 만들 수 있습니다. AJAX를 사용하면 요청이 있을 때마다 페이지를 새로 고치지 않고도 응용 프로그램과 상호 작용할 수 있기 때문에 웹 브라우저와 웹 서버 사이의 데이터 교환 작업을 줄일 수 있습니다. AJAX는 브라우저에서 지원하는 XMLHttpRequest 개체를 사용하여 이 기능을 제공합니다. 이러한 개념은 1990년대 후반 Internet Explorer 5.0에 처음 소개되었으며 2000년대 중반에 이르러서는 더 많은 브라우저에서 XMLHttpRequest를 지원하게 되었고 AJAX가 보편화되었습니다.

그러나 AJAX 클라이언트를 만드는 작업은 그리 간단하지 않습니다. Microsoft는 이 작업을 위해 "Atlas"라는 코드 이름의 기술 집합을 만들었습니다. Atlas는 AJAX 응용 프로그램을 만드는 데 사용할 수 있는 라이브러리, 컨트롤 및 기타 요소의 집합으로, Internet Explorer뿐 아니라 다른 여러 브라우저에 사용할 수 있는 클라이언트 스크립트 라이브러리 및 서버 쪽에서 사용할 수 있는 ASP.NET 확장 기능으로 구성됩니다. Atlas는 AJAX 클라이언트가 포함된 웹 응용 프로그램을 보다 간단하게 만들 수 있도록 도와 줍니다.

AJAX는 다양한 브라우저에서 사용할 수 있다는 점에서 많은 개발자들이 관심을 갖는 기술입니다. AJAX를 사용하면 보다 뛰어난 대화형 인터페이스를 만들어 웹 사용자에게 제공할 수 있지만 지원되는 콘텐츠 형식이 매우 제한적이라는 단점이 있습니다. 예를 들어 AJAX만으로는 그래픽, 비디오, 애니메이션 및 기타 최신 상호 작용 방식을 지원할 수 없습니다. 따라서 해당 클라이언트에서 WPF를 지원하도록 해야 하는 응용 프로그램을 만들려면 AJAX 대신 XBAP를 선택하는 것이 좋습니다.

Windows Presentation Foundation과 "WPF/E"

XBAP를 사용하면 웹 응용 프로그램에서 WPF 기능의 대부분을 구현할 수 있지만 이를 위해서는 클라이언트 컴퓨터에 WPF가 설치되어 있어야 하므로 웹 응용 프로그램의 사용 범위가 제한될 수 있습니다. 또한 WPF를 지원하지 않는 Macintosh나 기타 시스템에서도 액세스할 수 있고 최신 인터페이스를 제공하는 웹 응용 프로그램을 만들어야 하는 경우가 생길 수도 있습니다.

코드 이름 "WPF/E"는 이와 같은 문제를 해결하기 위해 곧 제공될 기술입니다. WPF/E("E"는 Everywhere를 나타냄)는 Macintosh와 같은 다양한 클라이언트 플랫폼, 소형 장치 등을 비롯하여 Internet Explorer, FireFox, Netscape 등의 다양한 웹 브라우저에 WPF의 기능 중 일부를 제공할 예정으로, 여기에는 2차원 그래픽, 이미지, 비디오, 메모 및 텍스트가 포함됩니다. 그러나 XBAP에서 지원하는 기능 중 3차원 그래픽, 문서, 하드웨어 가속 등의 일부 기능은 WPF/E에서 지원되지 않습니다.

개발자는 JavaScript를 사용하여 WPF/E 응용 프로그램을 만들 수 있습니다. C# 및 Visual Basic 언어를 사용하여 개발할 수 있도록 WPF/E에는 .NET Framework의 플랫폼 간 호환 기능 중 일부도 포함될 것입니다. WPF/E는 .NET Framework 3.0의 일부가 아니며 2007년 중에 릴리스될 것으로 예상됩니다. WPF/E가 릴리스되면 웹 응용 프로그램 작성자는 광범위한 플랫폼에서 다양한 기능을 사용하여 클라이언트 응용 프로그램을 만들 수 있는 또 다른 기술을 경험할 수 있을 것입니다.

결론

사용자 인터페이스는 대부분의 응용 프로그램에서 매우 중요한 부분을 차지합니다. 효과적인 인터페이스를 만들면 사용자 및 사용자가 속한 조직에 상당한 이점을 제공할 수 있습니다. WPF의 기본적인 목표는 개발자가 이러한 효과적인 사용자 인터페이스를 만들 수 있도록 돕는 것이기 때문에 WPF는 Windows 응용 프로그램을 만드는 개발자나 일반 사용자 모두가 기대할 만한 기술입니다.

WPF는 최신 사용자 인터페이스를 만들기 위한 통합 플랫폼을 제공하고, 이러한 인터페이스를 만드는 작업에 디자이너가 보다 적극적으로 참여할 수 있도록 도와 주며, 독립 실행형 응용 프로그램과 브라우저 응용 프로그램을 위한 공통적인 프로그래밍 모델을 제공함으로써 Windows 사용자 환경을 크게 향상시키는 것을 목표로 합니다. WPF는 지난 20년 동안 Windows 사용자 인터페이스의 기반이 되어 온 기술을 대체하는 새로운 기술을 제시하여 향후 20년 동안 사용할 기반 기술로서의 역할을 할 것입니다.

"WCF/WPF" 카테고리의 다른 글

Windows Presentation Foundation으로 최상의 사용... (0)2007/07/23
Windows Presentation Foundation 소개 (0)2007/07/23
Windows Communication Foundation과의 관계로 보... (0)2007/07/23
WCF(Windows Communication Foundation) 아키텍처... (0)2007/07/23

Posted by webdizen

Tags Windows Fresentation Foundation, WPF

No Trackback No Comment

Leave your greetings.

«Prev 1 Next»

	Windows Forms	PDF	Windows Forms/ GDI+	Windows Media Player	Direct3D	WPF
그래픽 인터페이스(예: 폼 및 컨트롤)	X					X
화면에 표시되는 문서	X					X
고정된 형식의 문서		X				X
이미지			X			X
비디오 및 오디오				X		X
2차원 그래픽			X			X
3차원 그래픽					X	X

수안이의 컴퓨터 연구실

4 Articles, Search for 'WPF'

눈길가는 블로그 아티클 [1월 셋째주]

Trackback URL : http://www.webdizen.net/blog/trackback/3171

Leave your greetings.

어도비 플렉스 (Adobe Flex)

개요

라이브사이클 데이터 서비스

플렉스 응용 프로그램 개발 과정

Trackback URL : http://www.webdizen.net/blog/trackback/3161

Leave your greetings.

Windows Presentation Foundation으로 최상의 사용자 인터페이스 빌드

Trackback URL : http://www.webdizen.net/blog/trackback/3089

Leave your greetings.

Windows Presentation Foundation 소개

목차

Windows Presentation Foundation 설명

문제점 예시

문제점 해결: Windows Presentation Foundation의 기능

최신 사용자 인터페이스를 제공하기 위한 통합 플랫폼

개발자와 디자이너가 공동으로 작업할 수 있는 환경

Windows 사용자 인터페이스와 웹 브라우저 사용자 인터페이스를 개발하기 위한 공통의 기술

Windows Presentation Foundation 사용

Windows Presentation Foundation의 기술

응용 프로그램 모델

레이아웃 및 컨트롤

스타일 및 서식 파일

텍스트

문서

이미지

비디오 및 오디오

2차원 그래픽

3차원 그래픽

변환 및 효과

애니메이션

데이터 바인딩

사용자 인터페이스 자동화

Windows Presentation Foundation 적용

독립 실행형 WPF 응용 프로그램

XAML 브라우저 응용 프로그램: XBAP

XPS 문서

Windows Presentation Foundation 도구

개발자용: Visual Studio

디자이너용: Expression Interactive Designer

Windows Presentation Foundation 및 기타 Microsoft 기술

Windows Presentation Foundation과 Windows Forms

Windows Presentation Foundation과 Win32/MFC

Windows Presentation Foundation과 Direct3D

Windows Presentation Foundation과 AJAX/"Atlas"

Windows Presentation Foundation과 "WPF/E"

결론

Trackback URL : http://www.webdizen.net/blog/trackback/3088

Leave your greetings.

Categories

Notice

Tags

Recent Articles

Recent Comments

Recent Trackbacks

Archive

Calendar

Bookmarks