AEM에 기여 contributing-to-aem

개발 방법론 development-methodology

AEM은 대규모 오픈 소스 프로젝트에서 일반적으로 실행되는 검증된 방법론에 따라 개발됩니다. AEM의 기술 스택에 있는 많은 핵심 요소는 실제로 Apache Software Foundation에 기여한 Sling 및 Jackrabbit과 같은 활성 오픈 소스 프로젝트로 유지됩니다. AEM에 있는 이 정신의 주요 측면은 사용 가능한 메일링 목록과 온라인 포럼을 사용하여 개발 팀과의 직접적인 상호 작용을 권장한다는 것입니다.

AEM의 구성 요소에 기여하는 경우 오픈 소스 프로젝트에 기여하는 것처럼 AEM에 대해 숙지하고, 그러한 프로젝트에 기여하려는 것처럼 기존 핵심 팀과 커뮤니케이션하십시오.

필수 경험 required-experience

하이퍼텍스트 전송 프로토콜 (HTTP)은 우리가 하는 모든 것에 핵심입니다. 따라서 AEM에 기여하기 전에 스레드 풀링으로 다중 스레드 HTTP 서버의 자체 Java™ 구현을 작성할 수 있는 범위 내에서 HTTP에 대해 깊이 있게 이해해야 합니다. 또한 HTTP/1.1 keep-alive 비헤이비어를 이해하고 JavaScript과의 서버/클라이언트측 상호 작용, 특히 AJAX으로 표현되는 비동기 상호 작용 스타일에 대한 깊이 있는 지식이 있어야 합니다.

페이지 역동성과 대화형 콘텐츠는 WM 경험의 핵심이므로 문서 객체 모델과 이벤트에 대한 프로그래밍 방식 조작의 가능성에 대해 상당히 깊이 있게 이해해야 합니다. 예를 들어 여러 브라우저 문서(예: iframe 사용)에 대한 실시간 DOM 조작 및 드래그 앤 드롭 동작에 대한 일부 지식이 있어야 합니다.

가장 높은 수준에서 다음을 확실히 이해해야 합니다.

Adobe Experience Manager의 기술 스택은 Apache Sling 웹 프레임워크와 함께 Apache Felix OSGI 컨테이너를 기반으로 하며 Apache Jackrabbit을(를) 기반으로 Java™ 콘텐츠 저장소(JCR)를 임베드합니다. 이러한 개별 프로젝트 및 기여하려는 영역에서 사용되는 기타 오픈 소스 구성 요소(예: Apache Lucene)에 대해 숙지하십시오.

부족의 지식 tribal-knowledge

어떤 개념과 지도 원리는 이전 시대의 문화에서 깊이 배어 있다. 이 섹션에는 알고 있어야 하는 "심층 DNA 포함" 문제 중 일부가 나열되어 있습니다.

모든 것이 콘텐츠임 everything-is-content

컨텐츠에는 웹 애플리케이션이 지속하는 모든 데이터만 포함됩니다. 모든 종류의 프로그램 코드, 라이브러리, 스크립트, 템플릿, HTML, CSS, 이미지 및 아티팩트는 콘텐츠 리포지토리에서 유지되고 패키지 관리자 및 패키지 공유를 통해 패키지 형태로 가져오거나 내보냅니다.

David의 모델 david-s-model

Java™ 콘텐츠 리포지토리에서 콘텐츠를 모델링하는 방식은 소프트웨어 업계에서 일반적으로 관계형 환경에서 데이터 모델링을 수행하는 방식과 완전히 다른 방식의 사고가 필요합니다. JCR 방식으로 콘텐츠 관리에 새로 들어오는 모든 사용자에게 필수적인 읽기는 David의 모델: 콘텐츠 모델링 가이드입니다.

나머지 정도 restfulness

REST 접근은 우리가 하는 일에 깊이 배어 있다. 즉, 특히 상태 저장 상호 작용을 피하고 URI가 컨텐츠 및 서비스에 대한 결정적인 주소라는 점을 염두에 두십시오.

REST(RePresentational State Transfer)는 World Wide Web이 기반으로 하는 소프트웨어 아키텍처 스타일을 나타냅니다. 이 안내서에서는 웹 작업을 수행하는 주요 요소에 대해 설명하고 웹 기반 소프트웨어를 디자인하는 방법에 대한 일련의 원칙을 제공합니다. 따라서 웹을 통해 사용할 API를 디자인할 때 이러한 "모범 사례"를 준수하는 것이 적절합니다.

REST는 우리가 하는 많은 일의 이면에 지도 철학을 제공하기 때문에, 당신은 RESTful 디자인의 신조를 잘 숙지하는 것이 필수적이라고 생각해야 합니다. Roy Fielding의 논문을 시작하는 것이 좋습니다.

Sling 요청 해결 sling-request-resolution

AEM에 대해 이해해야 할 주요 측면은 들어오는 요청이 콘텐츠 및 애플리케이션 동작과 어떻게 관련되는지, 콘텐츠가 콘텐츠 리포지토리에서 어떻게 구조화되는지, AEM에서 요청을 처리할 애플리케이션 로직을 찾는 위치입니다. Apache Sling URL 분해과 REST 아키텍처 스타일과 상태 비저장, 캐시 가능 및 계층화된 시스템 제약 조건을 적용하는 방법에 대해 알아봅니다.

Apache Sling의 요청 해결에 대해 이해해야 할 주요 사항은 요청이 주로 콘텐츠 저장소의 특정 리소스에 매핑되는 방법, 요청의 추가 속성 및 이러한 콘텐츠 객체의 속성과 함께 콘텐츠를 렌더링하기 위해 호출되는 애플리케이션 코드를 결정하는 방법, /apps의 코드가 /libs의 코드를 재정의하는 방법입니다.

Quickstart quickstart

3단계 없음: 설치 및 실행하려면 Quickstart JAR 파일을 다운로드하여 두 번 클릭합니다. 3단계는 없습니다. 추가 옵션 기능은 패키지 공유에서 적절한 패키지를 설치하는 것 외에는 필요하지 않습니다.

작은 Quickstart 크기: Quickstart JAR 파일의 크기를 최소한으로 유지합니다. 라이브러리를 지능적이고 최적화된 방식으로 사용하여 선택적 기능을 패키지 공유로 이동합니다.

시작 시간 단축: 시작 시간에 영향을 줄 수 있는 변경 사항을 적용할 경우 더 오래 걸리지 않고 더 짧게 적용해야 합니다.

야위고 평균 lean-and-mean

우리는 가볍고, 작고, 빠르고, 우아한 코드와 프로젝트를 선호합니다. "충분히 좋다"는 것만으로는 충분하지 않습니다.

코드 재사용: 당사의 OSGi 기반 제품 아키텍처와 "모든 것이 콘텐츠입니다" 철학은 코드와 아티팩트를 재사용할 수 있는 기회가 비정상적으로 좋다는 것을 의미합니다. 우리는 가능한 한 그 사실을 이용해서 특징들을 희미하게 유지하려고 노력한다.

느슨한 결합 : 우리는 엄격한 종속성과 "원치 않는 친밀감"보다 느슨하게 결합된 상호 작용을 선호합니다. 느슨한 결합을 통해 더 많은 코드를 재사용할 수 있습니다.

데모를 중단하지 마십시오. don-t-break-the-demo

데모에서 가장 자주 표시되는 데모 스크립트 및 제품 기능에 익숙해지십시오. 어떤 작업도 "데모 스크립트" 기능을 중단하면 안 된다는 것을 이해합니다. 핵심 제품은 개발 중에도 항상 데모를 준비해야 합니다.

안정성 설계 design-for-reliability

단일 DOM 요소의 문제로 인해 전체 페이지가 렌더링되지 않도록 실패-소프트 방식으로 기능을 디자인하고 코딩하려고 합니다. 즉, 치명적이고 치명적이어야 할 것을 만드는 것이다. 다른 건 다 살릴 수 있게 해 제품을 "용서함"으로 만드세요.

이상: 새로운 정상 abnormal-is-the-new-normal

종료 후크에 의존하지 말고 시작 시 정리하십시오. 비정상 종료는 정상 종료입니다.

shutdown == kill -9 == power outage

탄력적인 클러스터링 준비 be-ready-for-elastic-clustering

항상 탄력적인 클러스터링을 준비하십시오. 항상 클러스터링이 있다고 가정하십시오. 일반적으로 컨텐츠 저장소에 있는 모든 항목을 준수한다는 것은 클러스터링 지원이 내장된 것을 의미합니다.

이전 버전과의 호환성을 위한 설계 design-for-backward-compatibility

어떤 작업도 고객의 기존 코드를 위반해서는 안 됩니다. 업그레이드 중에 업데이트할 수 있는 제품 코드를 포함하려면 /libs만 고려하십시오. 저장소의 /apps 섹션은 프로젝트 코드이며 /etc 섹션에는 유지해야 하는 사용자 지정 구성이 포함되어 있습니다. 일반적으로 /apps, /content 및 /home의 항목을 덮어쓰지 않습니다. 업그레이드 후에도 이전 프로젝트 코드, 구성 및 콘텐츠는 업그레이드 전과 마찬가지로 계속 작동해야 합니다.

이전 버전과의 호환성을 위해 설계하면 업그레이드 환경이 초기 설치의 단순성과 일치하도록 할 수도 있습니다. AEM을 중지하고 Quickstart JAR 파일을 교체한 다음 AEM을 다시 시작하면 됩니다. 설치 기반이 급속히 확대됨에 따라 업그레이드 효율성이 점점 더 중요한 이점이 되고 있습니다.

기존 API는 더 나은 기능이 최신 API를 대체할 경우 더 이상 사용되지 않는 것으로 표시될 수 있으며 표시해야 하지만, 이전 5.x 릴리스에서 공개되었던 모든 API는 사용자 정의 애플리케이션 코드에서 사용 중일 수 있으므로 계속 작동해야 합니다. 이러한 API는 제거해서는 안 됩니다.

콘텐츠 구조 및 사용자 경험의 일반적인 일관성과 관련하여 이전 버전과의 호환성도 염두에 두어야 합니다.

핵심 개념 core-concepts

작성자 인스턴스 - 일반적으로 보안, 거버넌스 및 기타 이유로 프로덕션 사이트는 AEM 인스턴스를 작성자 인스턴스와 Publish 인스턴스로 나눕니다. 배포 아키텍처(작성자/Publish 인스턴스 포함)에 대한 자세한 내용은 AEM 인스턴스에 대한 설명서를 참조하십시오.

캐싱, 튀김 및 굽기 - 일반적으로 굽기와 튀김 개념은 서로 다른 웹 콘텐츠 관리 시스템 간의 중요한 차이점입니다. CMS 전문 용어에서 "baking"은 게시 시간에 데이터를 정적 파일로 커밋하는 개념을 의미하고 "frying"은 요청 시간에(즉, 적시에) 최종 프레젠테이션을 위해 데이터를 처리하는 개념을 의미합니다.

클러스터링 및 로드 밸런싱 - 프로덕션 환경의 가용성을 높이고 성능을 향상시키기 위해 여러 작성자 및/또는 Publish 인스턴스를 다른 사용자 그룹에서 사용하거나 Dispatcher 구성 뒤에서 로드 밸런싱을 수행하여 여러 작성자 및/또는 인스턴스를 클러스터로 결합하는 것이 일반적입니다.

콘텐츠 저장소의 여러 인스턴스를 결합하여 고가용성 JCR 솔루션을 만들 수도 있습니다. 그런 다음 AEM 솔루션과 통합하여 하드웨어 및 소프트웨어 오류에 대한 보호를 극대화할 수 있습니다. 자세한 내용은 권장 배포를 참조하십시오.

구성 요소 - AEM에서 구성 요소는 일반적으로 Sidekick에서 드래그 앤 드롭하여 만들 수 있는 개체 유형입니다. 따라서 예를 들어 AEM과 함께 제공되는 즉시 사용 가능한 구성 요소에는 텍스트, 제목, 태그 클라우드, 회전 메뉴, 이미지 및 목록 구성 요소가 모두 런타임 시 Sidekick에서 사용할 수 있습니다.

콘텐츠 파인더 - 작성 모드에서 콘텐츠 파인더는 페이지 왼쪽에 있는 특수 패널(프레임)이며, 맨 위에서 선택한 탭에 따라 콘텐츠 파인더에서 작업 중인 페이지로 드래그하여 놓을 수 있는 이미지, 문서, Flash 에셋, 페이지, 단락 또는 저장소 리소스 목록을 표시합니다.

디지털 자산 - AEM에서 Digital Assets은 일반적으로 이미지와 리치 미디어 파일입니다. 자세한 내용은 DAM에서 Digital Assets 작업 을 참조하십시오.

Dispatcher - Dispatcher은 캐싱 및 부하 분산 도구이며 특정 보안 보호 기능을 제공합니다.

