2013-01-09 2 views
4

페이지의 URL을 현지화/번역해야하는 경우가 있습니다. 우리의 기존 메커니즘은 oData를 통해 페이지를 검색하기 위해 실제 게시 된 URL을 사용합니다. 간단한 예제를 명확히하기 위해 :Tridion 및 REL : 페이지의 PublishedUrl 속성에서 페이지 파일 이름 업데이트

/my-awesome-path/my-awesome-page 

지금

이된다 : 우리는 파일 확장자가없는 요청 URL을 (소요 프론트 엔드에서 어떤 논리를 가지고하는이 .html 확장자, 예를 추가
/my-awesome-path/my-awesome-page.html 

는 논리는 우리가이 SEO 친화적 인 URL을 구문 분석하고 MVC 컨트롤러 기능 PARAM을 얻기 위해이 문제를 해결해야 훨씬 더 논리가 쿼리

/odata.svc/Pages?$filter=url eq '/my-awesome-path/my-awesome-page.html' 

를 사용하여 하나로, OData에서 페이지를 가져옵니다 eters 및 기타 이것들은 여기에 관련이 없습니다.

우리는 번역 된 URL을 제공하기 위해 페이지를 현지화 할 수 없기 때문에 상위 웹 게시에서 전체 페이지를 관리 할 수 ​​없다는 것을 의미합니다.

페이지 파일 이름까지 이어지는 지역화 된 경로를 얻으려면 SG를 지역화하면됩니다. 문제는 페이지 파일 이름입니다. 페이지의 메타 데이터에는 지역화 된 페이지 파일 이름을 제공하는 필드가있는 링크 된 "현지화 가능 메타 데이터"구성 요소가 있습니다.

게시/배포 프로세스 중에 페이지의 URL 속성을 업데이트하여이 링크 된 메타 데이터 구성 요소의 현지화 된 페이지 파일 이름으로 페이지의 게시 된 URL을 업데이트하십시오 (Google에서 현지화 된 파일 이름 필드에 액세스 할 수 있다고 가정). 게시 시작부터 배포 약정까지 모든 단계의 가치).

사용자 지정 해결 프로그램을 통해이 작업을 시도했지만이 수준에서는 page.PublishedUrl 속성이 CM에 의해 이미 설정되어 있고 재정의 될 수없는 것으로 보입니다. 따라서 page.FileName 속성을 업데이트해도 아무런 효과가 없습니다.

또한 브로커 DB의 PAGE 테이블에있는 URL 열을 다른 이름으로 직접 업데이트하려고 시도했으며 페이지의 동적 연결 및 게시 취소를 포함하여 모든 것이 계속 작동하는 것처럼 보입니다. 분명히 jdbc를 통해 DB를 직접 업데이트하기 위해 저장소 확장 또는 배포 확장을 작성하는 것은 용납 할 수 없습니다. 1) 디플로 확장을 시도하고 2) URL이 실제 URL을 업데이트하지 않고 논리를 대체 실행하는 사용자 정의 렌더러를 작성하려고 url 속성을 업데이트 할 Tridion API를 사용 : 여기

내가 생각하고있는 옵션입니다 브로커에서. 요청 시간 처리가 매번 필요하기 때문에 나는 이것을 선호하지 않습니다.

제 질문은 페이지 URL 등록 정보를 업데이트하는 가장 적합한 방법은 무엇입니까? URL 속성을 업데이트하기 위해 Tridion API를 사용하여 맞춤 배포자를 작성하면 리졸버처럼 막 다른 길로 인도합니까?

+1

저는 배포자 측에서이 작업을 수행해야 할 수도 있습니다. 전개 자 확장을 사용하여 전송 패키지에서 페이지의 파일 이름을 변경할 수 있습니다 (여기에 드래곤 : 문서화되지 않았고 잠재적으로 지원되지 않음). –

답변

3

