1 Mar
2013
1 Mar
'13
4:38 p.m.
Hi,
Le 28/02/13 13:01, Vincent Massol a écrit :
Hi,
On Feb 28, 2013, at 12:47 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
Could you elaborate ?
You've made us curious :)
Jérôme
Hi,
in 4.x we introduced UI Extensions (UIX) and "Extension Points", it
allows applications to come and plug their bits of UI where it is
possible [1]. 5.x is a good time to provide a list of useful Extension
Points (UIXP) in our velocity templates, allowing applications to plug
themselves in, for example : the header, before the content, the
footer, etc.
To allow this I can think of 2 strategies:
== 1) Manually add UIXPs ==
Actions:
* Discuss where are the common places where applications would like to
plug (in our opinion)
* Make a lengthy list
* Vote it
* Introduce an API call (services.uix.getExtensions()) for each item in the list
* Commit it
Pros:
* We can carefully build the UI API
Cons:
* We can't think of everything
* Long process
* Overridden templates won't display the extensions
== 2) Instrument our templating mechanism with UIXPs ==
Actions:
* Modify the #template macro so that it create UIXPs before and after
the parseTemplate call. Calling #template.vm would create the
following UIXP:
** platform.template.global.before (or:
platform.template.global.above, platform.template.global.top)
** platform.template.global.after (or: platform.template.global.below,
platform.template.global.bottom)
* Commit it
Pros:
* A lot of available UIXPs
* We've worked on our template architecture for a long time, UIXP
would benefit from that
I don't think this is quite true. We've been
wanting to clean up our templates for a long time now. I'm not sure that considering
it as our next API without careful review of each template is a good thing.
Now as you say 1) and 2) are compatible and we need to do 1) anyway.
I personally prefer 1) since a) a template isn't necessarily a feature boundary and
b) any API needs to be introduced carefully since it's very very hard to change
afterwards.
Also I'd like to us to get away from templates in some not too far future so this
would not go in this direction.
BTW we need to start thinking about how we deprecate and remove UIX for the future… :)
Funnily, for 2) if you add "around" in addition to "before" and
"after" then you're offering a new way to create skins :)
I'm not fully against 2) but I think it's an additional feature and should
absolutely not replace 1) for any UIX. Now my worry is that it' generic and thus there
are templates we're not sure of keeping that would get their UIX automatically. I
think I prefer to manually add UIX in the templates we want, instead of being automatic.
Good topic for discussion! :)
Thanks
-Vincent
* Quick process
Cons:
* It'd make our current template architecture an API ... but since
templates can be overridden in skins, it already is one.
* A lot of API calls (but tests with YourKit shows that it doesn't
impact performance)
Note:
2) doesn't exclude 1), we'd probably still need to introduce UIXP
within templates, but we'd have way less UIX API calls with this
method.
WDYT ?
I guess it's quite obvious that my opinion is biased, I've started
playing with 2) and it's quite cool :)
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/UIExtension+Module
Thanks,
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs