Как найти полный путь к URL страницы в диалоге AEM Touch UI

Question

У нас есть структура сайта, как показано ниже:

Site:
  --Brand
     --Market
         --Language
             --Page1

Допустим, мой пользовательский компонент перетащен в Page1. Теперь в диалоговом окне прослушивания я хочу найти параметры Market и Language по пути к странице.

Как добиться этого в TouchUI диалоге AEM?

Answer 1

Есть два варианта, которые я знаю. Один из них простой, но не "надежный", а другой более сложный, но и более надежный.

Вариант № 1: простое решение

В TouchUI у вас есть доступ к так называемой "информации о странице" в JavaScript. Ваш слушатель диалога может получить доступ к этой "информации о странице", чтобы получить абсолютный путь к контенту, а затем проанализировать строку.

Это может выглядеть так:

(function ($, $document, author) {
    "use strict";

    $document.on("dialog-ready", function() {
        var path = author.page.path;
    });


})($, $(document), Granite.author);

Очевидно, вы должны разобрать path строковая переменная, чтобы получить части пути, которые вас интересуют.

Хочу отметить, что JavaScript "переменная" Granite.author.page содержит много интересной информации о текущей странице, компонентах и ​​т. д.

Теперь к важной части: это простой способ решить вашу проблему, но разбор строк всегда будет хрупким решением. Лично я бы сказал, что синтаксический анализ строк следует считать плохой практикой, и его следует избегать любой ценой. Таким образом, я хочу предложить лучшее решение с Вариантом № 2.

Вариант № 2: (Более) комплексное решение

В варианте № 1 я предложил использовать "информацию о странице", предоставляемую TouchUI, чтобы получить полный путь к странице, а затем проанализировать путь. Вариант № 2 основывается на этом, но улучшает подход, расширяя информацию, предоставляемую "информацией о странице".

Чтобы расширить "информацию о странице", вы должны создать сервис OSGi, который реализует следующий интерфейс:

com.day.cq.wcm.api.PageInfoProvider

Ваш PageInfoProvider будет вызываться при каждом запросе, а затем сможет добавить информацию в предоставленный JSONObject,

Это означает, что вы могли бы написать некоторую бизнес-логику, которая:

1. получает правильный AEM Page экземпляр либо из предоставленного request или же resource,
2. получает страницу рынка и языка со страницы.

Код для этого может выглядеть так:

import com.day.cq.wcm.api.PageInfoProvider;
import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.resource.Resource;
import org.apache.sling.commons.json.JSONException;
import org.apache.sling.commons.json.JSONObject;
import org.osgi.service.component.annotations.Component;

@Component
public class MyPageInfoProvider implements PageInfoProvider {

    @Override
    public void updatePageInfo(final SlingHttpServletRequest request,
                               final JSONObject pageInfo,
                               final Resource resource) throws JSONException {

        // get market
        // get languagepage

        pageInfo.put("market", market);
        pageInfo.put("languagepage", languagepage);
    }
}

Я бы посоветовал вам использовать специальные типы ресурсов для ваших рынков и языковых страниц. Таким образом, было бы легко написать другой сервис OSGi, который вы можете передать Page Затем он будет определять рынок страниц и языковую страницу, обходя дерево контента до тех пор, пока не будет найдена страница с требуемым типом ресурса.

Слушателю диалога теперь может понравиться это:

(function ($, $document, author) {
    "use strict";

    $document.on("dialog-ready", function() {
        var market = author.pageInfo.market;
        var languagepage = author.pageInfo.languagepage;
    });


})($, $(document), Granite.author);

Это решение гораздо более надежно, потому что не выполняется разбор строк, и весь код Java может быть покрыт соответствующими модульными тестами.