Как правильно проверять селекторы и расширения через RequestPathInfo

Я работаю над компонентом, и в настоящее время я пытаюсь делать разные вещи в зависимости от селектора, выбранного для компонента.

Итак, в основном, если у меня есть компонент с этой структурой

myComponent/
  dialog.xml
  myComponent.jsp
  altView.jsp

Я знаю, что если у меня есть Node с resourceType myComponent, я могу запросить альтернативное представление через браузер, запросив path/to/component/content.altView.html, и все будет отлично.

Точно так же я могу включить cq и сделать что-то вроде:

# with cq include
<cq:include path="my/path.altView" resourceType="myComponent"/>

# or with sling include
<sling:include path="my/path" resourceType="myComponent"  replaceSelectors="altView"/>

Однако при обработке запроса я заметил интересное поведение при просмотре RequestPathInfo Объект.

Например, если мы посмотрим на все 3 вышеперечисленных случая, у меня может быть что-то вроде этого:

# http://path/to/component/content.altView.html
slingRequest.getRequestPathInfo().getSelectors(); // {altView}
slingRequest.getRequestPathInfo().getExtension(); // html

# <sling:include path="my/path" resourceType="myComponent"  replaceSelectors="altView"/>
slingRequest.getRequestPathInfo().getSelectors(); // {altView}
slingRequest.getRequestPathInfo().getExtension(); // html

# <cq:include path="my/path.altView" resourceType="myComponent"/>
slingRequest.getRequestPathInfo().getSelectors(); // []
slingRequest.getRequestPathInfo().getExtension(); // altView

Я понимаю, почему cq:include возвращает разные результаты (мы делаем запрос к my/path.altView, и .altView в данном случае совпадает с расширением). Мне любопытно, есть ли нормализованная причина для извлечения altView (или выбранного представления) независимо от того, использовалось ли оно в качестве расширения или селектора. Или, если это нормально, и мне просто нужно проверить как расширения, так и селекторы по отдельности.

i.e

selectors = get selectors();
if selectors
   do stuff
else check extensions
   do stuff

Еще раз большое спасибо за ваши идеи, это потрясающее сообщество.

[РЕДАКТИРОВАТЬ]

В ответ на ответ я подумал, что дам немного больше контекста тому, что я делаю. В основном наша структура компонентов настроена так, что каждый из наших компонентов имеет связанный класс Java, который обрабатывает бизнес-логику. (IE apps/myapp/components/myComponent будет отображаться в com.mypackage.components.MyComponent). Тем не менее, в классе моего компонента мне нужно по-разному обрабатывать поток управления в зависимости от того, как был вызван компонент (т.е. какие селекторы/расширения/и т. д. ). Например, если бы мой компонент вызывался нормально, я бы выполнял базовое поведение, но если бы он вызывался с селектором (например) altView, мне нужно было бы по-другому обрабатывать альтернативное представление, и в этом альтернативном представлении будут доступны другие данные, и т.п.

Мой вопрос был основан на том, что кажется, что я могу дать атрибуту пути тега cq:include селектор, который я хочу использовать:

<cq:include path="my/path.altView" resourceType="myComponent"/>

Однако, когда я проверяю свой RequestPathInfo в своем классе компонентов, чтобы определить рабочий процесс, altView возвращается как расширение, а не в селекторах String[]. Обратите внимание, что вышеприведенное компилируется нормально и выбирает правильный файл .jsp для рендеринга, объект RequestPathInfo просто сохраняет данные в другом месте.

Я начинаю догадываться, что размещение селектора в атрибуте пути работает, потому что модификаторы селекторов и расширений изменяют поведение одинаково. mycomponent.altView.html разрешается в altView.jsp, тогда как, если бы я выполнял mycomponent.altView, он также пытался бы разрешить mycomponent/altView.jsp так же, как он сделал бы то же самое для mycomponent.xml в mycomponent/XML.jsp


person Brodie    schedule 07.05.2014    source источник


Ответы (2)


Похоже, вы работаете над разрешением Sling. Самый простой способ сделать «разные вещи на основе селектора» в данном компоненте (скажем, my/new/component) — это создать разные средства визуализации.

Например, скажем, я запрашиваю /content/app/page.html, и на этой странице был компонент my/new/component. Или, если я запрошу /content/app/page.selector.html, я хочу, чтобы мой/новый/компонент работал немного по-другому.

В cq:component я бы создал два JSP: component.jsp и component.selector.jsp. Sling автоматически узнает на основе селектора в запрос, какой рендерер использовать. Очевидно, что каждый рендерер может создавать разные впечатления.

То же самое верно и для расширения. В примере component.jsp и component.selector.jsp фактически эквивалентны component.HTML.jsp и component.selector.HTML.jsp. HTML просто подразумевается. Однако вы можете сделать component.XML.jsp и component.selector.XML.jsp, и Sling снова выберет наиболее подходящий селектор на основе селектора(ов) и расширения запроса.

Теперь, что, если вы не хотите, чтобы селектор отображался в URL-адресе запроса страницы (на мой взгляд, вы не должны)...

Вы можете включить свой компонент с помощью sling:include и добавить селектор, как вы сделали.

The caveat is that sling:include works a little differently than cq:include, so only use this when you need to. Instead, you could also use Sling mapping to hide the selector from the user. The majority of the time I would recommend this approach.

Я не уверен, что вы пытались сделать, добавив селектор к атрибуту «путь». Я не думаю, что это что-то даст. «Путь» определяет имя ресурса (и имя узла, если ресурс не синтетический). Включение селектора в это ничего не даст, кроме того, что имя ресурса будет включать точку и селектор.

person ryanlunka    schedule 08.05.2014
comment
Спасибо за это. Однако я думаю, что мой вопрос был немного о другом. Большое спасибо за ссылку на синтетический ресурс, у меня есть несколько случаев, когда это может пригодиться. На самом деле мне было интересно узнать о концепции синтетического или фиктивного ресурса и о том, как его можно использовать. - person Brodie; 09.05.2014
comment
Теперь мне любопытно. Что я не так понял в вашем вопросе? - person ryanlunka; 09.05.2014
comment
Мне было любопытно, почему ‹cq:include path=my/path.altView resourceType=myRes/› и ‹sling:include path=my/path replaceSelectors=altView resourceType=myRes/› используют myRes/altView.jsp для рендеринга, хотя при проверке объекта RequestPathInfo cq:include имеет altView в качестве расширения, но sling:include имеет его в списке селекторов. Мне было любопытно, делает ли cq:include что-то особенное. Тем не менее, я думаю, что упускал из виду тот факт, что и селекторы, и расширения действительны при их использовании для нацеливания на определенный jsp для рендеринга. (извините, что много, чтобы вместить в комментарий) - person Brodie; 13.05.2014

Мой вопрос был основан на том, что кажется, что я могу указать атрибуту "путь" тега "cq:include" селектор, который я хочу использовать:

<cq:include path="my/path.altView" resourceType="myComponent"/> However, when I check my RequestPathInfo in my component class to

решить рабочий процесс, «altView» возвращается как расширение, а не в селекторах String[].

В отличие от тега cq:include вы можете использовать тег sling:include, который предоставляет атрибуты для изменения селекторов и суффикса в запросе:

<sling:include resourceType="myComponent" path="my/path" addSelectors="altView"/>

or

<sling:include resourceType="myComponent" path="my/path" replaceSelectors="altView"/>

Если у вас уже есть селекторы в запросе, которые вы не хотите применять к myComponent.


С точки зрения различий между Sling include и CQ include, похоже, их очень мало, за исключением того, что последний также поддерживает включение скриптов. Из документов:

Вы должны использовать <cq:include> или <sling:include>?

  • При разработке компонентов AEM Adobe рекомендует использовать <cq:include>.
  • <cq:include> позволяет вам напрямую включать файлы сценариев по их имени при использовании атрибута сценария. При этом учитывается наследование компонентов и типов ресурсов, и часто это проще, чем строгое соблюдение разрешения сценария Sling с использованием селекторов и расширений.
person anotherdave    schedule 12.05.2014