Custom Generic List Datasource Reverts After Saving Content Fragment Model

[Nivetha_Thavaraja]

Hi,

We're using a custom ACS Commons Generic List as a data-source for dropdowns in our Content Fragment Models. Initially, when we update the data-source node in CRXDE to point to our custom Generic List, everything works as expected—the dropdown populates correctly.

However, the issue arises when we open the model in the AEM UI and save it. The sling: resource Type of the data-source node reverts to the default:
dam/cfm/admin/components/datasources/optionrendererenumeration. It seems like the model editor is overwriting our custom data-source configuration upon save. This behaviour is causing our dropdown to lose the custom list reference.

Are there any recommended approaches to persist the custom data-source configuration or prevent the UI from resetting it?

Please provide any suggestions or workarounds if possible.

Thank you so much in advance!

[AmitVishwakarma · Accepted solution]

Hi @Nivetha_Thavaraja ,

You're facing a common issue with AEM Content Fragment Model Editor where the UI overwrites custom datasource configurations (like those using ACS Commons Generic Lists) when the model is saved. This is not a bug, but intended behavior by the editor, which resets certain subnodes such as datasource under enumeration fields based on UI logic.

When you edit and save the Content Fragment Model through the UI:

  - AEM automatically resets the datasource node under enumeration fields.

  - It changes sling:resourceType back to:

dam/cfm/admin/components/datasources/optionrendererenumeration

Your custom values (like acs-commons based genericlist) are overwritten.

You must bypass the UI when dealing with custom datasources like ACS Commons Generic Lists.

Option 1: Use Overlay + Post-Processing Hook

  - Create the CF Model via CRXDE or VLT (e.g., via code deployment)
  - Never modify it via UI once datasource is configured.

  - Write a Post-Deployment Hook in your CI/CD pipeline or package filter to ensure the datasource node remains as desired.

  - Add a .content.xml for your enumeration field with the following structure:

<campaignSource
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/select"
    fieldLabel="Campaign Source"
    name="campaignSource"
    valueType="string/enum"
    metaType="enumeration"
    listOrder="6"
    renderReadOnly="false"
    showEmptyInReadOnly="true"
    emptyOption="{Boolean}true"
    value="home">
  <datasource
      jcr:primaryType="nt:unstructured"
      sling:resourceType="acs-commons/components/utilities/genericlist/datasource"
      path="/etc/acs-commons/lists/campaign-source"
      variant="default"/>
</campaignSource>

Deploy this as part of your codebase, not through the UI.

Option 2: Custom Enumeration Component (For UI Compatibility)

If UI editing is a hard requirement, you can:
  - Create a custom datasource component that extends optionrendererenumeration.
  - Overlay or extend the default CF Model Editor logic by creating a proxy component (complex and less recommended).
  - Store the list in /conf or /apps instead of /etc, and use OSGi-based dynamic servlet rendering (e.g., DataSource servlet under /apps/myproject/datasource/campaignsource).

This requires more effort and provides partial mitigation only.

Note:

Define your model fields using code (e.g., content package .content.xml).

Avoid editing such fields in the UI after deployment.

Communicate this to authors/admins as part of authoring guidelines.

Regards,
Amit