On Mar 20, 2007, at 4:31 PM, Sergiu Dumitriu wrote:

Hi,

To me this seems to have too much Java. I was thinking of a more wiki-like solution, using documents, tags and POXO (plain old xwiki objects :p ).

We can discuss pros and cons if you want. Could you explain the solution you would prefer over the one below and why? Note that the UI content itself is in any technology in the proposal below (it can be in .vm files, JSP files, etc). The Java is there for 2 reasons: allow components (in Java) to contribute content so that you can have one single component for example for the importer/ exporter, and allow any other part of the code to interact with the UI interfaces (GWT, RCP client, Swing client, etc). Java is the most common denominator and when we have an API in Java it's then easy to access it from any other technology (the other direction is not always true). Thanks -Vincent

On 3/20/07, Vincent Massol <vincent@massol.net> wrote: Hi,

I'd like to propose the following general principles for the V2 Architecture (http://www.xwiki.org/xwiki/bin/view/Idea/ ArchitectureV2 ):

1) Components can contribute user interface elements. 2) They contribute them through a Java interface. 3) There's one Java interface for each UI contribution (located in a ui package).

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

For example, we have one interface for contributing Admin Pages (the tabs we have in the administration page when using the albatross skin). For example:

public interface org.xwiki.core.ui.AdministrationPage { Page getPage(Context context); }

where: Page will return the page's content (the implementation could have a "String getContent()" method, and some other fields, like a page id, etc). The context will contain useful information for returning the page. One interesting information is the skin name if some component want to return a content that is optimized for a given skin

The page content could be stored as *.vm file in the component JAR. The returned content is content that has NOT been processed by any renderer. We do not want to make these component renderer-aware as rendering should be done in a centralized manner elsewhere.

The content returned by getPage must not be styled at all. It should try to return only Wiki Markup. When this is not possible it should follow general convention that we'll need to publish as an API for HTML class ids for example.

</example>

4) There are Java UI Interfaces for skins. These are interfaces used by skins.

<example>

Continuing the example above we could have the following:

public interface org.xwiki.core.ui.skin.AdministrationServices { List getPages(...); }

And the component implementing this interface would query the component manager to get all components implementing the org.xwiki.core.ui.AdministrationPage interface, which would be returned as an output of getPages(). Then a skin implementation (*.vm files for example, or JSP pages, or...) would call getPages() to lay out all the administration pages, whether as a tabbed interface or on different physical pages, etc.

</example>

<example> Another example to illustrate this is the Import/Export feature. This could be packaged as a single component which would implement several interfaces, among which this AdministrationPage interface and provide the content for the import and export pages. </example>

WDYT?

After we discuss this and once we agree on it, I'll publish the results on http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2

Thanks -Vincent

-- http://purl.org/net/sergiu

-- You receive this message as a subscriber of the xwiki- dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/ wws

On 3/20/07, Sergiu Dumitriu <sergiu.dumitriu@gmail.com> wrote:

On 3/20/07, Vincent Massol <vincent@massol.net> wrote:

...

On Mar 20, 2007, at 4:31 PM, Sergiu Dumitriu wrote:

Hi,

To me this seems to have too much Java. I was thinking of a more wiki-like solution, using documents, tags and POXO (plain old xwiki objects :p ).

We can discuss pros and cons if you want. Could you explain the solution you would prefer over the one below and why?

An advantage of Java interfaces is that we can enforce a structure For example, administration tabs can have the same structure. What we can do is to have some interfaces, for well structured content like menu entries and the admin tabs. 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)

I think this should be easier using wikimodel. AFAIK, it provides support for events, and a DOM like structure of the wiki page. 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

...

(it can be in .vm files, JSP files, etc). The Java is there for 2 reasons: allow components (in Java) to contribute content so that you can have one single component for example for the importer/exporter, and allow any other part of the code to interact with the UI interfaces (GWT, RCP client, Swing client, etc). Java is the most common denominator and when we have an API in Java it's then easy to access it from any other technology (the other direction is not always true).

Thanks -Vincent

