Use a group of fields multiple times in TOUCH UI dialog



Hello everyone,

We are slowly migrating to Touch UI dialog for our projects but I'm facing some difficulties.

I'm trying to create a dialog which have repetitive fields. As shown in the picture below, we sometimes need to reuse a set of fields (to avoid having a very long file, and also to update those fields only once when needed). Its easy to do in classic UI by defining all the fields we want to reuse in a separate file and then including them everywhere we need with include and a namespace. This method provides us a child node with all the properties for a button for each instance.

Here is an example of the classic code (the dialog using the template xml) :

<btn_validate jcr:primaryType="cq:Widget" collapsed="{Boolean}true" collapsible="{Boolean}true"
   title="Bouton valider" xtype="dialogfieldset">
       <items jcr:primaryType="cq:WidgetCollection">
<btn_cancel jcr:primaryType="cq:Widget" collapsed="{Boolean}true" collapsible="{Boolean}true"
   title="Bouton annuler" xtype="dialogfieldset">
       <items jcr:primaryType="cq:WidgetCollection">

This is what it looks like in classic UI

All the fields are the same for Validate and Cancel. We use the template as it is. And we can have more than 2 buttons on the same component


This is what our content node looks like :


As you can see, the stepCValidateButton and stepCCancelButton have been created and both hold all the fields we defined in the template XMl file.


So far I've not been able to do this in Touch UI. I'm able to include the template using this :


The problem is that I can't define a namespace so it would create a child node. It puts all the imported field on the main node, which leads to all of them being overwritten. In clear, instead of doing mainNode.stepCValidateButton.textBtn to access the validation button textBtn attribute like in classic I have to do mainNode.textBtn and this leads to textBtn getting overwrote when I edit the cancel Button textBtn attribute. I hope all this is clear for you. We are using aem 6.4

I can provide the files if needed.

So is there a way to do the same as I did in classic? Or can someone point me to another way to deal with repetitive fields in touch UI?

Thanks for taking the time to read all this 🙂

Answers (6)

Answers (6)



Hi EasyJ7​,

No need to keep classic UI dialogs because:

  • You have to handle the behaviour of classic & touchui dialog such as multifield storage as mentioned by you.
  • Adobe might decommissioned Classic UI in upcoming versions.

Also, Please have a look on Adobe Modernization suite which might help you if your client is moving from classic to touch UI.

This will help you to understand the approach more clearly.


Introducing the AEM Modernization Suite

BlueJeans Network | Recording Playback

Github - GitHub - adobe/aem-modernize-tools: A suite of tools to modernize your AEM Sites implementations off...


Arpit Varshney




I've considered using a multifield for that purpose but since we are building this so our client could edit it's customer website, I'm reluctant to give them such a dynamic dialog. By using a multifield I don't think I would be able to put a title on each item like saying this item is for Cancel button and this one is for Validation Button (Or maybe there is a way to put title on items created by a multifield? WIll look up), so they could quickly get confused especially knowing the size of our dialog (They want to be able to edit almost everything on a 300+page Site).

I will try to use a multifield to see how effective it could be and come back to give my feedback.

Side Question :

Since we are still migrating from Classic to Touch, we decided to create both Classic and touch dialog for every new component we design. Is that a good way to do or should we just keep moving with Touch only?

I'm asking because it require some extra work to have both of them working correctly on the same component. A quick example is the multifield, in classic they create a property on the main node but in touch Ui they creat a node under the main node. So we have to add extra code to make the content JSON uniform in order for our app to use is correctly no matter which dialog the client used to edit those fields