My point is that it’s not because you define a macros.vm that you have to do any kind of synchronization. Here the problem is specific to some livetable macros being redefined in the flamingo skin.
which is the topic of this discussion
Yes, but what do we do with the generic “flamingo” UIXP when we move to a new skin (even based on Flamingo), if we do 1? The new skin will have its own versions of these UIXP. I guess we’ll have to rely on aliases?
Ah you mean about the id for the UIXPs? For me if we decide to merge platform-web and skin, it just becomes templates and we should use the template
id. That allows to have some id independent of the skin name. We would move them all in a xwiki-platform-template module. We would also probably remove xwiki-platform-web and have xwiki-platform-flamingo depend on xwiki-platform-template.
WDYT?
The UIXP naming convention is now documented. Thank you for your feedback.
Existing UIXP with ids that don’t conform to the convention will need to be updated only once http://jira.xwiki.org/browse/XWIKI-12982 is closed.
Hi everyone,
Unfortunately I haven’t followed this discussion till the end. I’m fine with the naming convention for UIXP but I have a small problem with the naming convention for the UIX:
The User Interface Extensions (UIXs) contributing to an UIXP must follow the following pattern:
<groupId>.<moduleName>.<uixpQualifier>(.<uixQualifier>) where:
<uixpQualifier>
: reuse the uixpQualifier of the UIXP where the UIX contributes.Examples of UIX contributing to the org.xwiki.platform.user.profile.menu UIXP:
org.xwiki.platform.notifications.menu
I find org.xwiki.platform.notifications.menu
confusing. It’s not clear that this is adding an entry to the user profile menu. My point is that in some cases the UIXP module name is important in identifying the UIXP. The uixpQualifier
is often very generic:
menu
, which menu? (org.xwiki.platform.user.profile.menu
)title.before
, which title? (org.xwiki.platform.template.title.before
)content
, what content? (org.xwiki.plaftorm.menu.content
)head
, which head? (org.xwiki.platform.html.head
)
I propose to make the rule a bit more relaxed:
<groupId>.<moduleName>.<uixQualifier>
where uixQualifier
can be the uixpQualifier
, if it’s specific enough, or uixpModuleName.uixpQualifier
or something else that better expresses the UIXP that this UIX contributes to. Basically I would enforce only the <groupId>.<moduleName>.
prefix which for me is the most important part in order to avoid conflicts between different UIXs.
WDYT?
@mflorea I see at https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HUserInterfaceExtensionPointNaming that there can be several <uixpQualifier>
elements and there are some examples given:
Examples of UIX contributing to the org.xwiki.platform.user.profile.menu UIXP:
org.xwiki.platform.notifications.menu
org.xwiki.platform.user.profile.menu.userMembership
org.xwiki.platform.user.profile.menu.userNetwork
Thus, using org.xwiki.platform.notifications.menu
is not mandated and it could as well have been org.xwiki.platform.notifications.menu.userProfile
, no?
It’s true that the doc says:
- : optional, used only in case of ambiguity, for instance if the UIX is declared in the same module as the UIXP, or if several UIX are declared in the same module. Single camel case identifier.
And thus it only lists 2 cases of ambiguity and the one discussed here is not listed.
So I see several choices:
- Do as you suggested. Cons: less precise and more subject to interpretation
- Use the uixQualifier to remove the ambiguity, as with
org.xwiki.platform.notifications.menu.userProfile
- Use the full UIXP suffix (removing just the groupId, ie
user.profile.menu
) →org.xwiki.platform.notifications.user.profile.menu
WDYT? cc @mleduc who started this thread.
Thx
I’d be in favor of this.
Thanks,
Marius