On 3/20/07, Vincent Massol <vincent@massol.net> wrote:

...

Hi,

I'd like to propose the following general principles for the V2 Architecture ( http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2):

1) Components can contribute user interface elements. 2) They contribute them through a Java interface. 3) There's one Java interface for each UI contribution (located in a ui package).

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

For example, we have one interface for contributing Admin Pages (the tabs we have in the administration page when using the albatross skin). For example:

public interface org.xwiki.core.ui.AdministrationPage { Page getPage(Context context); }

where: Page will return the page's content (the implementation could have a "String getContent()" method, and some other fields, like a page id, etc). The context will contain useful information for returning the page. One interesting information is the skin name if some component want to return a content that is optimized for a given skin

The page content could be stored as *.vm file in the component JAR. The returned content is content that has NOT been processed by any renderer. We do not want to make these component renderer-aware as rendering should be done in a centralized manner elsewhere.

The content returned by getPage must not be styled at all. It should try to return only Wiki Markup. When this is not possible it should follow general convention that we'll need to publish as an API for HTML class ids for example.

</example>

4) There are Java UI Interfaces for skins. These are interfaces used by skins.

<example>

Continuing the example above we could have the following:

public interface org.xwiki.core.ui.skin.AdministrationServices { List getPages(...); }

And the component implementing this interface would query the component manager to get all components implementing the org.xwiki.core.ui.AdministrationPage interface, which would be returned as an output of getPages(). Then a skin implementation (*.vm files for example, or JSP pages, or...) would call getPages() to lay out all the administration pages, whether as a tabbed interface or on different physical pages, etc.

</example>

<example> Another example to illustrate this is the Import/Export feature. This could be packaged as a single component which would implement several interfaces, among which this AdministrationPage interface and provide the content for the import and export pages. </example>

WDYT?

After we discuss this and once we agree on it, I'll publish the results on http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2

Thanks -Vincent

-- http://purl.org/net/sergiu

-- http://purl.org/net/sergiu

Hi Sergiu, On 3/22/07, Sergiu Dumitriu <sergiu.dumitriu@gmail.com> wrote:

Just to clarify some things which might cause confusion:

On 3/20/07, Sergiu Dumitriu <sergiu.dumitriu@gmail.com > wrote:

...

On 3/20/07, Vincent Massol <vincent@massol.net> wrote:

...

On Mar 20, 2007, at 4:31 PM, Sergiu Dumitriu wrote:

Hi,

To me this seems to have too much Java. I was thinking of a more

wiki-like solution, using documents, tags and POXO (plain old xwiki objects :p ).

...

...

We can discuss pros and cons if you want. Could you explain the solution

you would prefer over the one below and why?

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)

In your example you expanded #startelement some times to a div tag, but some other time to an img tag (which was wrapped in a div just to make things fit). This probably means in the end you would have a #startelement("div" "id" "class") in the first case, and a #startelement("img" "id" "class") in the second. So one more "tag" argument. To me this seems like reinventing HTML tags in Velocity. Why couldn't we do it in plain HTML using id's and classes for the usual HTML elements (not necessarily divs)? Every element that wants to be an extension point could also have class "ep". At this point I don't see why this wouldn't work. We could just pass the page first through a very simple "extension renderer", which might even expand begin and end tags to velocity #startelement-s and #endelement-s, and then leave the work to Velocity. The advantage of this would be a very simple syntax with which designers are already used to (plain HTML), rather that one that looks like HTML but with an awkward syntax.

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

- 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

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

- 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

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.

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

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

Here is how the same thing would look like in HTML: #foreach($comment in $comments) <div id="comment_${comment.number}" class="ep comment"> <div class="ep commentauthor">${ comment.author} said:</div> <div class="commentbody">${comment.content}</div> </div> #end To me it looks a lot cleaner since I don't have to care how these things are handled internally. Maybe during processing everything is expanded to the version using velocity macros Sergiu presented, but as an interface designer why should I care about that? Also notice that I left out the ep class for the "commentbody" just to exemplify that it can be a lot easier done. In this case this would be a normal div which nobody can extend (which probably makes sense in a lot of cases).

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")

