Pass variable from component model to author dialog

0
votes

I have a Sightly component with a (JavaScript) UseAPI model in an Adobe AEM/CQ site.

In the model, I have a variable that is calculated when the component loads and is not stored in the JCR (let's say it's a random string).

When an author opens the Granite/Touch UI dialog, there is a custom Granite UI component rendered with a JSP. The JSP has access to the scope of the component in the JCR, but as far as I can tell it does not have access to properties returned by the JavaScript model when rendering the component.

How can I pass/store this 'random string' variable from the Sightly/JavaScript UseAPI so that it can be accessed by the JSP of the dialog?

The variable is context-sensitive so I wouldn't want to store it in a permanent location such as the JCR. A good example may be a unique identifier for an external web service, that is unique for that particular rendering of the component.

1
aemsightly
Are you just trying to display the computed value in the dialog? Because it doesn't make sense to edit a purely computed value. – IT Gumby
@ITGumby the intended use is more along the lines of passing a default value or setting to the dialog, as opposed to a value that is editable – Alasdair McLeay

1 Answers

0
votes

I can think of a couple of approaches, with varying applicability:

  1. Dialog field emptyText property: This just shows grayed out/hinting text and does NOT set any content that can possibly be rendered.
  2. Dialog field defaultValue property: This looks very tempting, but I don't recall having success with it.
  3. Dialog event handlers: (adding JavaScript inside the XML of a dialog definition). I am not a fan of this approach since it isn't obvious how/where the magic happens. But it is possible to update/populate fields on dialog load or dialog save.
  4. Component cq:template: just like a page template, you can provide default content when dragging a component into a parsys. This doesn't work for components cq:included into the page/component. Also, it doesn't prevent the author from deleting the value altogether unless you add event handlers on the dialog.
  5. Create a component model. The model can provide default content/values if properties are missing or not populated. The drawback is authors may not understand where magic values are coming from if dialog fields are blank. Once I worked around this by creating a tag that would use authored values, then fall back to dialog emptyText properties, then to possible template values to "fill in" the content. This takes some initial developer effort, but provided hints to the authors if the content was missing, or the component was included instead of dragged on, ...YMMV.

However, none of these may work for you if the value is "context sensitive" and has to be calculated somewhere/somehow. But if it is computed, then it probably shouldn't be authored.