Adobe Experience Manager (AEM) (以及之前的CQ)一直使用覆蓋原則來讓您擴充及自訂 主控台 和其他功能(例如, 頁面製作)。
覆蓋是許多內容中使用的辭彙。 在此情境中(擴充AEM),覆蓋是指採用預先定義的功能,並將您自己的定義強加於此功能(以自訂標準功能)。
在標準例項中,預先定義的功能儲存在 /libs
而且建議您在下定義覆蓋(自訂) /apps
分支。 AEM使用搜尋路徑來尋找資源,先搜尋 /apps
分支,然後是 /libs
分支( 可設定搜尋路徑)。 此機制表示您的覆蓋(以及其中定義的自訂)有優先權。
自AEM 6.0起,覆蓋的實作與使用方式已發生變更:
AEM 6.0及更高版本 — 適用於 Granite — 相關覆蓋圖(即觸控式UI)
方法
重新建構適當的 /libs
結構於 /apps
.
這不需要一對一複製, Sling資源合併 用於互動參照所需的原始定義。 Sling Resource Merger提供的服務可存取及合併具有不同(差異)機制的資源。
在 /apps
,進行任何變更。
優點
/libs
.AEM 6.0之前的非Granite覆蓋圖和覆蓋圖
方法
複製內容來源 /libs
至 /apps
複製整個子分支,包括屬性。
在 /apps
,進行任何變更。
缺點
/libs
,您可能必須重新建立下覆蓋圖中所發生的特定變更 /apps
.針對許多變更,建議使用覆蓋圖,例如 設定您的主控台 或 在側面板中的資產瀏覽器中建立您的選取範圍類別 (用於編寫頁面)。 其需求為:
不要 變更 /libs
分支您所做的任何變更都可能會遺失,因為每當您:
這些功能可將您的變更集中在一個位置;如有需要,讓您更輕鬆地追蹤、移轉、備份或偵錯變更。
對於覆蓋圖,傳送的資源是擷取的資源和屬性的彙總,取決於可定義的搜尋路徑:
資源 解析程式搜尋路徑 如 OSGi設定 針對 Apache Sling Resource Resolver Factory.
/apps
, /libs
— 所以內容屬於 /apps
的優先順序高於 /libs
(也就是說 覆蓋 it)。兩位服務使用者需要有JCR:READ存取權才能存取儲存指令碼的位置。 這些使用者是: components-search-service (由com.day.cq.wcm.coreto使用)和sling-scripting (由org.apache.sling.servlets.resolver使用來尋找servlet)。
下列設定也必須根據您放置指令碼的位置(此範例中位於/etc、/libs或/apps下)進行設定。
PID = org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
resource.resolver.searchpath=["/etc","/apps","/libs"]
resource.resolver.vanitypath.whitelist=["/etc/","/apps/","/libs/","/content/"]
最後,也必須設定Servlet Resolver (在此範例中,亦要新增/etc)
PID = org.apache.sling.servlets.resolver.SlingServletResolver
servletresolver.paths=["/bin/","/libs/","/apps/","/etc/","/system/","/index.servlet","/login.servlet","/services/"]
以下情形會說明部分範例: