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.

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
>