Hi,

Le 28/02/13 13:01, Vincent Massol a écrit :
Hi,

On Feb 28, 2013, at 12:47 PM, Jean-Vincent Drean <[email protected]> wrote:

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.

Could you elaborate ?

You've made us curious :)

Jérôme


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
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to