ExtJS 위젯 - AEM의 대부분의 사용자 인터페이스 요소는 JavaScript에서 작성된 서드파티 위젯 라이브러리인 ExtJS를 사용합니다. ExtJS는 고성능의 사용자 정의 가능한 UI 위젯과 잘 설계되고 확장 가능한 구성 요소 모델을 제공합니다.

JCR, Java™ Content Repository - Java™ Content Repository 사양(JSR-283)은 파일 시스템과 개체 데이터베이스의 기능을 결합하는 대규모로 확장 가능한 NoSQL 데이터 저장소를 구현하기 위한 추상 데이터 모델과 응용 프로그램 프로그래밍 인터페이스를 모두 제공합니다. JSR-283을 완전히 상세하게 이해할 필요는 없지만 AEM의 "모든 것이 콘텐츠"라는 철학을 가능하게 하는 것이 JCR이기 때문에 JCR의 기본 기능과 기본 데이터 모델을 숙지하는 데 시간을 투자해야 합니다.

기본적으로 JCR은 노드 및 속성의 시스템으로서, 노드가 다른 노드에서 상속할 수 있고 모든 콘텐츠는 속성 값(으)로 저장됩니다. JCR에서는 일반 상속 외에도 "mixin" 노드 개념을 사용할 수 있으므로 여러 상속을 모델링할 수 있습니다.

JCR에는 사전 정의된 노드 유형 및 속성 유형이 여러 개 있지만 일반적으로 입력 시스템이 유연하며 정형 및 비정형 콘텐츠를 동일한 방식으로 저장/관리할 수 있다는 것이 JCR의 강점 중 하나입니다. 즉, JCR은 고도로 구조화된 데이터를 수용할 수 있지만 스키마 제약 없이 임의의 동적 데이터 구조도 수용할 수 있다.

JCR의 Java™ API용 JavaDoc은 여기입니다.

JavaDoc 또는 JCR 사양 자체를 읽기 전에 Adobe Experience Services에 의해 구현된 JCR의 이 고급 설명을 살펴볼 수 있습니다.

MSM(다중 사이트 관리자) - AEM의 MSM 기능은 고객이 다국어 및 다국적 콘텐츠를 처리할 수 있도록 지원하므로 중앙 집중식 브랜딩과 지역화된 콘텐츠의 균형을 맞출 수 있습니다.

OSGi - OSGi는 AEM에서 모듈화된 Java™ 개발의 기반을 제공하는 서비스 기반 런타임 기술입니다. 코드 리소스(번들로 알려짐)에 대한 매우 동적이고 안전한 클래스 로딩 및 실행 환경뿐만 아니라 번들에 의해 노출된 다양한 서비스의 가시성과 라이프사이클에 대한 완전한 제어를 제공하는 프레임워크입니다. 서비스 레지스트리는 라이프사이클 역학(및 버전 요구 사항)을 고려하는 번들에 대한 협력 모델을 제공합니다. OSGi는 애플리케이션 서버가 해결하려고 했던 많은 문제를 해결하지만, 가볍고 동적인 방식으로 해결하므로, 예를 들어 서비스를 핫 배포(서버를 다시 시작하지 않고 새 코드를 즉시 사용 가능)할 수 있습니다.

Parsys, 단락 시스템 - 단락 시스템(parsys)은 작성자가 페이지에 다른 형식의 구성 요소를 추가할 수 있고 다른 단락 구성 요소를 포함하는 복합 구성 요소입니다. 각 단락 유형은 구성 요소로 표시됩니다. 단락 시스템 자체는 다른 단락 구성 요소를 포함하는 구성 요소이기도 합니다.

마이크로커널 - 저장소의 모든 작업 영역은 특정 마이크로커널(데이터의 읽기 및 쓰기를 관리하는 클래스)을 통해 해당 데이터를 저장하도록 별도로 구성할 수 있습니다. 유사하게, 저장소 전체 버전 저장소는 또한 특정 마이크로커널을 사용하도록 독립적으로 구성될 수 있다. 다양한 파일 형식 또는 관계형 데이터베이스에 데이터를 저장할 수 있는 여러 가지 다른 마이크로커널이 있습니다. (예를 들어 MongoDB, DB2® 또는 Oracle에 대한 지속성 관리자가 있습니다.) AEM의 기본 마이크로커널은 TarMK입니다(아래 추가 참조).

