nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Surf Extension Module Customization of Rule Actions

akreienbring

ACS 6.2.ga
SDK 4.1.0

I created a surf extension module with a customization like this:

<targetPackageRoot>org.alfresco.components.rules.config</targetPackageRoot>
<sourcePackageRoot>[my.packagename].components.rules.config</sourcePackageRoot>

If I copy the Javastript Controller from ...org\alfresco\components\rules\config\rule-config-action.get.js to <sourcePackageRoot> it is picked up and processed by share like it should! 🙂

BUT if I copy the config XML file ...org\alfresco\components\rules\config\rule-config-action.get.config.xml to <sourcePackageRoot> it is NOT taken into account by share. So my customization in that file is not working. 😞

Is this by design or is it an issue? I think that all out-of-the-box files that go to <sourcePackageRoot> should overrule the original ones...

How can I use the module customization for my purpose WITHOUT simply overwriting the out-of-the-box files?

Find more posts tagged with

Alfresco Content Services

Accepted answers

afaust

As far as I am aware, *.config.xml files are not supported by the Surf Extension Module Customisation functionality. This has to do with the fact that there is no way in defining / handling XML file merges, and without any technical schema to those files, there no assumptions can be made as for a "safe" default behaviour. For all other supported elements, JS, FTL and i18n, the way that these files can adapt the original are easy to define: JS is a simple post processor on the same model, FTL too, and has to explicitly reference pre-defined elements that support custommisation, I18n can simple work on key-value override patterns. But for XML?

So yeah, you can consider this limitation to be by design, although the "by design" part is that nobody was able to come up with a design that would universally work, and so Alfresco has likely out-of-scoped this part of web scripts.

All comments

afaust

akreienbring

@afaust

Although I marked your answer as "The Solution" I wonder why xml can't be merged.. An example ist share-config-custom.xml that is merged with a module extension xml.

AND: I don't think that merging is even necessary. If I can overwrite the original *.config.xml then it should also be possible to pick it up when it is in the customization folder and has the same name.

What do you think? 🙂

afaust

1) share-config-custom.xml's overriding is far from consistent / does not always work as expected. It also does not work out-of-the-box for just any XML as it relies on Java-backed implementation, which is registered via plugins / element readers (e.g. https://github.com/Alfresco/share/blob/master/web-framework-commons/src/main/resources/alfresco/form-config.xml#L3). You probably have never seen those, because they are not really documented and not a lot of people know how to use them. It is only because of this basic support - and specific handling in code using the configurations - that extension module configuration customisations can actually work.

2) overrides via the extension path (extension or web-extension directory) are obviously different from doing customisations via extension modules. You can have multiple customisations affecting the same web script, so merging must be supported, otherwise only the last (in whatever order those end up being applied) wins, whereas a file in the extension path will always override / replace the original file, and there can only be one - in fact, it takes the place of the original file in the lookup order, and Alfresco will actually not even check if the original file even exists.