[xwiki-dev] [ArchitectureV2] UI Interfaces

[Sergiu Dumitriu]

On 3/22/07, Vincent Massol <vincent at 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.

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.


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/
> view/Idea/ArchitectureV2? (Possibly under a new page like
> ArchitectureV2UIExtensionPoints).


Sure, but after things are a bit more clear.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xwiki.org/pipermail/devs/attachments/20070325/ac75bd04/attachment.htm