25 Mar
2007
25 Mar
'07
10:27 p.m.
On 3/25/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
Hello,
I could add two more open issues.
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
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. 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.
If it is defined good enough, it will be usable from anywhere.
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