I guess this request is similar to Mixin with parameter support.
I share the need of kind of customizing some mixins. My team is in middle of restructuring a large project to use mixins as reusable components, thus avoiding a lot of copying-pasting code.
The thing is that in a few content-types, some (not all) of these mixins’ fields are not required (occurrence min=0). Of course that duplicating the mixin to reflect both alternatives is a valid path, but I believe it’ll largely increase the number of custom made components.
We’d appreciate the possibility of overriding a mixin’s field, which otherwise would continue with the current behaviour, presenting the default config.
For instance, we could have clean content-types representing each (bear with me) a person with a nationality (for whatever reason we could have to create a content-type specifically for each person-nation), all of them with a default mixin fullName, but some would have a middleName field shown up as required whereas the default would be not to have it. Then, again, in some nationalities we could have a unlimited maximum number of last names, and so on.
On a customizable mixin, I imagine we would be able to perform something like, for example: <mixin name="fullName" override="middleName.occurrences.minimum=1, lastName.occurrences.maximum=0">.
You could always “generate” your content types compile time (during the build of the app). Similar to how Thymeleaf is generating html pages. You can for instance use XSLT as templating language.
If someone has indeed done this, I couldn’t find it easily (does google searching count?).
I’ve read a bit about XSLT (it may help) but I’m wondering how to actually do this, since the content types depend on mixins.
Only the content types “know” which values the mixins’ parameters will have, which means (as I see it) that the mixins would be pieces of xslt (is this possible?) to be inserted in content types “code” (when does this occurs?), which would also be xslt files, along with a xml file with the parameters definitions in content type dir.
From my understanding, I’d have:
some XSLT mixins and some XML mixins (not all of them will be parametizable, maybe)
one XSLT (the one to have the mixins injected) and one XML (mixins values for parameters) in some content types’ dir
The I’ll have to apply xslt transform to actually generate the content types xml (as we usually have). I’d guess that some gradle task could do that, but I don’t know when/where exactly I should do it.
Unfortunately, using mixin is a must. It’s one of our client’s demand to restructure the project with mixins.
If you are using 7.x mixins only purpose is for re-use across the various forms, but essentially this is just a very simplified templating.
Your approach seems solid. You could replace mixins alltogether by processing your various content types with xslt, and the xslt would inject “mixins” or whatever else you might need.
Indeed, I’m running XP 7.2.
I guess this is as far as I’ll get on this discussion. I’ll debate the real need of using mixins with the client, since their expectations are quite different of the technology’s purpose for them.