1 Results for 'Site of Origin'

  1. 2008.10.24 리소스 종류와 상대 URI 평가 방법 정리 (5)

실버라이트 2에서 상대 URI를 평가하는 기준은 아주 심플하게 말하자면,

“XAP파일이 호스팅되어 있는 웹 서버의 URL”이에요.

끝~~~~

 

 

 

 

이러면 해피하겠지만, 실버라이트는 각 리소스 종류에 따라 상대 URI를 평가하는 방법이 달라져요. 정확히 말하자면 어떤 상대 URI를 가진 리소스를 가져올 때에는 정해진 절차가 있다…가 되겠죠.

 

리소스의 종류

우선 실버라이트가 사용할 수 있는 리소스의 종류는 크게 다음과 같이 나눌 수 있어요.

  1. Resource
  2. Embedded Resource
  3. Content
  4. Site of Origin

Resource

Resource는 비주얼 스튜디오 IDE에서 Build Action 속성이 Resource로 설정된 프로젝트 아이템을 말해요.
Resource는 프로젝트가 컴파일 될 때 해당 프로젝트의 타겟 어셈블리에 포함되므로 별도로 배포할 필요가 없어지지만 대신 어셈블리의 용량이 그만큼 늘어나게 되겠죠. 따라서 아주 필수적인 요소만을 Resource로 설정해야 해요.

※ Build Action의 설정은 다음 그림과 같이 프로젝트 아이템을 선택하고 속성Properties 창에서 할 수 있습니다.


Embedded Resource

Embedded Resource는 Resource와 거의 동일한 속성을 갖지만 애플리케이션에서 접근하는 방법이 달라요. 실버라이트에서는 사용되지 않는다고 봐도 무방해요. 아니, 실버라이트 프로젝트에서는 쓰지 않기를 권장해요. 정말로 불편하기만 하니까요.

Content

Content는 비주얼 스튜디오 IDE에서 Build Action 속성이 Content로 설정된 프로젝트 아이템을 말하죠.
Content는 실버라이트 프로젝트가 컴파일 될 때 XAP 패키지 파일에 직접 포함이 되므로 역시 따로 배포할 필요가 없어지죠. 그러나 마찬가지로 XAP 패키지의 크기가 늘어나는 원인이 되므로 필수 요소만을 Content로 설정해야 해요.

Resource와 Embedded Resource와 Content가 비록 그 정의와 특성이 다르긴 하지만 하나의 프로젝트의 아이템이므로 같은 위치에 같은 파일 명으로는 단 하나의 종류만 존재할 수 있어요. 요컨대, MyImage.png라는 파일이 동시에 Resource와 Content의 형태로 존재할 수 없다는 거죠.

※단, 위의 가정은 어디까지나 비주얼 스튜디오 IDE를 사용할 경우를 말합니다. 기술적으로 MyImage.png는 Resource와 Content로 존재할 수 있지만 실제로 그렇게 하는 경우는 없다고 단언할 수 있을 만큼 없기 때문에 위와 같이 말 할 수 있습니다.

Site of Origin

이건 참 할 때마다 우리말로 옮기기가 애매한 건데요, 굳이 말하자면 ‘XAP파일을 호스트하는 서버의 위치’라고 할 수 있죠. 쉽게 얘기해서 실버라이트 패키지, XAP 파일이 올라갈 웹 서버에 있다는 것을 의미해요. Site of Origin 위치에 있는 리소스 파일은 당연하게도 실버라이트 패키지 내에 포함되지 않으므로 그 파일이 존재할 것이라고 확신할 수 없어요. 따라서 이 위치에 있는 리소스를 접근할 때에는 반드시 예외 처리가 필요하겠죠. 웹의 특성상 대부분의 이미지, 동영상, XML 등이 Site of Origin 리소스로 배치될 거에요.

 

URI 표현식

실버라이트는 어떤 리소스의 위치를 지정하는데 URI(Uniform Resource Identifyer)를 사용하죠. URI는 크게 상대 URI와 절대 URI로 구분할 수 있는데요, 절대 URI는 일반적인 URL을 지정하는 방법과 같다고 할 수 있으므로 상대 URI의 표현에 대해서 집중하도록 하죠. 상대 URI의 표현에는 몇 가지 규칙이 있어요.

예제를 들기 위해 실버라이트 애플리케이션이 http://hugeflow.com/Silverlight/Test.xap에서 다운로드 되었다고 가정합니다.

상대 URI는 Site of Origin 즉, 웹 사이트가 아닌 Resource또는 Content를 우선적으로 가리킵니다.

단, 적용 방식은 살짝 특이한데 이 부분은 아래에 설명합니다.

 

상대 URI의 절대적 기준은 XAP 파일의 현재 위치가 됩니다.

