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. 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