What about something like this? object.content=<img src="$xwiki.getAvatar($comment.author)" class="ep 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

--

Am I missing something ? Catalin

Ok Vincent, sounds cool ! I hope your conference went well ! Luis On 3/21/07, Vincent Massol <vincent@massol.net> 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 :)

-- Luis Arias http://www.xwiki.com +33 6 14 20 87 93 skype : kaaloo

On 3/22/07, Catalin Hritcu <catalin.hritcu@gmail.com> wrote:

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.

We still need to decide who can add a new extension, and who affects such an extension. My first idea is to allow anybody to add EPs and IEs, but unless such a document is certified somehow, it will only affect the current user. We need to make the distinction between global and user-specific extensions. This complicates a bit the algorithm for fast IE output, but I think we can manage to keep it fast enough. Regards,

Catalin

On 3/21/07, Luis Arias <kaaloo@gmail.com> wrote:

...

Ok Vincent, sounds cool ! I hope your conference went well !

Luis

On 3/21/07, Vincent Massol <vincent@massol.net> 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 :)

-- http://purl.org/net/sergiu

Hello, I could add two more open issues. On 3/22/07, Vincent Massol <vincent@massol.net> wrote:

Hi,

After long thoughts where I my opinion swinged in one direction and then in another and then back again, I think Sergiu and Catalin are right. I won't send the 5 emails that I started writing explaining the pros and cons of each approach. Instead, to summarize:

* I like the idea that a Skin is made of a Skin object (defining a general layout and only extension points (no content)) and of SkinElement objects (implementing the extension points). I like it because it allows any user to easily modify only a specific part of the skin by either editing the related page or by providing an implementation of that extension point in a separate page.

* I like the idea of having a special Renderer for expanding expansion points and their implementations. This allows plugging different Renderers if people want to use a different expansion point mechanism (like using PHP for defining their extension points and implementations, using Java API calls, etc).

Open issues:

* We need to define what is an EP Context * We need to somehow autogenerate extension points documentation or it'll never be done. * We need to prevent "DLL Hell". This is my biggest worry... If it's easy to create extension points people will use and abuse them. So an app will provide an extension points used by another app used yet by another one. Then someone changes one version of an app and other apps start failing, etc. So when you install an app you need to make sure you install all the right versions of the dependencies. I would have found it easier to say there's only one dependency on the core and no interapp dependencies. Also the Component Manager knows how to deal with dependencies, versions, etc but I don't see a solution to reuse it and we'll have to code the application/UI extension management features we need I think.

* We need to asses the security implications of such an extension mechanism. For example who will be allowed to extend an arbitrary extension point? There should be a way to enforce that some extension points (like the Administration page) should be extended only by users with proper rights. * We need to find a way to make this interact with frameworks like GWT and TinyMCE, otherwise there will still be no easy way to extend the WYSIWYG editors. This will probably become really important if more functionality starts to be reimplemented in GWT.

Sergiu, what about putting this on http://www.xwiki.org/xwiki/bin/ view/Idea/ArchitectureV2? (Possibly under a new page like ArchitectureV2UIExtensionPoints).

Thanks -Vincent

On Mar 20, 2007, at 11:28 AM, Vincent Massol wrote:

...

Hi,

I'd like to propose the following general principles for the V2 Architecture (http://www.xwiki.org/xwiki/bin/view/Idea/ ArchitectureV2):

1) Components can contribute user interface elements. 2) They contribute them through a Java interface. 3) There's one Java interface for each UI contribution (located in a ui package).

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

For example, we have one interface for contributing Admin Pages (the tabs we have in the administration page when using the albatross skin). For example:

public interface org.xwiki.core.ui.AdministrationPage { Page getPage(Context context); }

where: Page will return the page's content (the implementation could have a "String getContent()" method, and some other fields, like a page id, etc). The context will contain useful information for returning the page. One interesting information is the skin name if some component want to return a content that is optimized for a given skin

