AEM 코어 개념 aem-core-concepts

AEM에서 개발을 위한 사전 요구 사항 prerequisites-for-developing-on-aem

AEM을 기반으로 개발하는 데 다음 기술이 필요합니다.

또한 을 읽고 따르는 것이 좋습니다 지침 및 우수 사례.

Java Content Repository java-content-repository

JCR(Java Content Repository) 표준, JSR 283를 지정하는 경우, 컨텐츠 리포지토리 내의 세부 수준에서 양방향 컨텐츠에 액세스할 수 있는 공급업체와 독립적이고 구현에 독립적인 방법을 지정합니다.

Specification Lead는 Adobe Research(스위스) AG에 의해 소유됩니다.

다음 JCR API 2.0 패키지, javax.jcr.* 저장소 컨텐츠에 대한 직접 액세스 및 조작에 사용됩니다.

Experience Server(CRX) 및 Jackrabbit experience-server-crx-and-jackrabbit

Experience Server는 AEM이 빌드되고 사용자 지정 애플리케이션을 작성하는 데 활용할 수 있는 Experience Services를 제공하며 Jackrabbit을 기반으로 컨텐츠 저장소를 내장합니다.

Apache Jackrabbit 는 JCR API 2.0의 구현을 완벽하게 따르는 오픈 소스입니다.

Sling 요청 처리 sling-request-processing

Sling 소개 introduction-to-sling

AEM이 Sling은 컨텐츠 중심 애플리케이션을 쉽게 개발할 수 있도록 REST 원칙을 기반으로 하는 웹 애플리케이션 프레임워크입니다. Sling은 Apache Jackrabbit와 같은 JCR 저장소 또는 AEM의 경우 CRX 컨텐츠 저장소를 데이터 저장소로 사용합니다. Sling은 Apache Software Foundation에 기여하여 Apache에서 추가 정보를 찾을 수 있습니다.

Sling을 사용하면 렌더링할 컨텐츠의 유형이 첫 번째 처리 고려 사항이 아닙니다. 대신 기본 고려 사항은 URL이 렌더링을 수행할 스크립트를 찾을 수 있는 콘텐츠 개체로 확인되는지 여부입니다. 이 기능은 웹 컨텐츠 작성자가 요구 사항에 맞게 쉽게 사용자 지정된 페이지를 작성할 수 있도록 지원합니다.

이러한 유연성의 장점은 다양한 컨텐츠 요소를 사용하는 애플리케이션이나 사용자 지정할 수 있는 페이지를 필요로 할 때 두드러집니다. 특히 AEM 솔루션에서 WCM과 같은 웹 컨텐츠 관리 시스템을 구현할 때

자세한 내용은 15분 안에 Sling 검색 Sling을 사용하여 개발하는 첫 번째 단계에 대해 설명합니다.

다음 다이어그램에서는 Sling 스크립트 해상도에 대해 설명합니다. 이 보고서는 HTTP 요청에서 컨텐츠 노드로, 컨텐츠 노드에서 리소스 유형으로, 리소스 유형에서 스크립트로 가져오는 방법과 사용 가능한 스크립팅 변수를 보여줍니다.

다음 다이어그램은 저장소에서 노드를 만들기, 수정, 삭제, 복사 및 이동하기 위한 무제한 옵션을 제공하는 모든 POST 요청에 대한 기본 핸들러인 SlingPostServlet을 처리할 때 사용할 수 있는 숨겨진 모든 강력한 요청 매개 변수에 대해 설명합니다.

Sling은 컨텐츠 중심의 sling-is-content-centric

Sling은 콘텐츠 중심. 즉, 각(HTTP) 요청이 JCR 리소스(저장소 노드) 형식의 컨텐츠에 매핑될 때 처리에 중점을 둡니다.

RESTful Sling restful-sling

컨텐츠 중심 철학으로 인해 Sling은 REST 기반 서버를 구현하므로 웹 애플리케이션 프레임워크의 새로운 개념을 제공합니다. 장점은 다음과 같습니다.

URL 분해 url-decomposition

Sling에서 처리는 사용자 요청의 URL에 의해 결정됩니다. 적절한 스크립트로 표시할 컨텐츠를 정의합니다. 이를 위해 URL에서 정보가 추출됩니다.

다음 URL을 분석하는 경우:

https://myhost/tools/spy.printable.a4.html/a/b?x=12

우리는 그것을 그것의 복합 부분으로 나눌 수 있습니다.

프로토콜 HTTP

호스트 웹 사이트의 이름입니다.

컨텐츠 경로 렌더링할 컨텐츠를 지정하는 경로입니다. 확장과 함께 사용됩니다. 이 예제에서는 tools/spy.html으로 변환됩니다.