Publish 인스턴스 - 보안, 거버넌스 및 기타 이유로 프로덕션 사이트는 일반적으로 AEM 인스턴스를 작성자 및 Publish 인스턴스로 나눕니다. 배포 아키텍처(작성자/Publish 인스턴스 포함)에 대한 자세한 내용은 AEM 인스턴스에 대한 설명서를 참조하십시오.

Quickstart - 다른 많은 프로그램과 달리 AEM은 "Quickstart" 자동 압축 해제 JAR 파일 하나를 사용하여 설치합니다. JAR 파일을 처음 두 번 클릭하면 필요한 모든 항목이 자동으로 설치됩니다. quickstart JAR에는 CRX 저장소(관리 기능 포함), 가상 저장소 서비스, 인덱스 및 검색 서비스, 워크플로 서비스, 보안 및 웹 서버에 필요한 모든 파일과 CQSE(CQ Servlet Engine) 및 모든 AEM 서비스가 포함됩니다. 설치할 다른 파일이 없습니다. Quickstart는 자체 포함되어 있습니다.

빠른 시작을 처음 시작하면 백그라운드에서 전체 JCR 호환 저장소가 생성되며, 이 작업은 몇 분 정도 걸릴 수 있습니다. 이 초기 시작 후에는 저장소 인프라가 이미 구축되었기 때문에 후속 시작이 훨씬 빠릅니다.

활성 포트 번호 및 해당 AEM 인스턴스가 Publish 인스턴스여야 하는지 여부와 작성자 인스턴스여야 하는지 여부 등 여러 시작 옵션을 빠른 시작 파일의 이름을 적절하게 변경하여 제어할 수 있습니다. 이와 관련된 옵션 목록을 보려면 명령줄에서 "-help"를 사용하여 JAR을 실행하십시오.

java -jar <quickstartfilename>.jar -help

복제 에이전트 - 복제 에이전트는 작성자 환경에서 게시 환경으로 콘텐츠를 Publish(활성화)하고, Dispatcher 캐시에서 콘텐츠를 플러시하고, Publish 환경에서 작성자 환경으로 사용자 생성 콘텐츠(예: 양식 입력)를 반환하는 데 사용되는 메커니즘으로 AEM의 중심입니다.

스캐폴딩 - 스캐폴딩으로 페이지에 대해 원하는 구조를 반영하는 필드가 있는 양식(스캐폴드)을 만든 다음 이 양식을 사용하여 이 구조를 기반으로 페이지를 쉽게 만들 수 있습니다.

세그먼테이션 - 사이트 방문자가 사이트를 방문할 때 서로 다른 관심사와 목표를 갖습니다. 방문자의 목표를 이해하고 기대치를 충족하는 것은 온라인 마케팅의 중요한 성공 전제 조건입니다. 세그먼테이션은 방문자의 세부 사항을 분석하고 특성화하여 이를 달성하는 데 도움이 됩니다.

Sidekick - Sidekick은 편집 가능한 페이지에 나타나는 팔레트 모양의 부동 창입니다. 이 창에서 새 구성 요소를 드래그하고 페이지에 적용되는 작업을 실행할 수 있습니다.

사이트 촉매 - SiteCatalyst은 마케터에게 여러 마케팅 채널에서 모든 온라인 이니셔티브의 통합 데이터를 측정, 분석 및 최적화할 수 있는 단일 위치를 제공합니다. Adobe SiteCatalyst을 사용하여 AEM 웹 사이트의 데이터를 분석할 수 있습니다.

Tar 저장소(TarMK) - TarMK는 AEM의 기본 지속성 시스템입니다. AEM은 다른 지속성 시스템(예: MongoDB)을 사용하도록 구성할 수 있지만 TarMK는 일반적인 JCR 사용 사례에 맞게 성능이 최적화되어 있고(따라서 속도가 빠름), 업계 표준 데이터 형식을 사용하며, 빠르고 쉽게 백업할 수 있다는 점에서 일정한 이점이 있습니다.

템플릿 - AEM에서 템플릿이 특정 페이지 유형을 지정합니다. 페이지 구조를 정의합니다(일반적으로 썸네일 이미지와 다양한 속성을 지정함). 예를 들어 제품 페이지, 사이트 맵 및 연락처 정보에 대해 별도의 템플릿이 있을 수 있습니다.

워크플로 - AEM 워크플로 시스템을 사용하면 페이지 또는 에셋과 관련된 자동화된 프로세스를 만들 수 있습니다.