위의 Nuno의 의견에 따라 맞춤 배포자를 사용하지 않기로 결정하고 이벤트 시스템의 2 가지 이벤트 구독을 사용하여 문제를 해결했습니다. 페이지를 게시 할 때 먼저 페이지를 현지화하고 현지화 된 링크 된 메타 데이터 구성 요소에서 현지화 된 파일 이름을 가져 와서 페이지를 저장합니다. 그런 다음 이벤트에서 단순히 페이지의 위치를 ​​벗어납니다. 여기에 제 작업 코드가 있습니다 :

[TcmExtension("Publish or Unpublish Events")] 
public class PublishOrUnpublishEvents : TcmExtension 
{ 
    public PublishOrUnpublishEvents() 
    { 
     EventSystem.Subscribe<Page, PublishEventArgs>(SetLocalizedPageFileName, EventPhases.Initiated); 
     EventSystem.Subscribe<Page, SetPublishStateEventArgs>(UnlocalizePageOncePublished, EventPhases.Initiated); 
    } 


    public void SetLocalizedPageFileName(Page page, PublishEventArgs args, EventPhases phase) 
    { 
     string localFilename = GetLocalilizedFileNameFromPageMetadata(page); 
     if (!string.IsNullOrEmpty(localFilename)) 
     { 
      page.Localize(); 
      if (page.TryCheckOut()) 
      { 
       page.FileName = localFilename; 
       page.Save(true); 
      } 
     } 
    } 

    public void UnlocalizePageOncePublished(Page page, SetPublishStateEventArgs args, EventPhases phase) 
    { 
     string localFilename = GetLocalilizedFileNameFromPageMetadata(page); 
     if (!string.IsNullOrEmpty(localFilename)) 
      page.UnLocalize(); 
    } 

    private string GetLocalilizedFileNameFromPageMetadata(Page page) 
    { 
     string localFilename = string.Empty; 
     if (page.Metadata != null) 
     { 
      ItemFields fields = new ItemFields(page.Metadata, page.MetadataSchema); 
      if (fields.Contains("LocalizableMeta")) 
      { 
       ComponentLinkField localMetaField = fields["LocalizableMeta"] as ComponentLinkField; 
       Component component = localMetaField.Value; 
       ItemFields compFields = new ItemFields(component.Content, component.Schema); 
       if (compFields.Contains("LocalizedPageFilename")) 
       { 
        SingleLineTextField fileNameTextField = compFields["LocalizedPageFilename"] as SingleLineTextField; 
        localFilename = fileNameTextField.Value; 
       } 
      } 
     } 
     return localFilename; 
    } 
} 
1

아마도 또 다른 옵션 :

스토어 지역화 된 URL 게시 된 페이지에 대한 동일한 물리적 URL을 유지하는 페이지에 대한 추가 메타 데이터 필드가 있습니다.

나는 예를 들어, 나는 그것이 URL이 작동 전 세계적으로 어떻게 입력하는 워드 프레스에서 가능하는 방식을 좋아 귀하의 요구 사항이 자식 페이지의 현지화를 방지하는 것입니다 참조 :

/내 사이트/%postname%/

그것은 것 콘텐츠 URL에서 콘텐츠 제목을 추출하고 사용할 수있는 SDL Tridion 내에서 이와 비슷한 것을 구축하십시오.

어느 쪽이든, '친숙한 URL'을 사용하고 실제 URL을 조회하는 시스템을 작성해야한다면 매우 간단 할 것입니다.

+0

제안 John에게 감사드립니다. 그러나 내가 언급해야 할 또 다른 요구 사항은 페이지를 가져 오기 위해 하나 이상의 odata를 치지 않아야한다는 것입니다. Custommeta에서이를 유지하려면 CustomMetas 엔티티에 한 번, 다음으로 Pages 엔티티에 한 번의 히트가 필요합니다. 우리는 이것을 피하고 우리가 $ 필터링 할 수있는 매개 변수로만 작업하고 싶습니다. –