Hi, 1. UIXP are very generic while XObjects are Class dependent: ** you cannot add in a particular location anything else than what the Class requires (only panels, only ApplicationEntryClasses, etc.); Question: * How will we handle Class modifications? Is there a threat if the user will customize the initial class? How will we handle the deletion of Class properties?
2. IMO UIXP's main point was to extend our velocity templates. We are using them now only to insert something of a particular type (and this can be replaced with XObjects), but they could have inserted only Velocity or HTML (add a new small functionality, independent of the initial usage - an export, a social button, etc.). How will we handle this? Thanks, Caty On Tue, Mar 4, 2014 at 4:46 PM, [email protected] <[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 > > > > > > > > > > > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
