Re: [xwiki-dev] [ArchitectureV2] UI Interfaces

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