선택기 컨텐츠를 렌더링하는 대체 방법에 사용됩니다. 이 예에서는 A4 형식의 프린터 친화형 버전입니다.

확장 컨텐츠 형식; 렌더링에 사용할 스크립트도 지정합니다.

접미사 추가 정보를 지정하는 데 사용할 수 있습니다.

매개 변수 동적 컨텐츠에 필요한 모든 매개 변수.

URL에서 콘텐츠 및 스크립트에 이르기까지 from-url-to-content-and-scripts

다음 원칙 사용:

아래 그림은 사용된 메커니즘을 보여 줍니다. 이 메커니즘은 다음 섹션에서 자세히 설명합니다.

Sling을 사용하면 특정 엔터티를 렌더링하는 스크립트를 지정합니다( sling:resourceType 속성(JCR 노드)입니다. 이 메커니즘은 리소스가 여러 변환을 가질 수 있으므로 스크립트가 데이터 엔티티에 액세스하는 것보다 더 자유롭게 제공합니다(PHP 스크립트의 SQL 문처럼).

리소스에 요청 매핑 mapping-requests-to-resources

요청이 분류되고 필요한 정보가 추출됩니다. 저장소가 요청된 리소스(컨텐츠 노드)에 대해 검색됩니다.

Sling은 JCR 노드 이외의 항목을 리소스화할 수도 있지만 고급 기능입니다.

스크립트 찾기 locating-the-script

적절한 리소스(컨텐츠 노드)가 있으면 sling 리소스 유형 추출됩니다. 컨텐츠 렌더링에 사용할 스크립트를 찾는 경로입니다.

에 의해 지정된 경로 sling:resourceType 다음 중 하나를 수행할 수 있습니다.

모든 Sling 스크립트는 다음 중 하나의 하위 폴더에 저장됩니다 /apps 또는 /libs: 이 순서로 검색됩니다( 참조). 구성 요소 및 기타 요소 사용자 지정).

주목할 다른 몇 가지 사항은 다음과 같습니다.

AEM의 특정 인스턴스에서 지원하는 스크립트 엔진 목록은 Felix Management Console( http://<host>:<port>/system/console/slingscripting).

또한 Apache Sling은 널리 사용되는 다른 스크립팅 엔진(예: Groovy, JRuby, Freemarker)과의 통합을 지원하며 새로운 스크립팅 엔진을 통합하는 방법을 제공합니다.

위의 예를 사용하는 경우 sling:resourceType is hr/jobs 다음에 대해 다음을 수행합니다.

지정된 요청에 여러 스크립트가 적용되는 경우 가장 일치하는 스크립트가 선택됩니다. 매치가 구체적일수록 효과적이다. 즉, 요청 확장이나 메서드 이름이 일치하는 것과 관계없이 더 많은 선택기가 더 잘 일치합니다.

예를 들어 리소스에 액세스하기 위한 요청을 고려합니다
/content/corporate/jobs/developer.print.a4.html
유형
sling:resourceType="hr/jobs"

올바른 위치에 다음 스크립트 목록이 있다고 가정합니다.

그런 다음 기본 설정의 순서는 (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1)입니다.

리소스 유형(주로 sling:resourceType 속성)에는 리소스 슈퍼 유형도 있습니다. 일반적으로 이것은 sling:resourceSuperType 속성을 사용합니다. 이러한 수퍼 유형은 스크립트를 찾으려고 할 때도 고려됩니다. 리소스 슈퍼 유형의 장점은 기본 리소스 유형이 sling/servlet/default (기본 서블릿에 사용됨)이 효과적으로 루트입니다.

리소스의 리소스 슈퍼 유형은 다음 두 가지 방법으로 정의할 수 있습니다.

예:

유형 계층 구조:

왜냐하면 /y 있음 sling:resourceSuperType property /x 이 아니므로 상위 형식은 해당 리소스 유형에서 가져옵니다.

Sling 스크립트를 직접 호출할 수 없습니다 sling-scripts-cannot-be-called-directly

Sling 내에서 스크립트를 직접 호출할 수 없습니다. 이렇게 하면 REST 서버의 엄격한 개념이 중단됩니다. 리소스와 표현을 혼합합니다.

표현(스크립트)을 직접 호출하는 경우 스크립트 내에 리소스를 숨겨 프레임워크(Sling)가 더 이상 이 리소스에 대해 알지 못합니다. 따라서 특정 기능을 잃게 됩니다.

Sling API sling-api

Sling API 패키지 org.apache.sling을 사용합니다.및 태그 라이브러리(&A)

sling:include를 사용하여 기존 요소 참조 referencing-existing-elements-using-sling-include

마지막으로 고려해야 할 사항은 스크립트 내에 기존 요소를 참조해야 하는 것입니다.

더 복잡한 스크립트(집계 스크립트)는 여러 리소스(예: 탐색, 사이드바, 바닥글, 목록의 요소)에 액세스해야 할 수 있으며 리소스.

이렇게 하려면 sling:include("/<path>/<resource>") 명령을 실행합니다. 이렇게 하면 이미지 렌더링을 위한 기존 정의를 참조하는 다음 문과 같이 참조된 리소스의 정의를 효과적으로 포함합니다.

%><sling:include resourceType="geometrixx/components/image/img"/><%

OSGI osgi

OSGi는 모듈식 애플리케이션 및 라이브러리(Java용 Dynamic Module System)를 개발 및 배포하는 아키텍처를 정의합니다. OSGi 컨테이너를 사용하면 애플리케이션을 개별 모듈(추가 메타 정보가 있는 jar 파일이며 OSGi 용어에서 번들이라고 함)로 분류하고 다음 기능을 사용하여 애플리케이션 간의 상호 종속성을 관리할 수 있습니다.

이러한 서비스 및 계약은 개별 요소가 협업을 위해 동적으로 서로를 검색할 수 있도록 하는 아키텍처를 제공합니다.

그런 다음 OSGi 프레임워크를 통해 다시 시작할 필요 없이 이러한 번들을 동적으로 로드/언로드, 구성 및 제어할 수 있습니다.

이 아키텍처를 통해 Sling을 애플리케이션별 모듈로 확장할 수 있습니다. Sling에서 CQ5에서는 Apache Felix OSGI(Open Services Gateway Initiative) 구현 및 OSGi Service Platform 릴리스 4 버전 4.2 사양을 기반으로 합니다. 둘 다 OSGi 프레임워크 내에서 실행되는 OSGi 번들 컬렉션입니다.

이렇게 하면 설치 내의 패키지에 대해 다음 작업을 수행할 수 있습니다.

자세한 내용은 웹 콘솔, OSGI 구성 및 OSGi 구성 설정 추가 정보.

AEM 환경의 개발 개체 development-objects-in-the-aem-environment

개발에 대한 관심 사항은 다음과 같습니다.

항목 항목은 노드 또는 속성입니다.

항목 객체 조작에 대한 자세한 내용은 Javadocs 인터페이스 javax.jcr.Item의

노드(및 해당 속성) 노드 및 해당 속성은 JCR API 2.0 사양(JSR 283)에서 정의됩니다. 컨텐츠, 개체 정의, 렌더링 스크립트 및 기타 데이터를 저장합니다.

노드는 컨텐츠 구조를 정의하고 해당 속성은 실제 컨텐츠와 메타데이터를 저장합니다.

컨텐츠 노드는 렌더링을 구동합니다. Sling은 들어오는 요청에서 컨텐츠 노드를 가져옵니다. 이 노드의 sling:resourceType 속성은 사용할 Sling 렌더링 구성 요소를 가리킵니다.

JCR 이름인 노드를 Sling 환경에서도 리소스라고 합니다.

예를 들어 현재 노드의 속성을 가져오려면 스크립트에서 다음 코드를 사용할 수 있습니다.

PropertyIterator properties = currentNode.getProperties();

currentNode가 현재 노드 개체인 경우

노드 객체 조작에 대한 자세한 내용은 Javadocs.

위젯 AEM에서 모든 사용자 입력은 위젯에 의해 관리됩니다. 종종 컨텐츠 편집을 제어하는 데 사용됩니다.

대화 상자는 위젯을 결합하여 만들어집니다.

AEM은 위젯의 ExtJS 라이브러리를 사용하여 개발되었습니다.

대화 상자 대화 상자는 특별한 유형의 위젯입니다.

컨텐츠를 편집하려면 AEM에서 애플리케이션 개발자가 정의한 대화 상자를 사용합니다. 일련의 위젯을 조합하여 사용자에게 관련 컨텐츠를 편집하는 데 필요한 모든 필드와 작업을 제공합니다.

대화 상자는 메타데이터를 편집하는 데, 다양한 관리 도구에서도 사용됩니다.

구성 요소 소프트웨어 구성 요소는 사전 정의된 서비스 또는 이벤트를 제공하며 다른 구성 요소와 통신할 수 있는 시스템 요소입니다.

AEM 내에서 구성 요소는 종종 리소스의 컨텐츠를 렌더링하는 데 사용됩니다. 리소스가 페이지인 경우, 렌더링을 수행하는 구성 요소를 최상위 구성 요소 또는 Pageconent라고 합니다. 그러나 구성 요소는 컨텐츠를 렌더링하거나 특정 리소스에 연결할 필요가 없습니다. 예를 들어 탐색 구성 요소에는 여러 리소스에 대한 정보가 표시됩니다.

구성 요소의 정의에는 다음이 포함됩니다.

템플릿 템플릿은 특정 유형의 페이지에 대한 기준입니다. 웹 사이트 탭에서 페이지를 만들 때는 템플릿을 선택해야 합니다. 그런 다음 이 템플릿을 복사하여 새 페이지를 만듭니다.

템플릿은 만들 페이지와 구조가 동일하지만 실제 컨텐츠는 없는 노드 계층 구조입니다.

페이지 및 기본 컨텐츠(기본 최상위 컨텐츠)를 렌더링하는 데 사용되는 페이지 구성 요소를 정의합니다. 컨텐츠는 AEM이 컨텐츠 중심으로서 렌더링되는 방식을 정의합니다.

페이지 구성 요소(최상위 구성 요소) 페이지를 렌더링하는 데 사용할 구성 요소입니다.

페이지 페이지는 템플릿의 '인스턴스'입니다.

페이지에는 cq:Page 유형의 계층 노드 및 cq:PageContent 유형의 컨텐츠 노드가 있습니다. 컨텐츠 노드의 sling:resourceType 속성은 페이지 렌더링에 사용되는 페이지 구성 요소를 가리킵니다.

예를 들어 현재 페이지의 이름을 가져오려면 스크립트에서 다음 코드를 사용할 수 있습니다.

String pageName = currentPage.getName();

currentPage가 현재 페이지 개체인 경우 페이지 개체 조작에 대한 자세한 내용은 Javadocs.

페이지 관리자 페이지 관리자는 페이지 수준 작업에 대한 메서드를 제공하는 인터페이스입니다.

예를 들어 리소스의 포함 페이지를 가져오려면 스크립트에서 다음 코드를 사용할 수 있습니다.

Page myPage = pageManager.getContainingPage(myResource);

pageManager가 페이지 관리자 개체이고 myResource가 리소스 개체인 경우. 페이지 관리자에서 제공하는 방법에 대한 자세한 내용은 Javadocs.

리포지토리 내의 구조 structure-within-the-repository

다음 목록은 리포지토리 내에 표시되는 구조에 대한 개요를 제공합니다.

환경 environments

AEM을 사용하는 프로덕션 환경은 종종 두 가지 유형의 인스턴스로 구성됩니다. an 작성자 및 게시 인스턴스.

디스패처 the-dispatcher

Dispatcher는 캐싱 및/또는 로드 밸런싱 모두를 위한 Adobe의 도구입니다. 자세한 내용은 디스패처.

FileVault(소스 수정 시스템) filevault-source-revision-system

FileVault는 JCR 저장소에 파일 시스템 매핑 및 버전 제어를 제공합니다. 프로젝트 코드, 컨텐츠, 구성 등을 표준 버전 제어 시스템(예: Subversion)에서 저장 및 버전 관리하는 데 완벽하게 지원되는 AEM 개발 프로젝트를 관리하는 데 사용할 수 있습니다.

자세한 내용은 FileVault 도구 자세한 내용은 설명서 를 참조하십시오.

워크플로 workflows

컨텐츠는 여러 참여자의 승인 및 로그오프와 같은 단계를 포함하여 조직 프로세스를 따르는 경우가 많습니다. 이러한 프로세스는 워크플로우로 표시될 수 있습니다. AEM 내에서 정의 및 개발에 적용된 다음 적절한 컨텐츠 페이지 또는 디지털 자산 필요한 경우.

워크플로우 엔진은 워크플로우의 구현을 관리하고 컨텐츠에 대한 후속 애플리케이션을 관리하는 데 사용됩니다.

다중 사이트 관리 multi-site-management

MSM(Multi Site Manager)을 사용하면 공통 컨텐츠를 공유하는 여러 웹 사이트를 쉽게 관리할 수 있습니다. MSM을 사용하면 한 사이트의 컨텐츠 변경 사항이 다른 사이트에 자동으로 복제되도록 사이트 간의 관계를 정의할 수 있습니다.

예를 들어, 웹 사이트는 국제 대상을 위해 여러 언어로 제공되는 경우가 많습니다. 동일한 언어의 사이트 수가 낮으면(3~5개) 사이트 간에 컨텐츠를 동기화하는 수동 프로세스를 수행할 수 있습니다. 그러나 사이트 수가 증가하거나 여러 언어가 사용되는 즉시 프로세스를 자동화하는 것이 더 효율적입니다.

자세한 내용은 다중 사이트 관리자.