The page content could be stored as *.vm file in the component JAR. The returned content is content that has NOT been processed by any renderer. We do not want to make these component renderer-aware as rendering should be done in a centralized manner elsewhere.

The content returned by getPage must not be styled at all. It should try to return only Wiki Markup. When this is not possible it should follow general convention that we'll need to publish as an API for HTML class ids for example.

</example>

4) There are Java UI Interfaces for skins. These are interfaces used by skins.

<example>

Continuing the example above we could have the following:

public interface org.xwiki.core.ui.skin.AdministrationServices { List getPages(...); }

And the component implementing this interface would query the component manager to get all components implementing the org.xwiki.core.ui.AdministrationPage interface, which would be returned as an output of getPages(). Then a skin implementation (*.vm files for example, or JSP pages, or...) would call getPages() to lay out all the administration pages, whether as a tabbed interface or on different physical pages, etc.

</example>

<example> Another example to illustrate this is the Import/Export feature. This could be packaged as a single component which would implement several interfaces, among which this AdministrationPage interface and provide the content for the import and export pages. </example>

WDYT?

After we discuss this and once we agree on it, I'll publish the results on http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2

Thanks -Vincent

-- You receive this message as a subscriber of the xwiki-dev@objectweb.org mailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Another issue: * How do we prevent users from hijacking a selector? Assume an administration link should only appear inside "#admin #searchresults .item", somebody could write empty divs to reproduce this. If the access rights are well defined, then we should not fear this. Anything that will appear this way in the interface, could be accessed in another manner anyway. On 3/25/07, Catalin Hritcu <catalin.hritcu@gmail.com> wrote:

Hello,

I could add two more open issues.

On 3/22/07, Vincent Massol <vincent@massol.net> wrote:

...

Hi,

After long thoughts where I my opinion swinged in one direction and then in another and then back again, I think Sergiu and Catalin are right. I won't send the 5 emails that I started writing explaining the pros and cons of each approach. Instead, to summarize:

* I like the idea that a Skin is made of a Skin object (defining a general layout and only extension points (no content)) and of SkinElement objects (implementing the extension points). I like it because it allows any user to easily modify only a specific part of the skin by either editing the related page or by providing an implementation of that extension point in a separate page.

* I like the idea of having a special Renderer for expanding expansion points and their implementations. This allows plugging different Renderers if people want to use a different expansion point mechanism (like using PHP for defining their extension points and implementations, using Java API calls, etc).

Open issues:

* We need to define what is an EP Context * We need to somehow autogenerate extension points documentation or it'll never be done. * We need to prevent "DLL Hell". This is my biggest worry... If it's easy to create extension points people will use and abuse them. So an app will provide an extension points used by another app used yet by another one. Then someone changes one version of an app and other apps start failing, etc. So when you install an app you need to make sure you install all the right versions of the dependencies. I would have found it easier to say there's only one dependency on the core and no interapp dependencies. Also the Component Manager knows how to deal with dependencies, versions, etc but I don't see a solution to reuse it and we'll have to code the application/UI extension management features we need I think.

* We need to asses the security implications of such an extension mechanism. For example who will be allowed to extend an arbitrary extension point? There should be a way to enforce that some extension points (like the Administration page) should be extended only by users with proper rights. * We need to find a way to make this interact with frameworks like GWT and TinyMCE, otherwise there will still be no easy way to extend the WYSIWYG editors. This will probably become really important if more functionality starts to be reimplemented in GWT.

...

Sergiu, what about putting this on http://www.xwiki.org/xwiki/bin/ view/Idea/ArchitectureV2? (Possibly under a new page like ArchitectureV2UIExtensionPoints).

Thanks -Vincent

On Mar 20, 2007, at 11:28 AM, Vincent Massol wrote:

...

Hi,

I'd like to propose the following general principles for the V2 Architecture (http://www.xwiki.org/xwiki/bin/view/Idea/ ArchitectureV2):

1) Components can contribute user interface elements. 2) They contribute them through a Java interface. 3) There's one Java interface for each UI contribution (located in a ui package).

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

