AEM Core Concepts

注意

在深入探討AEM的核心概念之前,Adobe建議先完成開始開發AEM Sites檔案中的WKND教學課程,以取得AEM開發流程的概觀和核心概念的簡介。

AEM開發的必要條件

您需要下列技巧才能在AEM上進行開發:

  • Web應用程式技術的基本知識,包括:

    • request -response(XMLHttpRequest / XMLHttpResponse)週期
    • HTML
    • CSS
    • JavaScript
  • Experience Server(CRX)的使用知識,包括Content Explorer

  • 在傳統的UI中開發時,還需要具備JSP(JavaServer Pages)的基本知識,包括瞭解和修改簡單JSP範例的能力。

建議您閱讀並遵循准則和最佳實務

Java內容儲存庫

Java內容儲存庫(JCR)標準JSR 283指定了一種獨立於供應商和獨立於實施的方式,以在內容儲存庫的精細級別上雙向訪問內容。

規格領導由Adobe Research(瑞士)AG負責。

JCR API 2.0套件javax.jcr。*用於直接訪問和控制儲存庫內容。

Experience Server(CRX)和Jackrabbit

Experience Server提供AEM所建立的Experience Services,並可用來建立自訂應用程式,並內嵌以Jackrabbit為基礎的內容存放庫。

Apache Jackrabbitis是開放原始碼、完全符合規範的JCR API 2.0實作。

Sling Request Processing

Sling簡介

AEM是使用Sling建立的,此為以REST原則為基礎的Web應用程式架構,提供內容導向應用程式的輕鬆開發。 Sling會使用JCR儲存庫(例如Apache Jackrabbit),或在AEM中使用CRX Content Repository(CRX內容儲存庫)做為其資料儲存。 Sling已對Apache Software Foundation做出貢獻——如需詳細資訊,請參閱Apache。

使用Sling,要轉譯的內容類型不是第一個處理考量。 主要考量是URL是否解析為內容物件,然後可找到指令碼來執行轉譯。 這為網頁內容製作者提供絕佳的支援,讓他們建立可輕鬆依其需求自訂的頁面。

此彈性的優點在具有多種不同內容元素的應用程式中,或當您需要可輕鬆自訂的頁面時,都十分明顯。 尤其是在實作網頁內容管理系統(例如AEM解決方案中的WCM)時。

請參閱Discover Sling in 15 minutes,以取得使用Sling進行開發的第一步驟。

下圖說明Sling指令碼解析度:它說明如何從HTTP請求到內容節點,從內容節點到資源類型,從資源類型到指令碼,以及可用的指令碼變數。

瞭解Apache Sling指令碼解析度

下圖說明處理SlingPostServlet時,您可使用的所有隱藏但功能強大的請求參數,SlingPostServlet是所有POST請求的預設處理常式,提供您無限選項,以建立、修改、刪除、複製和移動儲存庫中的節點。

使用SlingPostServlet

Sling is Content Centric

Sling為​content-centric。 這表示處理會以JCR資源(儲存庫節點)的形式,將每個(HTTP)請求映射至內容時,將重點放在內容上:

  • 第一個目標是保存內容的資源(JCR節點)
  • 其次,表示或指令碼與請求的某些部分(如選擇器和/或擴展)組合從資源屬性中定位

RESTful Sling

由於內容導向的理念,Sling建置了REST導向的伺服器,因此在Web應用程式架構中具備新概念。 其優點是:

  • 非常REST風格,不只是表面上;資源和表示法在伺服器內正確建模

  • 刪除一個或多個資料模型

    • 之前需要下列項目:URL結構、業務對象、資料庫模式;
    • 現在,此功能已簡化為:URL =資源= JCR結構

URL分解

在Sling中,處理是由使用者要求的URL所驅動。 這定義了要由相應指令碼顯示的內容。 若要這麼做,會從URL擷取資訊。

如果我們分析下列URL:

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

我們可以把它分解成複合部分:

協定 主機 內容路徑 選擇器 extension 尾碼 param(s)
https:// myhost 工具/間諜 .printable.a4. html / a/b ? x=12

訊協定HTTP

機網站名稱。

content path指定要呈現的內容的路徑。與擴展結合使用;在此範例中,它們會轉譯為tools/spy.html。

selector(s)用 於轉換內容的替代方法;在此示例中,A4格式的打印機友好版本。

extensionContent 格式;也指定要用於呈現的指令碼。

尾碼 可用於指定其他資訊。

param(s)動態 內容所需的任何參數。

從URL到內容和指令碼

使用下列原則:

  • 映射使用從請求中提取的內容路徑來定位資源
  • 當找到適當的資源時,會擷取sling資源類型,並用來找出要用來呈現內容的指令碼

下圖說明所使用的機制,將在以下各節中詳細討論。

chlimage_1-86

