Hi All, Let me write my new thoughts after Sergiu’s post. Issues to agree on ================== 1) I’d like to have a single terminology for expressing the ability to plug some UI element dynamically on a given part of the screen, be it done inside a template or in a wiki page. For example the Applications Panel does contain a "UI Extension Point" for me even though it would be best implemented as a specific XClass and not as a UIExtensionClass. Similarly, if I talk about the need to be able to contribute new Tabs in the AllDocs page, I would speak in term of adding a UI Extension Point. So when we talk about UI Extension Point we shouldn’t restrict it to the UIExtensionClass. That’s the main reason why the xwiki-platform-uiextension module is an issue for me in term of terminology. UI Extension Point   |_ implemented as UIExtensionClass   OR   |_ implemented as a custom XClass How do we make this clear when UIExtensionClass is named like this? If it were named UIContentClass it would work fine though. 2) It’s ok for me to keep a specific XClass (currently badly named UIExtensionClass, see point 1)) when the need is to **only** contribute some content. If, for a specific extension point, you need to have content and some other parameters, then it should be implemented as a custom XClass. There are 2 solutions out of this: * A solution based on Design: Remove the “parameters” field from UIExtensionClass and you’ll be guaranteed that if the need is to also have some parameters the developer will be forced to create a custom XClass. In this case we will also need to add a new property for defining the order. * A solution based on Best Practice: Keep the “parameters” field in UIExtensionClass but make it a best practice to not use it when you need to use parameters (except for one case: when the parameter are used exclusively for ordering). 2a) I don’t mind that much having a lot of XClass, i.e. one per UI Extension Point because it makes the whole concept much simpler (no need at all for the xwiki-platform-uiextension module and no terminology issue) AND when you need to evolve the UI Extension Point by adding a new parameter you can do so in a typed way (you add a property to the specific XClass) without having to deprecate your UIExtensionClass xobject and create a custom XClass… Note that since we would have a lot of XClasses we would need to improve the XObject picker in edit mode but we do need to improve it anyway so that it scales because we’re starting to have lots of XClasses anyway… So we need categories, search, etc. 3) When we list all the UI Extension Points available in the wiki (see http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/WebHome) we would need a way to list *ALL* of them and not just UIEXtensionClass which cover only the specific case of contributing content. A developer should be able to see a list of all XClass in the wiki that are used to contribute UI elements somehow (either manual or we need to tag them in some manner). Specific UIXP ============= ATM there are 6 UIXP defined at http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/WebHome. I’d like that we agree about whether they should be implemented as UIExtensionClass or as a custom XClass: * “Add Application”. For me, custom class. * “More Application”. For me, custom class, possibly the same one as the one used by “Add Application” with an addition property to say where it’s applied (main list or more application list). * “Left Panels”/“Right Panels”. For me, this is definitely a custom class which already exists: PanelClass. * “After Header”. This is just content so for me, UIExtensionClass is ok (or whatever the new name we want to give it, see point 1)). * “Search Provider". For me, custom class. WDTY? Thanks -Vincent On 5 Mar 2014 at 18:47:21, Sergiu Dumitriu (sergiu@xwiki.org(mailto:sergiu@xwiki.org)) wrote: