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, vincent(a)massol.net <vincent(a)massol.net>wrote;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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs