Search code examples
extjsaemsling

Is it possible to map a single dialog field to multiple JCR properties without using custom widgets?

I have a piece of configuration in my AEM project that I'd like to simplify.

The configuration can be changed by two groups of users. One requires granular control over a set of parameters and the other one only cares about a single one.

Instead of writing a custom Ext JS plugin to hide/show fields and adding an additional field to switch between the normal/simplified mode, I decided to make a separate component for those less interested in the granular config.

In my dialog.xml, in the full-featured component, I've got the following fields:

<field1
    jcr:primaryType="cq:Widget"
    allowBlank="false"
    fieldLabel="Field 1"
    name="./field1"
    xtype="selection"
    type="select"
    options="/bin/myapp/fancyOptions.json" />
<field2
    jcr:primaryType="cq:Widget"
    allowBlank="false"
    fieldLabel="Field 2"
    name="./field2"
    xtype="selection"
    type="select"
    options="/bin/myapp/fancyOptions.json" />
<field3
    jcr:primaryType="cq:Widget"
    allowBlank="false"
    fieldLabel="Field 3"
    name="./field3"
    xtype="selection"
    type="select"
    options="/bin/myapp/fancyOptions.json" />

In the dialog for the simplified component, I only need a single field:

  • Field

while the values of Field 1, Field 2 and Field 3 should be inferred from the value of Field (in this case, all 3 fields should have the same value)

I don't want to introduce a separate Sling Model or any other Adaptable and I want to keep the content structure consistent for easier consumption at the back-end.

- myComponent
  - field1
  - field2
  - field3

Is there away to map one field in a Classic UI dialog to multiple properties in the content repository without creating a custom Ext JS widget to post them separately? I could write one but I'd like to avoid it if possible.

Solution

  • Yes, it's possible. The SlingPostServlet supports a parameter called @ValueFrom which allows it to generate the content of a property in the content repository based on the value of a different field.

    Here's a (partial) dialog definition that maps to the right HTML form in my case:

    <field1
    jcr:primaryType="cq:Widget"
    allowBlank="false"
    fieldLabel="Field 1"
    name="./field1"
    xtype="selection"
    type="select"
    options="/bin/myapp/fancyOptions.json" />
<field2
    jcr:primaryType="cq:Widget" 
    xtype="hidden"
    name="./field2@ValueFrom"
    value="./field1"
    defaultValue="./field1" />
<field3 
    jcr:primaryType="cq:Widget" 
    xtype="hidden"
    name="./field3@ValueFrom"
    value="./field1"
    defaultValue="./field1" />

    For some reason, this only works if both value and defaultValue are set. Setting just the defaultValue makes this work for a newly created component but every next time the dialog is opened, it's going to read the data from the repository and wipe out the expected value. At the same time, setting just the value property will prevent the dialog from initalising the element the first time the dialog is opened.