On 11/03/2011 09:12 AM, Vincent Massol wrote: > Hi Eddy, > > On Nov 3, 2011, at 1:13 PM, Eduard Moraru wrote: > >> Hi Vincent, >> >> On Thu, Nov 3, 2011 at 12:56 PM, Vincent Massol <[email protected]> wrote: >> >>> Hi devs, >>> >>> I'm implementing the LinkChecker UI and I want to be able to add a Tab in >>> AllDocs. Right now I've coded it with a hardcoded #if but I really hate >>> this. >>> >>> So here's my proposal: >>> >>> * Create the following modules: >>> xwiki-platform-uiextension/ >>> |_ xwiki-platform-uiextension-ui/ >>> |_ xwiki-platform-uiextension-api/ >>> >>> where: >>> * xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page >>> * xwiki-platform-uiextension-api/: contains a ScriptService to get >>> UIExtension data + contains an EventListener that refreshes the UI >>> Extension Cache when an UIExtensionClass object is modified (this is for >>> performance reasons) >>> >>> >> So how would this work exactly? > > First le me say that I'm not planning this as something uber complex that may > satisfy all possible future needs. I'm taking a very pragmatic approach here > which IMO solves a lot of hardcoded issues we have today. We can > optimize/refine it later on. I prefer to that approach since the other > approach hasn't worked in the past 5 years… ;)
I want to echo this sentiment, not just in this case but in general, there is a fine balance between creating something that doesn't age well and not doing anything because there might be a better way, both are dangerous. Caleb > >> Each UI (skin, xwiki bundled application, user application, etc.) defines >> these extension points that any other application can contribute to by >> using the "type" field in an XWiki.UIExtensionClass instance? > > Yes. > >> This would, >> of course, mean a great deal of rewriting, but once done, it would be a >> good investment. > > There's no need for any rewrite. > > Whatever works will continue to work. OTOH of course it'll be nice if some > existing custom extension mechanisms were retrofitted to use this new > UIExtensionClass. Now it doesn't mean we should never allow custom extension > mechanisms. > > The idea is more than any part of the UI which needs to provide extension > points would use UIExtensionClass from now on if it fits its needs. For > example I can think of the Workspace Applications which needs a User profile > extension point for the tabs and which needs a Menu extension point for the > top level Menu. > >>> To start with I'm proposing to have the following fields for >>> UIExtensionClass: >>> * type: String, represents the type of the extension (for example for the >>> AllDocs needs, I'll use a "IndexTab" type (or "AllDocsTab" type) >>> * id: String, the technical name of the extension, which can be used for >>> example as suffix for HTML class or ids. >>> * name: String, the name of the extension, which can be used for >>> displaying. For example for the AllDocs needs, it would be used as the name >>> of the Tab >>> * content: Textarea: the content of the extension. For example for the >>> AllDocs needs, it would be used as the content to display when clicking on >>> a tab >>> >> >> Depending on the specifics of the extension point, the content gets treated >> differently? > > Yes, it's the user of the UIExtensionClass which decides what the content > contains. > >> Also, I`m assuming this will generally be velocity/wiki syntax, right? > > Generally I'd say wiki syntax yes. > >> Another thing that might be useful (maybe in future iterations) would be >> some kind of parameters that the extension could supply to its hook. >> In your particular use case, a tab extension could say to the AllDocs page >> that it wants its content to be loaded asynchronously, when the tab is >> selected. Another case would be a menu extension that wants the menu item >> to open in a new window when clicked or that wants to be placed before >> entry X or after entry Y. Etc. > > Yes, good idea, we'll probably need to use a List field for that allowing the > extension to provide "key1=value1,key2=value2,…" > >>> I'd like to implement this ASAP and thus stop hardcoding UI Extensions >>> from now on. >>> >> >> The only downside I see is the performance penalty once everything starts >> being extra extensible, but maybe using some smart caching (which you >> already mentioned something about) we can limit the damage. > > Yes that's the plan. As I mentioned the UIExtensionClass objects would be > cached in memory and the script service would return the cached values (it's > an "active" cache since it'll refresh automatically when a UIExtensionClass > object is modified). > >> The extension >> content still needs to be evaluated every time (unless maybe otherwise >> stated by the extension itself), but at least the list of extensions can be >> easily cached. > > Yes. Caching the rendered value would be another field in the > UIExtensionClass for later. > >>> Here's my +1 >>> >>> >> +1 if I understood it correctly. > > Yes you did ;) > > Thanks > -Vincent > >> Thanks, >> Eduard >> >> >>> Thanks >>> -Vincent >>> >>> PS: If you find a better than "uiextension" I'm all ears. A name without >>> "extension" would be great to not confuse it with our Extensions (and with >>> xwiki-platform-extension). > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
