On 3/20/07, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: XWiki promotes the idea that it allows easy collaborative web application development. Such an application might want to add an entry in the menu, or a [del.icio.us] link to the document footer. 1. If we require users to write a java class, compile it, package it in a jar and distribute it, then we lose the collaborative/online/easy parts. 2. If we list a number of interfaces that can be extended, then we would probably have forgotten the document footer. So we limit the extension points drastically. On the other hand, if we do list all the extension points, then we'll have minor releases with something like "added an EP for this and that", and we'll have dozens of interfaces. 3. I still dream of the wiki that supports importable xar-lets (well, named differently, as we agreed .xar is not a good extension), which can contribute anything, from simple pages to complete skins, interface elements, new classes/templates/sheets. Interface elements seem hard to add if we require java classes, right? I have developed some Firefox extensions in the past, so I am a bit biased when I insist on taking a XUL-like approach. Here are some ideas (see also http://jira.xwiki.org/jira/browse/XWIKI-649 ): 1. Right now we are putting Interface Elements (IE for short, also stands for Interface Extension) manually in the current skin. The only thing aggregated are the panels. Each of these elements is put in a <div>, maybe with an id and class. In XUL, each element having an id is a possible extension point (EP for short). It would be hard to use divs and ids, that's why we should replace these with something like #startelement("id", "class") and #endelement("id" "class"). These macros create extension points, and they aggregate any content that wants to be included in here. (as a bonus, we can keep a stack of open elements, and when we close an element (with an id) we can automatically close the missing #endelement-s) 2. An IE that wants to extend something can specify an id or/and class name, a position (before, after, at the begin, at the end), and some ordering hints. And the content, of course. What's more, an IE can add new EPs. In the wiki/velocity world, this is best accomplished using XObjects. 2a. If we want to push things to an advanced level, we can make the selection not just by an id or classname, but something like (basic) XPath or like the css (basic) selectors. 3. For java, we can create an interface equivalent to the EP XWiki class. This has the advantages that: - it's only one interface, similar in Java and the wiki - it can extend anything 4. #startelement and #endelement are implemented in java, by one or more components (at least one for java IE and one for wiki IE). In order to speed things up, we can make a cache of the extension points. When the platform start, it should search for the available extensions, and already prepare the list of elements to be added for each element. When startelement is called, don't search for anything, just flush the prepared list. We register a listener, so when a page is saved, check if it contains an IE object and update the affected list of extensions. 5. We should document the extension points present in the skins. First of all, we should identify a core list of EPs that should exist in all skins, with the same id/class. Each skin can add new EPs, which must be documented, and we should warn (outside) developers that only core EPs are guaranteed to exist in all the skins. 6. Each xarlet/plugin should list in the documentation the EPs affected and the EPs added. We can have extensions (xarlets) that mainly add a new EP, which other xarlets can use (like greasemonkey does for firefox). WDYT? Sergiu Note that the UI content itself is in any technology in the proposal below -- http://purl.org/net/sergiu

Just to clarify some things which might cause confusion: On 3/20/07, Sergiu Dumitriu &lt;sergiu.dumitriu(a)gmail.com&gt; wrote: - Any one of "id" and "class" can be missing, but not both at the same time. - If an ID is used more than one time, then it is an interface error. We should provide either a namespace-like feature ("ns", "id", "class"), or require (recommend) a safe naming convention. However, we don't need another stack trace or not-so-user-friendly error message, we should just ignore this error, and the result is that both elements have the same extensions. 2. An IE that wants to extend something can specify an id or/and class name, - The content can be static text, velocity or groovy code, or a simple call to a java method (we still need a scripting language to make the call). - If an IE can add content to a class of elements, we need to make sure that the context is known. For example, if we make an extension that adds permalinks to comments, how do we identify the comment? This requires that each EP also list the context-dependent variables that are available, and these variables should have the same name under all skins. - XObject means XWiki document objects. 2a. If we want to push things to an advanced level, we can make the - This is an AND item, not an XOR one. So we have both wiki EP+IE, and java EP+IE, sharing the same structure. So the java interface looks like the wiki class, and a java implementation does the same thing as a wiki object. - "It can extend anything" means it can be an Interface Extension for any Extension point defined in the wiki or in another java interface component. 4. #startelement and #endelement are implemented in java, by one or more As I said above in another comment, each EP should also list the context-dependent variables that can be used, and when they can be used: at the start or/and at the end. 6. Each xarlet/plugin should list in the documentation the EPs affected and An example is needed for a better understanding: Scenario: Comments currently don't have user pictures attached (not in the albatross skin). How does an extension that wants to add them work? Step 1: defining the extension points The comments should be defined as extension points #foreach($comment in $comments) #startelement("comment_${comment.number}" "comment") #startelement("" "commentauthor")${comment.author} said: #endelement("" "commentauthor") #startelement("" "commentbody")${comment.content}#endelement("" "commentbody") #endelement("comment_${comment.number}" "comment") #end A comment is an extension point with the id of the form "comment_<number>" and the class "comment". It contains two sub-EPs, for the author and the content. The context dependent variable is $comment Step 2: defining the extension There should be a document named (for example) Extensions.CommentAvatar, with an attached object with the class Extensions.ExtensionClass object.name = Avatar for comments object.selector = .comment ( .class selects a class and #id selects an id ) object.position = start object.orderRules = first object.content = #startelement("" "commentavatar")$xwiki.getAvatar($comment.author)#endelement("" "commentavatar") Note that this avatar is also an extension point, so another extension can put something around the avatar. Step 3: how things work The core component managing extension points and interface extensions will detect the fact that Extensions.CommentAvatar is an InterfaceExtension and will register it for the elements having the class "comment" ( object.selector). It also knows that it must be placed at the start of the comment (object.position) and if no other extensions ask to be placed first, it will be the first one to be added (object.orderRules). When the rendering engine interprets the #startelement macro, it will trigger the extension insertion mechanism. - First the list of extensions to be placed before the EP is inserted (none here) - First the html code for an element start is printed : <div id="comment_2" class="comment"> - Then the list of extension that are to be placed at the start of an element (but inside) are inserted. In this case, CommentsAvatar. The content of the object.content is parsed and then it is copied to the output. We need to parse it first because it contains velocity code that must be executed. Because it also defines an EP, there will be a recursive call following the same stes. Result: <div class="commentavatar"><img src="my.png"/></div> - The content of the comment is parsed. Result: <div class="commentauthor">John Doe</div><div class="commentbody">Nice thing!</div> - The list of extension to be placed at the end of the extension point is inserted. None in this case - The end element is printed: </div> - The list of extension to be placed after the extension point is inserted. None in this case So we saw: - how easy it is to define a new EP (just use #startelement instead of <div id="">) - what an wiki IE looks like (a simple wiki object) - how an IE tells what it wants to extend (selector, position, orderRules properties of the object) - how the insertion algorithm works (outputting the list of extensions before and after the start tag, before and after the end tag of the element) Using a java extension is pretty much the same, but instead of using a wiki object, we make a class implementing the InterfaceExtension interface, having getters with the same name as the wiki object (getName, getSelector, getContent...) Hope this clears the fog a bit... Sergiu -- http://purl.org/net/sergiu

On 3/22/07, Catalin Hritcu &lt;catalin.hritcu(a)gmail.com&gt; wrote: I know it is difficult to use #startelement and #endelement. This is not a final decision, but rather an idea of how it could be done in the given architecture (velocity + radeox). Maybe it could be done a lot easier in wikimodel. Using HTML only means that we need to add a new rendering engine, one that expands extension points. It is a better idea, but it needs more work. More, we don't need any special syntax, and it does not depend on velocity. Even more, we're not bound to using only div elements or specifying all the attributes that we might want to set to the generated element; all the markup is already there. Before jumping to the implementation, we do need to define how exactly is an EP defined, and when and how are they filled in. What we need to decide is the architecture, meaning what is an extension point and what is an extension. The advantage of this would be a very simple syntax with which -- http://purl.org/net/sergiu

On Mar 21, 2007, at 9:52 AM, Luis Arias wrote: Luis, I was only discussing general principles and not details. The page stuff was only one example of one interface. This is why I said: "<example - I'm not asking to vote on this, it's just an example to better visualize what "one Java Interface for each UI contribution" means>" :) Now that said, I need to read Sergiu's emails and answer. That'll take me a bit as I'm talking at conference today and this is not something you read quickly. I'll need to digest it :) Thanks -Vincent

