JCR/Sling - Does it make sense for a Node Property to contain a JSON value, OR should the corresponding subnodes be created?

1
votes

I am developing a fairly simple AEM component, but I'm stuck understanding the best practice.

For example, let's say I want to store a set of Link objects, each of which contains a href & title properties.

This can be stored in 2 ways:

[1] Each link as a separate node:

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

[2] As a JSONArray property beneath component:

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

After writing this out, I think I answered my own question...

Even though Option [2] is appealing for component development, it seems redundant when JCR/Sling data modeling already provides that hierarchy.

  • Am I understanding this correctly?

  • I know it is possible to export a Resourceas JSON, but is it possible to import/create a SyntheticResource from JSON?

    • If not that, when would one use SyntheticResource
  • Would I be better off storing the link nodes beneath a separate a distinct parent node for organization?

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

1
aemslingjcr
I'd say, it depends on your user-case. But since this is a component, I assume you are using a composite multi-field to author those values? I wrote an article about that here: blogs.perficientdigital.com/2018/08/24/…. I generally prefer structures that can be easily adapted to a sling model, so I'd go the JCR route. Although, you could get away with using JSON string, but it's just ugly to look at (again personal preference ) – Ahmed Musallam

1 Answers

5
votes

I would recommend creating nodes in jcr. Storing as json may prohibit you from using (or complicate the use of) a number of jcr/aem provided functionalities e.g. indexing, searching, event handling, access control etc.

Although your example is simple and some of the above listed things may not apply, it would create problems if someone were to store more complex data as json.