Re: [xwiki-devs] [VOTE] Stop using UI Extension Points and deprecate this concept

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, vincent(a)massol.net wrote: -- Sergiu Dumitriu http://purl.org/net/sergiu