Show Menu
TOPICS×

구성 요소 지침

핵심 구성 요소는 기본 구성 요소와 매우 다른 최신 구현 패턴을 따릅니다.
이 페이지에서는 이러한 패턴과 이러한 패턴을 사용하여 작성 가능한 구성 요소를 언제 빌드하는지에 대해 설명합니다. 첫 번째 섹션 일반 구성 요소 패턴은 모든 유형의 구성 요소에 적용되며 두 번째 섹션 재사용 가능한 구성 요소 패턴은 구성 요소 지침 핵심 구성 요소와 같이 사이트 또는 프로젝트에서 재사용할 수 있도록 만들어진 구성 요소에 적용됩니다.

일반 구성 요소 패턴

구성 요소가 단일 프로젝트에 특정되어 있는지 또는 구성 요소가 사이트 또는 프로젝트에서 광범위하게 재사용되도록 되어 있는지 여부와 상관없이 이 섹션의 지침은 모든 종류의 구성 요소에 대해 권장됩니다.

구성 가능한 구성 요소

구성 요소에는 다양한 옵션이 있는 대화 상자가 있을 수 있습니다. 이 구성 요소를 활용하여 구성 요소를 유연하고 구성할 수 있으며, 서로 변형된 여러 구성 요소를 구현하지 않아야 합니다.
일반적으로 와이어프레임 또는 디자인에 유사한 요소의 변형이 포함되어 있는 경우 이러한 변형을 다른 컴포넌트로 구현하지 않고 변형을 선택할 수 있는 옵션이 있는 하나의 컴포넌트로 구현해야 합니다.
구성 요소를 사이트 또는 프로젝트에서 다시 사용하는 경우 한 단계 더 나아가 구성 가능한 기능 섹션을 참조하십시오 .

우려 사항 분리

일반적으로 마크업 템플릿(또는 보기)과 구성 요소의 로직(또는 모델)을 구분하는 것이 좋습니다. 이를 위해 몇 가지 방법이 있지만, 핵심 구성 요소처럼 로직용 Sling Models와 마크업에 HTML 템플릿 언어 (HTL)를 사용하는 것이 좋습니다.
Sling Models는 POJO에서 필요한 변수에 쉽게 액세스할 수 있는 Java 주석 집합이므로 구성 요소에 대한 Java 로직을 구현하는 간단하고 강력한 성능을 제공합니다.
HTL은 AEM에 맞게 고안된 안전하고 간단한 템플릿 언어입니다. 그것은 많은 형태의 로직이라고 부를 수 있는데, 그것은 그것을 매우 유연하게 한다.

재사용 가능한 구성 요소 패턴

이 섹션의 지침은 모든 유형의 구성 요소에도 사용할 수 있지만 핵심 구성 요소와 같이 사이트 또는 프로젝트에서 재사용할 수 있는 구성 요소에 대해서는 가장 적절합니다. 따라서 이러한 지침은 단일 사이트 또는 프로젝트에서만 사용되는 구성 요소에 대해 무시될 수 있습니다.

사전 구성 가능한 기능

페이지 작성자가 사용하는 편집 대화 상자 외에도 구성 요소에는 템플릿 작성자가 미리 구성할 수 있는 디자인 대화 상자가 있을 수 있습니다. 템플릿 편집기를 사용하면 "정책"이라고 하는 모든 사전 구성을 설정할 수 있습니다.
구성 요소를 가능한 한 다시 사용할 수 있도록 하려면 구성 요소를 미리 구성할 수 있는 의미 있는 옵션을 제공해야 합니다. 이렇게 하면 다른 사이트의 특정 요구 사항에 맞게 구성 요소의 기능을 활성화하거나 비활성화할 수 있습니다.

프록시 구성 요소 패턴

각 컨텐츠 리소스에는 렌더링하기 위해 구성 요소를 참조하는
sling:resourceType
속성이 있으므로 여러 사이트에서 공유하는 구성 요소를 가리키는 대신 이러한 속성이 사이트별 구성 요소를 가리키는 것이 좋습니다. 이렇게 하면 한 사이트에서 구성 요소에 대해 다른 비헤이비어가 필요한 경우 컨텐츠 리팩토링 문제를 방지할 수 있습니다. 이렇게 하면 사이트별 구성 요소에서 이러한 사용자 지정을 수행할 수 있고 다른 사이트에는 영향을 주지 않기 때문입니다.
그러나 프로젝트별 구성 요소가 코드를 복제하지 않도록 하려면 각 구성 요소는
sling:resourceSuperType
속성이 있는 공유 상위 구성 요소를 참조해야 합니다. 대부분의 상위 구성 요소만 참조하는 이러한 프로젝트 특정 구성 요소를 "프록시 구성 요소"라고 합니다. 프록시 구성 요소는 기능을 완전히 상속하거나 구성 요소의 일부 측면을 재정의할 수 있는 경우 완전히 비어 있을 수 있습니다.

구성 요소 버전 관리

구성 요소는 시간 경과에 따라 완벽하게 호환되어야 하지만, 경우에 따라 호환할 수 없는 변경 사항이 필요합니다. 이러한 서로 다른 요구 사항에 대한 한 가지 해결 방법은 해당 리소스 유형 경로에 숫자를 추가하고 구현의 정규화된 Java 클래스 이름에 번호를 추가하여 구성 요소 버전 관리를 도입하는 것입니다. 이 버전 번호는 의미 체계 버전 관리 지침에 의해 정의된 주 버전을 나타내며 이전 버전과 호환되지 않는 변경 사항에 대해서만 증가합니다.
구성 요소의 다음 측면을 호환되지 않는 변경 사항으로 인해 새 버전이 만들어집니다.
  • Sling Models(의미 체계 버전 관리 지침 참조)
  • HTL 스크립트 및 템플릿
  • HTML 마크업 및 CSS 선택기
  • JSON 표현
  • 대화 상자
자세한 내용은 GitHub의 버전 관리 정책 문서를 참조하십시오.
구성 요소 버전 관리는 어떤 것을 리팩토링해야 하는 시기를 명확히 하기 때문에 업그레이드에 중요한 계약 양식을 만듭니다. 업그레이드에 필요한 다양한 사용자 정의 양식의 고려 사항을 설명하는 사용자 정의 업그레이드 호환성 섹션을 참조하십시오.
컨텐츠 마이그레이션이 까다롭지는 않도록 컨텐츠 리소스에서 버전 관리 구성 요소를 직접 지정하지 않는 것이 중요합니다. 경험상 컨텐츠의 버전 번호는 포함되지 않아야
sling:resourceType
합니다. 그렇지 않으면 구성 요소를 업그레이드하려면 컨텐츠도 리팩토링해야 합니다. 이를 방지하는 가장 좋은 방법은 위에 설명된 프록시 구성 요소 패턴을 따르는 것입니다.

모델 인터페이스

이 패턴은 Java 인터페이스를 가리키도록 HTL의
data-sly-use
지침에 대한 것이지만, Sling Model 구현은 구성 요소의 리소스 유형에도 자신을 등록하고 있습니다.
위에 설명된 프록시 구성 요소 패턴과 결합하면 이 형태의 이중 바인딩 기능은 다음과 같은 좋은 확장 포인트를 제공합니다.
  1. 사이트는 여전히 인터페이스를 가리킬 수 있는 HTL 파일에 대해 신경 쓰지 않고도 프록시 구성 요소의 리소스 유형에 등록하여 Sling 모델의 구현을 재정의할 수 있습니다.
  2. 사이트는 어떤 구현 로직을 가리키는지 신경 쓰지 않고도 구성 요소의 HTL 마크업을 재정의할 수 있습니다.

모든 작업 간소화

다음은 제목 코어 구성 요소의 예를 들어 전체 리소스 유형 바인딩 구조에 대한 개요입니다. 사이트 특정 프록시 구성 요소가 컨텐츠 리소스에 버전 번호가 포함되어 있지 않도록 구성 요소 버전 지정을 해결하는 방법을 보여 줍니다. 그런 다음 구성 요소의 HTL
title.html
파일이 모델 인터페이스에 어떻게 사용하는지를 보여주며, 구현은 Sling 모델 주석을 통해 구성 요소의 특정 버전에 바인딩됩니다.
다음은 구현 POJO에 대한 세부 정보를 표시하지 않고 관련 템플릿과 정책을 참조하는 방법을 보여주는 또 다른 개요입니다.
cq:allowedTemplates
cq:template
속성은 사이트에 사용할 수 있는 템플릿을 알려주고 각 페이지에 대해 연관된 템플릿이 무엇인지 알려줍니다. 모든 템플릿은 다음 세 부분으로 구성됩니다.
  • 구조각
    ​페이지에서 강제로 사용할 리소스가 포함되어 있으며 페이지 머리글과 바닥글 구성 요소와 같이 페이지 작성자가 삭제할 수 없습니다.
  • 초기값페이지에
    ​복제될 초기 컨텐츠를 포함합니다.
  • 정책구성
    ​요소의 사전 구성인 정책에 대한 매핑을 각 구성 요소에 대해 포함합니다. 이 매핑을 사용하면 템플릿 간에 정책을 다시 사용할 수 있으므로 중앙에서 관리할 수 있습니다.

AEM 프로젝트 원형

AEM Project Tranype 은 권장 프록시 패턴을 사용하는 핵심 구성 요소의 로직과 적절한 구현을 위해 SlingModels가 포함된 사용자 지정 HTL 구성 요소의 도움말 예제를 비롯하여 최소한의 Adobe Experience Manager 프로젝트를 고유한 프로젝트의 시작점으로 만듭니다.
다음 참조:
  • 핵심 구성 요소 사용 - 프로젝트에서 핵심 구성 요소를 사용하여 바로 시작할 수 있습니다.
  • 핵심 구성 요소 사용자 지정 - 핵심 구성 요소의 스타일을 지정하고 사용자 지정하는 방법을 알아봅니다.