ex) /Image.png => http://hugeflow.com/Silverlight/Image.png

 

상대 경로는 '/'로 시작하는 것과 그렇지 않은 것이 동일한 위치를 가리킵니다.

ex) Image.png  => http://hugeflow.com/Silverlight/Image.png

ex) /Image.png => http://hugeflow.com/Silverlight/Image.png

 

..표현식으로 상위 경로를 지정할 수 없으며 이 표현은 무시됩니다.

ex) ../../Image.png => http://hugeflow.com/Silverlight/Image.png

 

Resource는 명시적으로 리소스가 포함된 어셈블리를 지정할 수 있습니다.

ex) /MyAssembly;component/Image.png => MyAssembly안에 있는 Image.png 리소스를 가리킴

 

동작 테스트

이외에도 다른 규칙들도 있지만 실제 사용에서 가장 중요한 내용은 이 정도라고 봐요. 자, 지금껏 말만 많이 했는데 역시 실제 동작 코드를 봐야 쉽게 이해가 가겠죠? 다음 이미지는 각 경로에 따라 로드되는 리소스의 종류를 표현하고 있는데요, 일단 보죠.


코드도 함께 곁들이는 건 어떨까요? :)

 

이 프로젝트는 다음과 같은 구조를 가지고 있어요.

 
 - 크게 세개의 프로젝트

ImageLibrary
실버라이트 라이브러리

UriRuleTest
ImageLibrary를 참조하는 실버라이트 애플리케이션 프로젝트

UriRuleTest.Web
UriRuleTest 실버라이트 애플리케이션을 호스팅하는 웹 서비스


- 실버라이트 애플리케이션 프로젝트와 웹 프로젝트는 각각 동일한 위치에 같은 파일 명으로 이미지 리소스 파일 존재

- 각 리소스가 포함된 위치는 색상으로 구분
(파랑 ; 실버라이트 애플리케이션
빨강 ; 실버라이트 라이브러리
녹색 ; Site of Origin 웹 프로젝트)

- 상대 URI로는 실버라이트가 호스팅되는 위치 바깥의 경로를 접근할 수 없다는 것을 보여주기 위해 웹 프로젝트에는 또다른 위치에 리소스들을 포함
(Web/Images 폴더)


결과를 보면 직관적으로 어떤 식으로 리소스가 로딩 되는지를 확인할 수 있을 거에요. 하나하나 설명하는 것 보다는 특이한 몇 가지 결과만 얘기해 보도록 하죠.

  • '/'로 시작하지 않는 리소스의 경우 Resource를 먼저 검색하고 만약 Resource가 없을 경우 Site of Origin을 시도합니다. 즉 두 파일이 모두 존재할 경우 항상 Resource가 선택됩니다. 또한 이 경우 Content에 대해서는 시도하지 않습니다.
  • '/'으로 시작하는 리소스의 경우 Content를 먼저 검색하고 만약 Content가 없을 경우 Site of Origin을 시도합니다. 즉 두 파일이 모두 존재 할 경우 항상 Content가 선택됩니다. 또한 이 경우 Resource에 대해서는 시도하지 않습니다.
  • Site of Origin의 경우 '/'의 유무는 영향을 주지 않습니다.
  • 위와 같은 특징이 혼란을 줄 가능성이 있으므로 Resource는 반드시 다음과 같이 명시적인 리소스 경로를 사용하는 것이 좋습니다. 이렇게 하면 참조하고 있는 다른 어셈블리의 리소스도 가져올 수 있습니다. 
    /UriRuleTest;component/Images/Resource.png
  • Embedded Resource는 오직 코드를 통해 특별한 방법으로만 접근이 가능합니다. 사실 Embedded Resource를 쓸 이유가 없습니다.
  • 다른 라이브러리 어셈블리에 있는 Content는 가져올 수 있는 방법이 없습니다. 이 파일은 사실상 컴파일시 버려집니다.
  • 웹 서버에서 XAP 파일이 있는 경로를 벗어난 위치에 있는 리소스를 접근하기 위해서는 절대 URI를 사용하는 방법 밖에 없습니다. 사용법은 코드를 참고하세요.
  • ../../../../… 와 같이 ..를 아무리 많이 중첩하더라도 결코 XAP 파일의 위치에서 벗어날 수 없으며 해당 표현은 무시됩니다.

사실 이 정책이 Beta2때 바뀌었다가 RC0이후로 다시 위와 같이 돌아왔죠. 실버라이트 애플리케이션의 의미상 위의 정책이 올바르다고 생각해요. 실버라이트 애플리케이션이 웹 서버의 루트 경로나 상대 경로를 가정하고 동작하는 것은 좋지 않은 판단일테니까요.

어쨌든 이젠 헤깔리지 마시고 그냥 위의 표를 참고하세요^^

저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo


티스토리 툴바