使用Sling,您可指定要轉譯特定實體的指令碼(透過在JCR節點中設定sling:resourceType屬性)。 此機制提供比指令碼訪問資料實體(如PHP指令碼中的SQL陳述式)更多的自由,因為資源可以有多個轉譯。

將請求映射到資源

請求會細分並擷取必要的資訊。 系統將搜索儲存庫以查找請求的資源(內容節點):

  • first Sling會檢查節點是否存在於請求中指定的位置;例如,../content/corporate/jobs/developer.html
  • 如果沒有找到節點,則會丟棄擴展,並重複搜索;例如,../content/corporate/jobs/developer
  • 如果找不到節點,Sling將會傳回http code 404(Not Found)。

Sling也允許JCR節點以外的項目成為資源,但這是進階功能。

查找指令碼

當找到適當的資源(內容節點)時,會擷取​sling資源類型。 這是路徑,可找到要用於呈現內容的指令碼。

sling:resourceType所指定的路徑可以是:

  • 絕對值

  • 相對,到配置參數

    Adobe建議使用相對路徑,因為相對路徑可提升可攜性。

所有Sling指令碼都儲存在/apps/libs的子檔案夾中,會依此順序搜尋(請參閱自訂元件和其他元素)。

還需注意的一點是:

  • 當需要方法(GET、POST)時,會根據HTTP規格(例如jobs.POST.esp)以大寫指定方法(請參閱下面)

  • 支援各種指令碼引擎:

    • HTL(HTML範本語言- Adobe Experience Manager針對HTML偏好且建議的伺服器端範本系統):.html
    • ECMAScript(JavaScript)頁面(伺服器端執行):.esp, .ecma
    • Java伺服器頁(伺服器端執行):.jsp
    • Java Servlet編譯器(伺服器端執行):.java
    • JavaScript範本(用戶端執行):.jst