For example, we have one interface for contributing Admin Pages (the tabs we have in the administration page when using the albatross skin). For example:

public interface org.xwiki.core.ui.AdministrationPage { Page getPage(Context context); }

where: Page will return the page's content (the implementation could have a "String getContent()" method, and some other fields, like a page id, etc). The context will contain useful information for returning the page. One interesting information is the skin name if some component want to return a content that is optimized for a given skin

The page content could be stored as *.vm file in the component JAR. The returned content is content that has NOT been processed by any renderer. We do not want to make these component renderer-aware as rendering should be done in a centralized manner elsewhere.

The content returned by getPage must not be styled at all. It should try to return only Wiki Markup. When this is not possible it should follow general convention that we'll need to publish as an API for HTML class ids for example.

</example>

4) There are Java UI Interfaces for skins. These are interfaces used by skins.

<example>

Continuing the example above we could have the following:

public interface org.xwiki.core.ui.skin.AdministrationServices { List getPages(...); }

And the component implementing this interface would query the component manager to get all components implementing the org.xwiki.core.ui.AdministrationPage interface, which would be returned as an output of getPages(). Then a skin implementation (*.vm files for example, or JSP pages, or...) would call getPages() to lay out all the administration pages, whether as a tabbed interface or on different physical pages, etc.

</example>

<example> Another example to illustrate this is the Import/Export feature. This could be packaged as a single component which would implement several interfaces, among which this AdministrationPage interface and provide the content for the import and export pages. </example>

WDYT?

After we discuss this and once we agree on it, I'll publish the results on http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2

Thanks -Vincent

-- http://purl.org/net/sergiu

On 3/25/07, Sergiu Dumitriu <sergiu.dumitriu@gmail.com> wrote:

On 3/22/07, Vincent Massol < vincent@massol.net> wrote:

...

Hi,

After long thoughts where I my opinion swinged in one direction and then in another and then back again, I think Sergiu and Catalin are right. I won't send the 5 emails that I started writing explaining the pros and cons of each approach. Instead, to summarize:

* I like the idea that a Skin is made of a Skin object (defining a general layout and only extension points (no content)) and of SkinElement objects (implementing the extension points). I like it because it allows any user to easily modify only a specific part of the skin by either editing the related page or by providing an implementation of that extension point in a separate page.

* I like the idea of having a special Renderer for expanding expansion points and their implementations. This allows plugging different Renderers if people want to use a different expansion point mechanism (like using PHP for defining their extension points and implementations, using Java API calls, etc).

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.

OK, I think I found something which brings us closer to achieving this. The only way to incrementally add extensions and extension points, without continuously reparsing the rendered content, is to use a SAX-based parser (let's call it EP-parser) on the input and output streams for the renderers, which checks whenever a new tag is introduced if it corresponds to an EP. If it does, then instead of sending the next characters from the original input to be processed, it sends the code of the extension point. However, there is an issue here, with the context. For example, consider the following (pseudo)script: #foreach($i in $xwiki.searchDocuments($someQuery)) #set($qdoc = $xwiki.getDocument($i)) #set($qobj = $qdoc.getObject("Some.Class")) <span class="EP-class">qobj.display("desc")</span> #end ...and an extension which needs the $qobj variable. If the velocity parser uses a buffer, then the SAX-parser will only receive the full list of spans, with the $qobj variable set to the last value. We need to see if Velocity can be forced (or already does) not to use buffers. Then, if the EP-parser and Velocity share the context/vcontext, and if we can stop the current velocity rendering thread after each EP-trigger, we might have a solution (at least for the velocity rendering). We need to see how we can mix the different renderers, so that the velocity context is still available after expanding a radeox macro or filter. Also, we need to consider the WEM (Wiki Event Model) from WikiModel as a possible starting point for the EP-parser. I really have to find some time to take a deeper look at WM. Does anybody see some holes in this solution? Can we start filling in the Ideas page on xwiki.org? Thanks, Sergiu -- http://purl.org/net/sergiu