On Thu, Feb 28, 2013 at 1:01 PM, Vincent Massol <[email protected]> wrote: > 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. >
I think we've worked on it for a long time, even if it's not perfect it's been refined for years. We could however implement 2) and publish a sublist of public/recommended UIXP. > 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. > Shouldn't we consider our templates as APIs already ? (re: overriding in skins). > 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. > Move away from templates ? > > BTW we need to start thinking about how we deprecate and remove UIX for the > future… :) > For the moment UIXs are snippets of wiki syntax, hooked to an extension point (String), they were supposed to be future-proof. > 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 -- Jean-Vincent Drean, XWiki. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
