Cannot sync .xml files, such as cq_dialog fields

[kcmcgrath]

Dialog options within the _cq_dialog folders are often contained within nested folders and an XML file. It appears that aemsync is removing the .xml from these files, creating incorrect filters during package sync.

Using debug mode, I pulled the following filter settings:

<filter root="/apps/.../component/_cq_dialog/content/items/tabs/items/.../multivalue">
    <exclude pattern="/apps/.../component/_cq_dialog/content/items/.../multivalue/.*" />
    <include pattern="/apps/.../component/_cq_dialog/content/items/tabs/items/.../multivalue/field" />
    <include pattern="/apps/.../component/_cq_dialog/content/items/tabs/items/.../multivalue/field/.*" />
  </filter>

VS a standard css file

   <filter root="/etc/designs/.../clientlibs/css">
      <exclude pattern="/etc/designs/.../clientlibs/css/.*" />
      <include pattern="/etc/designs/.../clientlibs/css/main.css" />
      <include pattern="/etc/designs/.../clientlibs/css/main.css/.*" />
    </filter>

Note the difference between "main.css" and simply "field", where the latter should be "field.xml"

Code that performs this here:
https://github.com/gavoja/aemsync/blob/master/src/package.js#L128-L132

What is this filter meant to prevent? As a result of it, it seems that no edits to .xml files can be synced correctly. Is that purposeful?

[gavoja]

Usually this should not be a problem as in most cases the entire dialog is represented by one _cq_dialog.xml file. I did not test this when the dialog is split into multiple folders, however in theory it should work as long as the corresponding .content.xml files are there. Could you perhaps share the exact directory structure and detail the change that you make?

[kcmcgrath]

Thanks for responding. I don't have the immediate code in front of me right now, but what were trying to do is very similar to this: http://experience-aem.blogspot.com/2015/02/aem-6-sp2-touch-ui-multi-field-component.html. I should note that we are on AEM 6.2, focusing on the Touch UI dialogs.

Where our project differs from the the example above is on line 42 of their 'step 4', our .content.xml just has <field/>, instead of the full definition inline. Then, noting the tree structure they visualize under heading "Dialog Structure in CRX", at its bottom is an additional file named 'field.xml' that contains all the definitions for the repeating multi-field. Our .content.xml appears at the root of _cq_dialog, but the subsequent folder structure does not have another deeper down.

We use these multi-fields in a number of places, and use this method to split up the code and make it more manageable as they grow in size. Editing that final field.xml file is where I first saw the problem.

[kcmcgrath]

This is an example of the actual tree:

.../jcr_root/apps/.../components/common/componentname
├── .content.xml
├── _cq_dialog
│   ├── .content.xml
│   └── content
│       └── items
│           └── tabs
│               └── items
│                   └── tab2
│                       └── items
│                           └── columns
│                               └── items
│                                   └── multivalue
│                                       └── field.xml
├── _cq_editConfig.xml
├── dialog.xml
└── componentname.html

[gavoja]

It seems that the .content.xml files are not added to the folders on the path. I'm working on a fix.

[kcmcgrath]

Thats awesome - thank you. Let me know if I can provide any more information.

[kcmcgrath]

@gavoja just wanted to see if you had any thoughts. I could take a stab at it, but with my so far limited experience i'm not sure what the filter was meant to prevent well enough to be confident in working around it again.

[gavoja]

@kcmcgrath

I found a fix, though it's not very nice and I didn't have time to polish it. I'm currently flat out with other projects I do for living, but I'll definitely come back to this as soon as I can.

Basically for all the folders up to the root under jcr_content, the corresponding .content.xml files need to be added to the package - otherwise they will all be treated as nt:folder. You can give it a go if you have time - I will always appreciate it.

[gavoja]

Can you please verify if this works properly with 2.0.0?

[gavoja]

Closing.