AEM的指定例項支援的指令碼引擎清單列在Felix Management Console(http://<host>:<port>/system/console/slingscripting)上。

此外,Apache Sling支援與其他常用指令碼引擎(例如Groovy、JRuby、Freemarker)的整合,並提供整合新指令碼引擎的方式。

使用上述範例,如果sling:resourceTypehr/jobs,則表示:

  • 以。html結尾的GET/HEAD請求和URL(預設請求類型,預設格式)

    指令碼將為/apps/hr/jobs/jobs.esp;sling:resourceType的最後一個區段會形成檔案名稱。

  • POST請求(除GET/HEAD外的所有請求類型,方法名稱必須大寫)

    POST將用於指令碼名稱。

    指令碼將為/apps/hr/jobs/jobs.POST.esp

  • 其他格式的URL,不以。html結尾

    例如../content/corporate/jobs/developer.pdf

    指令碼將為/apps/hr/jobs/jobs.pdf.esp;尾碼將添加到指令碼名稱中。

  • 具有選擇器的URL

    選擇器可用來以替代格式顯示相同的內容。 例如,印表機友好版本、RSS饋送或摘要。

    如果查看打印機友好版本,選擇器可以是​print;as in ../content/corporate/jobs/developer.print.html

    指令碼將為/apps/hr/jobs/jobs.print.esp;選取器會新增至指令碼名稱。

  • 如果未定義sling:resourceType,則:

    • 內容路徑將用於搜索適當的指令碼(如果基於路徑的ResourceTypeProvider處於活動狀態)。

      例如,../content/corporate/jobs/developer.html的指令碼將在/apps/content/corporate/jobs/中生成搜索。

    • 將使用主節點類型。

  • 如果根本找不到指令碼,則將使用預設指令碼。

    預設轉譯目前支援純文字(.txt)、HTML(.html)和JSON(.json),所有這些都會列出節點的屬性(適當格式化)。 副檔名。res(或請求副檔名沒有請求副檔名)的預設轉譯,是將資源轉存(如果可能)。

  • 對於http錯誤處理(代碼403或404),Sling會在下列任一處尋找指令碼:

    • 自訂指令碼的位置/apps/sling/servlet/errorhandler
    • 或標準指令碼/libs/sling/servlet/errorhandler/403.esp或404.esp的位置。

如果多個指令碼套用至指定的請求,則會選取最符合的指令碼。 比賽越具體,越好;換言之,無論任何請求副檔名或方法名稱相符,選擇器與選取器的匹配程度都越高。

例如,考慮請求訪問資源
/content/corporate/jobs/developer.print.a4.html
類型
sling:resourceType="hr/jobs"

假設我們在正確位置有下列指令碼清單:

  1. GET.esp
  2. jobs.esp
  3. html.esp
  4. print.esp
  5. print.html.esp
  6. print/a4.esp
  7. print/a4/html.esp
  8. print/a4.html.esp

優先順序為(8)-(7)-(6)-(5)-(4)-(3)-(2)-(1)。

除了資源類型(主要由sling:resourceType屬性定義)外,還有資源super類型。 這通常由sling:resourceSuperType屬性指示。 嘗試尋找指令碼時,也會考慮這些超類型。 資源超類型的優勢在於,它們可以形成資源的層次結構,其中預設資源類型sling/servlet/default(由預設servlet使用)實際上是根資源。

資源的資源超類型可以用兩種方式定義:

  • 按資源的sling:resourceSuperType屬性。
  • sling:resourceType指向的節點的sling:resourceSuperType屬性。

例如:

  • /

    • a

    • b

      • sling:resourceSuperType = a
    • c

      • sling:resourceSuperType = b
    • x

      • sling:resourceType = c
    • y

      • sling:resourceType = c
      • sling:resourceSuperType = a

以下類型的層次結構:

  • /x
    • [ c, b, a, <default>]
  • while /y
    • 階層為[ c, a, <default>]

這是因為/y具有sling:resourceSuperType屬性,而/x沒有,因此其超類型取自其資源類型。

Sling Scripts無法直接呼叫

在Sling中,無法直接呼叫指令碼,因為這會打破REST伺服器的嚴格概念;你會混合資源和陳述。

如果您直接呼叫表示法(指令碼),就會隱藏指令碼內的資源,因此架構(Sling)不再知道。 因此,您會失去某些功能:

  • 自動處理http方法(GET除外),包括:

    • POST、PUT、DELETE,這些處理方式都包含sling預設實作
    • sling:resourceType位置中的POST.jsp指令碼
  • 您的程式碼架構已不再簡潔,也不再像原本那樣清晰;對於大規模發展至關重要

Sling API

這會使用Sling API套件org.apache.sling。&ast;和標籤庫。

使用sling:include參照現有元素

最後考慮的是,需要參考指令碼中的現有元素。

更複雜的指令碼(匯整指令碼)可能需要存取多個資源(例如導覽、側欄、頁尾、清單的元素),並加入​resource

若要這麼做,您可以使用sling:include("/<path>/<resource>")命令。 這將有效地包括引用資源的定義,如以下語句中引用用於渲染影像的現有定義:

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

OSGI

OSGi定義了用於開發和部署模組化應用程式和庫的體系結構(也稱為Java動態模組系統)。 OSGi容器可讓您將應用程式分割為個別模組(在OSGi術語中,是包含額外中繼資訊的jar檔案,並稱為bundles),並透過下列功能管理它們之間的跨相依性:

  • 容器內實作的服務
  • 容器與您的應用程式之間的合約

這些服務和合約提供一種架構,可讓個別元素動態發現彼此以進行協作。

然後,OSGi框架可為您提供這些捆綁包的動態載入/卸載、配置和控制——無需重新啟動。

注意

有關OSGi技術的完整資訊可在OSGi網站中找到。

尤其是,其「基本教育」頁面包含一系列簡報和教學課程。

此架構可讓您使用應用程式特定模組來擴充Sling。 Sling,因此CQ5使用Apache Felix實作OSGI(Open Services Gateway計畫),並以OSGi Service Platform Release 4 Version 4.2 Specifications為基礎。 它們都是在OSGi框架內運行的OSGi捆綁包的集合。

這可讓您對安裝中的任何軟體包執行以下操作:

  • 安裝
  • start
  • 停止
  • 更新
  • 卸載
  • 查看當前狀態
  • 存取有關特定組合的更多詳細資訊(例如符號名稱、版本、位置等)

如需詳細資訊,請參閱Web ConsoleOSGI ConfigurationOSGi Configuration Settings

AEM環境中的開發物件

以下是對發展感興趣的事項:

目項目是節點或屬性。

有關控制項對象的詳細資訊,請參閱介面javax.jcr.Item的Javadocs

Node(及其屬性) Nodes及其屬性在JCR API 2.0規範(JSR 283)中定義。它們儲存內容、物件定義、轉換指令碼和其他資料。

節點定義內容結構,其屬性儲存實際內容和中繼資料。

內容節點會推動演算。 Sling會從傳入的請求取得內容節點。 此節點的屬性sling:resourceType會指向要使用的Sling轉譯元件。

A node, is a JCR name, also called a resource in the Sling environment.

例如,要獲取當前節點的屬性,可以在指令碼中使用以下代碼:

PropertyIterator properties = currentNode.getProperties();

當前節點對象為currentNode。

有關操作節點對象的詳細資訊,請參閱Javadocs

Widget 在AEM中,所有使用者輸入都由Widget管理。這些常用於控制內容的編輯。

對話方塊是結合Widget而建立的。

AEM已使用Widget的ExtJS程式庫來開發。

話方塊是特殊的介面工具集類型。

若要編輯內容,AEM會使用應用程式開發人員所定義的對話方塊。 這些工具組合了一系列Widget,以向使用者呈現編輯相關內容所需的所有欄位和動作。

對話框也用於編輯元資料,並由各種管理工具使用。

件軟體元件是提供預定義服務或事件的系統元件,能夠與其他元件通信。

在AEM中,元件通常用於轉譯資源的內容。 當資源是頁面時,轉換該資源的元件稱為頂層元件或分頁元件。 但是,元件不需要轉譯內容,也不需要連結至特定資源;例如,導覽元件將顯示多個資源的相關資訊。

元件的定義包括:,

  • 用來呈現內容的程式碼
  • 對話方塊,供使用者輸入及產生的內容設定。

本範本範本是特定頁面類型的基礎。在「網站」索引標籤中建立頁面時,使用者必須選取範本。 然後,複製此範本即可建立新頁面。

範本是節點的階層,其結構與要建立的頁面相同,但沒有任何實際內容。

它定義用於呈現頁面的頁面元件和預設內容(主要頂層內容)。 內容會定義如何呈現為AEM以內容為中心。

頁面元件(頂層元件) 用於呈現頁面的元件。

PageA 頁面是範本的「例項」。

頁面具有類型cq:Page的階層節點和類型cq:PageContent的內容節點。 內容節點的屬性sling:resourceType會指向用於轉譯頁面的Page Component。

例如,若要取得目前頁面的名稱,您可以在指令碼中使用下列程式碼:

String pageName = currentPage.getName();

當前頁面物件為currentPage。 有關控制頁面對象的詳細資訊,請參閱Javadocs

頁面 管理器頁面管理器是提供頁面層級操作方法的「介面」。

例如,要獲取資源的包含頁,您可以在指令碼中使用以下代碼:

Page myPage = pageManager.getContainingPage(myResource);

以pageManager作為頁面管理器對象,myResource作為資源對象。 有關頁面管理器提供的方法的詳細資訊,請參閱Javadocs

資料庫中的結構

以下清單概述了在儲存庫中將看到的結構。

注意

對此結構或其中的檔案進行更改時應小心謹慎。

在進行開發時,需要進行變更,但您應小心,充分瞭解所做變更的影響。

注意

您不得變更/libs路徑中的任何項目。 對於配置和其他更改,請將項目從/libs複製到/apps,並在/apps中進行任何更改。

  • /apps

    與申請有關;包含您網站專屬的元件定義。 您開發的元件可以以/libs/foundation/components中可用的現成元件為基礎。

  • /content

    為您的網站建立的內容。

  • /etc

  • /home

    使用者和群組資訊。

  • /libs

    屬於AEM核心的程式庫和定義。 /libs中的子資料夾代表現成可用的AEM功能,例如搜尋或複製。 /libs中的內容不應加以修改,因為它會影響AEM的運作方式。 您網站的特定功能應在/apps下開發(請參閱自訂元件和其他元素)。

  • /tmp

    臨時工作區。

  • /var

    系統更改和更新的檔案;例如審核記錄、統計資料、事件處理。 子資料夾/var/classes包含源和編譯表單中已從元件指令碼生成的Java servlet。

環境

有了AEM,生產環境通常包含兩種不同的例項類型:an Author and a Publish instances.

Dispatcher

Dispatcher是Adobe的快取和/或負載平衡工具。 有關詳細資訊,請參閱 Dispatcher下。

FileVault(源修訂版系統)

FileVault為JCR儲存庫提供檔案系統映射和版本控制。 它可用來管理AEM開發專案,完全支援在標準版控制系統(例如Subversion)中儲存和修訂專案程式碼、內容、設定等。

有關詳細資訊,請參閱FileVault工具文檔。

工作流程

您的內容通常受組織流程的約束,包括許可和由不同參與者簽署等步驟。 這些程式可以表示為在AEM](/docs/experience-manager-65/sites-developing/workflows-models.html?lang=zh-Hant)中定義和開發的[工作流程,然後視需要套用至適當的內容頁面數位資產

工作流引擎用於管理工作流及其後續應用程式對內容的實施。

多站點管理

Multi Site Manager(MSM)可讓您輕鬆管理多個共用共同內容的網站。 MSM可讓您定義網站之間的關係,讓一個網站的內容變更自動複製到其他網站。

例如,網站通常以多種語言提供給國際觀眾。 當相同語言的網站數量較少(3到5個)時,就可以手動跨網站同步內容。 不過,當網站數量增加或涉及多種語言時,自動化程式就會變得更有效率。

  • 有效率地管理網站的不同語言版本。

  • 根據來源網站自動更新一或多個網站:

    • 在多個網站上強制執行共同的基本結構,並使用共同內容。
    • 充份運用可用資源。
    • 保持一致的外觀和感覺。
    • 著重管理不同網站的內容。

如需詳細資訊,請參閱多網站管理員

本頁內容