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 ([email protected](mailto:[email protected])) wrote:

Big -1.

UI extensions are a great concept, and they have a lot to offer. The issue isn't that they're too opaque (unstructured) for our current needs, but that we're severely under-using or misusing them.

As Caty said, the initial goal was to make the skin extensible. The example you mention -- the applications panel -- does not exactly fall into this category and that specific need would indeed be better served by specific xclasses. Instead, try to imagine an XWiki instance that needs to be customized for a specific purpose, for example a conference website. You would need to get rid of most of the wiki menus which are too technical, add your own text in the header with information about the conference name, date and venue, maybe add your own custom search box with options to search for events, authors, etc. The way XWiki is being customized now for this kind of task, as far as I know, is by writing a new skin where unneeded elements are removed and new elements are added. This seems like a good idea, but it results in painful upgrades for obvious reasons, and there will be a constant need to watch for skin improvements in the platform and decide whether/how they should be adopted by the custom skin. Imagine how nice it would be if you could just disable the menus and plug in your own text, navigation and search bar, without touching the skin.

In my opinion, instead of removing support for UIX, some time should be invested into figuring out good use cases and improving the implementation, including the way extensions can be edited by a non-technical user. Nothing (with the obvious exception of laking time and resources) stops us from having a more intelligent display of the extension parameters that ensures the entries are well formed for a specific extension point. It is my impression that this proposal to remove UIX was not based on a thorough analysis of benefits and caveats. Also, since a new skin is planned, now is the chance to design a fully extensible skin, with many extension points embedded in it.

I've done something like that for a downstream project, and in the end I've got a very flexible product that can be easily extended. Some extra features possible through standard parameters:

- extensions can be enabled only for a list of spaces - can be enabled globally with the exception of a list of spaces - can have a title, which is displayed in a UIX directory - can be ordered - can be disabled

To sum up: - For applications I agree that using UIX was a bad idea, especially since it only works with those 3 typed parameters. This should be reimplemented using an XClass. - For the general needs of an extensible skin, I think it would be wrong to force creating specific classes for every possible extension point. This will lead to a huge number of very similar classes, if we really define one xclass for one extension point, and this will make it hard for users to know which class to use. If we define one common class for most extension points, then this is already the UIX class we have now, and we should improve it instead of replace it completely. - My vote is a strong -1 for removing support for UIX at this point. The issue should be re-analyzed from the perspective of a new extensible skin before making such a decision.

On 03/04/2014 09:46 AM, [email protected] wrote:

...

Hi devs,

I know this will come as a bomb. It came as a bomb for me too when I thought about it this morning :)

Issue =====

So the question is: why do we need UIX when we already have a system to provide extensibility in XWiki called XClass and XObjects?

Let’s take the example of the AddApplication extension point (http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/AddApplicationUIX) used in the Applications Panel. The UIExtensionClass xobjects for it don’t use the “content” field but they use the “parameters" textarea field, which defines 3 parameters: “label", “target", “icon". This is actually not very nice because the parameters are untyped and it’s up to the extension point user to parse the value (for example if the value is a list, it’ll need to tokenize the value to extract the different parts).

A better way to implement this would be to have an ApplicationEntryClass with 3 typed fields: “label", “target" and "icon". And the “target" field could even be of type Page and when an XObject of that XClass is editer we would get auto suggest for it...

This is the XWiki way... And with UIExtension we’ve suddenly introduced non-typed versions of XClasses... and this is IMO anti-xwiki!

So, with an ApplicationEntryClass all the Application Panels needs to do, is use XWQL to find all xobjects (or introduce some script service to do that in the same as we have a script service for UIX).

Some Q&A ========

Q: How to support scope with XClass as we have in UIExtension? A: - For “user" scope, this can be achieved by setting a Rights xobject on the page containing the XObject. - For “global” scope, this can be achieved by putting all global XObjects on the main wiki.

Q: UIX could be implemented as components, we would loose that! A: Yes but look at it, UIX are for user interface and the best place to define the user interface is in wiki pages since that’s the place where the UI can be most easily modified by the user to fit his needs. If need be, we can have Java code that creates XObjects.

Q: Right now it’s possible to use velocity for the parameters of property values in the “parameters” textarea of UIExtensionClass A: Several possibilities: Use a textarea field type, modify xwiki to add optional support for applying velocity on a String property, apply velocity at the place of usage through #evaluate.

Way forward ===========

* Deprecate the UIExtension notion, i.e. move the code to a legacy module (still bundle it in XE with other legacy modules) * Introduce specific XClass(s) to replace existing UIX (see http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/WebHome for the full list) * Revert Panel display code (leftpanels.vm, rightpanels.vm) to before the introduce of the UIExtension module. * In order to be backward-compatible, if the $services.uix script service exist, also look for UIX. For example in the Application Panel. Note: I believe this the main and probably only UIX really used at the moment.

Here’s my +1

Thank you -Vincent

-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs