25 Mar
2007
25 Mar
'07
1:41 p.m.
Hello,
I could add two more open issues.
On 3/22/07, Vincent Massol <vincent(a)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(a)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