JCR/Sling. Имеет ли смысл, чтобы свойство узла содержало значение JSON, ИЛИ должны быть созданы соответствующие подузлы?

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

Например, допустим, я хочу сохранить набор из Link объектов, каждый из которых содержит свойства href и title.

Это можно сохранить двумя способами:

[1] Каждая ссылка как отдельный узел:

 component
    ├── link_1
    │   ├── .href  = "#1"
    │   └── .title = "T1"
    └── link_2
        ├── .href  = "#2" 
        └── .title = "T2"

[2] Как свойство JSONArray под component:

 component
    └── .links = [{"href":"#1", "title":"T1"}, {"href":"#2", "title":"T2"}]

Написав это, я думаю, что ответил на свой вопрос...

Несмотря на то, что вариант [2] привлекателен для разработки компонентов, он кажется излишним, когда моделирование данных JCR/Sling уже обеспечивает такую ​​иерархию.

  • Я правильно это понимаю?

  • Я знаю, что можно экспортировать Resourceas JSON, но можно ли импортировать/создать SyntheticResource из JSON?

    • If not that, when would one use SyntheticResource
  • Было бы лучше хранить узлы link под отдельным родительским узлом для организации?

component └── links ├── link_1 │   ├── .href = "#1" │   └── .title = "T1" └── link_2 ├── .href = "#2" └── .title = "T2"


aem sling jcr
person lyma    schedule 21.12.2018    source источник
comment
Я бы сказал, это зависит от вашего пользовательского случая. Но поскольку это компонент, я предполагаю, что вы используете составное мультиполе для создания этих значений? Я написал об этом статью здесь: blogs.perficientdigital.com/2018/08/24/. Обычно я предпочитаю конструкции, которые можно легко адаптировать к модели слинга, поэтому я бы пошел по пути JCR. Хотя вам может сойти с рук использование строки JSON, но на это просто некрасиво смотреть (опять же личные предпочтения)   -  person Ahmed Musallam    schedule 21.12.2018

Ответы (1)


arrow_upward
5
arrow_downward

Я бы рекомендовал создавать узлы в jcr. Хранение в формате json может запретить вам использовать (или усложнить использование) ряда функций, предоставляемых jcr/aem, например. индексация, поиск, обработка событий, контроль доступа и т. д.

Хотя ваш пример прост, и некоторые из перечисленных выше вещей могут не применяться, это создаст проблемы, если кто-то будет хранить более сложные данные как json.

person awd    schedule 21.12.2018
comment
согласованный. мой голос будет за то, чтобы JCR просто сохранял простоту и избегал сложности. - person Saravana Prakash; 31.12.2018