It took me quite a while to understand Sergiu's ideas, but now that I think I did they seem quite convincing. Here are two points on which I agree with Sergiu. It's highly unlikely that we can specify all possible extension points in any interface using XWiki, especially if we want to keep things easily extensible in the future. So instead of trying to enumerate the ones we currently know about, it would make sense to use a more generic way of specifying extension points. For better understanding, you can view an extension point as something as simple as a HTML id or class, so just a string identifier. Another point is that it should be possible to add such extension points not only from Java components, but also from Velocity, Groovy or Xwiki objects etc, so from the user interface itself. First, because it would be convenient for users. Most users will have the permissions to add new Velocity code for example, while adding a new Java component is not an option unless you are an administrator. Second, if the syntax is simple enough the designers themselves will be able to add the extension points to their user interface, without needing a programmer's assistance. Regards, Catalin On 3/21/07, Luis Arias &lt;kaaloo(a)gmail.com&gt; wrote:

On 3/25/07, Catalin Hritcu &lt;catalin.hritcu(a)gmail.com&gt; wrote: A solution would be to have distinct settings for the global extensions and user extensions. Global extensions have to be registered somewhere in XWikiPreferences (and WebPreferences, for customizing the interface only for a space), and it is impliend that only administrators are allowed to change these. The EPs will have to be secured, too, so that no user can alter the global interface (and insert a script that tracks entered passwords, for example). * We need to find a way to make this interact with frameworks like GWT If it is defined good enough, it will be usable from anywhere. -- http://purl.org/net/sergiu

On 3/22/07, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: At which point do we apply this? Velocity/Groovy generates code, and Radeox too, so it will have to be after these. On the other hand, the extension depends on the context, so it should be executed before the velocity/groovy/radeox renderers. Open issues: Indeed. The same problem is with FF extensions, most of them only work on specific versions of the browser, but usually it takes little effort to make them compatible with a new version. We can try to minimize this risk by providing stable interfaces. This means that before (officially) releasing any skins and the UI extension mechanism, we need to define the core interface elements, and this specification should remain stable (at least without removals or renames). Sergiu, what about putting this on http://www.xwiki.org/xwiki/bin/ Sure, but after things are a bit more clear. Thanks -- http://purl.org/net/sergiu

Hi Vincent and all, Vincent Massol wrote: [...] you probably considered it already, but couldn't we try to simply use the Eclipse UI extension points mechanism? btw this project may be of interest to us: Rich Server Platform – User Interface Framework (RSP-UI) http://www.eclipse.org/proposals/rsp/ "The Eclipse/OSGi development model, applied to the server-side, allows the creation of truly pluggable, componentized, server-side applications. Plug-ins can communicate at a logic layer with each other using established and tested methods, such as extension points and OSGi services. What is needed for the UI layer is a UI composition framework which we propose in the form of RSP-UI." Stéphane