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… ;) > 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
