[ArchitectureV2] UI Interfaces

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[ArchitectureV2] UI Interfaces

vmassol
Administrator
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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Sergiu Dumitriu
Hi,

To me this seems to have too much Java. I was thinking of a more wiki-like solution, using documents, tags and POXO (plain old xwiki objects :p ).

On 3/20/07, Vincent Massol <[hidden email]> 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

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

vmassol
Administrator

On Mar 20, 2007, at 4:31 PM, Sergiu Dumitriu wrote:

Hi,

To me this seems to have too much Java. I was thinking of a more wiki-like solution, using documents, tags and POXO (plain old xwiki objects :p ).

We can discuss pros and cons if you want. Could you explain the solution you would prefer over the one below and why?

Note that the UI content itself is in any technology in the proposal below (it can be in .vm files, JSP files, etc). The Java is there for 2 reasons: allow components (in Java) to contribute content so that you can have one single component for example for the importer/exporter, and allow any other part of the code to interact with the UI interfaces (GWT, RCP client, Swing client, etc). Java is the most common denominator and  when we have an API in Java it's then easy to access it from any other technology (the other direction is not always true).

Thanks
-Vincent

On 3/20/07, Vincent Massol <[hidden email]> 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

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Sergiu Dumitriu


On 3/20/07, Vincent Massol <[hidden email]> wrote:

On Mar 20, 2007, at 4:31 PM, Sergiu Dumitriu wrote:

Hi,

To me this seems to have too much Java. I was thinking of a more wiki-like solution, using documents, tags and POXO (plain old xwiki objects :p ).

We can discuss pros and cons if you want. Could you explain the solution you would prefer over the one below and why?

XWiki promotes the idea that it allows easy collaborative web application development. Such an application might want to add an entry in the menu, or a [ del.icio.us] link to the document footer.
1. If we require users to write a java class, compile it, package it in a jar and distribute it, then we lose the collaborative/online/easy parts.
2. If we list a number of interfaces that can be extended, then we would probably have forgotten the document footer. So we limit the extension points drastically. On the other hand, if we do list all the extension points, then we'll have minor releases with something like "added an EP for this and that", and we'll have dozens of interfaces.
3. I still dream of the wiki that supports importable xar-lets (well, named differently, as we agreed .xar is not a good extension), which can contribute anything, from simple pages to complete skins, interface elements, new classes/templates/sheets. Interface elements seem hard to add if we require java classes, right?


I have developed some Firefox extensions in the past, so I am a bit biased when I insist on taking a XUL-like approach. Here are some ideas (see also http://jira.xwiki.org/jira/browse/XWIKI-649 ):

1. Right now we are putting Interface Elements (IE for short, also stands for Interface Extension) manually in the current skin. The only thing aggregated are the panels. Each of these elements is put in a <div>, maybe with an id and class. In XUL, each element having an id is a possible extension point (EP for short). It would be hard to use divs and ids, that's why we should replace these with something like #startelement("id", "class") and #endelement("id" "class"). These macros create extension points, and they aggregate any content that wants to be included in here. (as a bonus, we can keep a stack of open elements, and when we close an element (with an id) we can automatically close the missing #endelement-s)
2. An IE that wants to extend something can specify an id or/and class name, a position (before, after, at the begin, at the end), and some ordering hints. And the content, of course. What's more, an IE can add new EPs. In the wiki/velocity world, this is best accomplished using XObjects.
2a. If we want to push things to an advanced level, we can make the selection not just by an id or classname, but something like (basic) XPath or like the css (basic) selectors.
3. For java, we can create an interface equivalent to the EP XWiki class. This has the advantages that:
- it's only one interface, similar in Java and the wiki
- it can extend anything
4. #startelement and #endelement are implemented in java, by one or more components (at least one for java IE and one for wiki IE). In order to speed things up, we can make a cache of the extension points. When the platform start, it should search for the available extensions, and already prepare the list of elements to be added for each element. When startelement is called, don't search for anything, just flush the prepared list. We register a listener, so when a page is saved, check if it contains an IE object and update the affected list of extensions.
5. We should document the extension points present in the skins. First of all, we should identify a core list of EPs that should exist in all skins, with the same id/class. Each skin can add new EPs, which must be documented, and we should warn (outside) developers that only core EPs are guaranteed to exist in all the skins.
6. Each xarlet/plugin should list in the documentation the EPs affected and the EPs added. We can have extensions (xarlets) that mainly add a new EP, which other xarlets can use (like greasemonkey does for firefox).

WDYT?

Sergiu

Note that the UI content itself is in any technology in the proposal below (it can be in .vm files, JSP files, etc). The Java is there for 2 reasons: allow components (in Java) to contribute content so that you can have one single component for example for the importer/exporter, and allow any other part of the code to interact with the UI interfaces (GWT, RCP client, Swing client, etc). Java is the most common denominator and  when we have an API in Java it's then easy to access it from any other technology (the other direction is not always true).

Thanks
-Vincent

On 3/20/07, Vincent Massol <[hidden email]> wrote:
Hi,

I'd like to propose the following general principles for the V2
Architecture (<a href="http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> 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 <a href="http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2

Thanks
-Vincent



--
http://purl.org/net/sergiu

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Sergiu Dumitriu

On 3/20/07, Sergiu Dumitriu <[hidden email]> wrote:


On 3/20/07, Vincent Massol <[hidden email]> wrote:

On Mar 20, 2007, at 4:31 PM, Sergiu Dumitriu wrote:

Hi,

To me this seems to have too much Java. I was thinking of a more wiki-like solution, using documents, tags and POXO (plain old xwiki objects :p ).

We can discuss pros and cons if you want. Could you explain the solution you would prefer over the one below and why?

An advantage of Java interfaces is that we can enforce a structure For example, administration tabs can have the same structure. What we can do is to have some interfaces, for well structured content like menu entries and the admin tabs.

XWiki promotes the idea that it allows easy collaborative web application development. Such an application might want to add an entry in the menu, or a [ <a href="http://del.icio.us" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">del.icio.us] link to the document footer.
1. If we require users to write a java class, compile it, package it in a jar and distribute it, then we lose the collaborative/online/easy parts.
2. If we list a number of interfaces that can be extended, then we would probably have forgotten the document footer. So we limit the extension points drastically. On the other hand, if we do list all the extension points, then we'll have minor releases with something like "added an EP for this and that", and we'll have dozens of interfaces.
3. I still dream of the wiki that supports importable xar-lets (well, named differently, as we agreed .xar is not a good extension), which can contribute anything, from simple pages to complete skins, interface elements, new classes/templates/sheets. Interface elements seem hard to add if we require java classes, right?


I have developed some Firefox extensions in the past, so I am a bit biased when I insist on taking a XUL-like approach. Here are some ideas (see also <a href="http://jira.xwiki.org/jira/browse/XWIKI-649" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://jira.xwiki.org/jira/browse/XWIKI-649 ):

1. Right now we are putting Interface Elements (IE for short, also stands for Interface Extension) manually in the current skin. The only thing aggregated are the panels. Each of these elements is put in a <div>, maybe with an id and class. In XUL, each element having an id is a possible extension point (EP for short). It would be hard to use divs and ids, that's why we should replace these with something like #startelement("id", "class") and #endelement("id" "class"). These macros create extension points, and they aggregate any content that wants to be included in here. (as a bonus, we can keep a stack of open elements, and when we close an element (with an id) we can automatically close the missing #endelement-s)

I think this should be easier using wikimodel. AFAIK, it provides support for events, and a DOM like structure of the wiki page.

2. An IE that wants to extend something can specify an id or/and class name, a position (before, after, at the begin, at the end), and some ordering hints. And the content, of course. What's more, an IE can add new EPs. In the wiki/velocity world, this is best accomplished using XObjects.
2a. If we want to push things to an advanced level, we can make the selection not just by an id or classname, but something like (basic) XPath or like the css (basic) selectors.
3. For java, we can create an interface equivalent to the EP XWiki class. This has the advantages that:
- it's only one interface, similar in Java and the wiki
- it can extend anything
4. #startelement and #endelement are implemented in java, by one or more components (at least one for java IE and one for wiki IE). In order to speed things up, we can make a cache of the extension points. When the platform start, it should search for the available extensions, and already prepare the list of elements to be added for each element. When startelement is called, don't search for anything, just flush the prepared list. We register a listener, so when a page is saved, check if it contains an IE object and update the affected list of extensions.
5. We should document the extension points present in the skins. First of all, we should identify a core list of EPs that should exist in all skins, with the same id/class. Each skin can add new EPs, which must be documented, and we should warn (outside) developers that only core EPs are guaranteed to exist in all the skins.
6. Each xarlet/plugin should list in the documentation the EPs affected and the EPs added. We can have extensions (xarlets) that mainly add a new EP, which other xarlets can use (like greasemonkey does for firefox).

WDYT?

Sergiu


Note that the UI content itself is in any technology in the proposal below (it can be in .vm files, JSP files, etc). The Java is there for 2 reasons: allow components (in Java) to contribute content so that you can have one single component for example for the importer/exporter, and allow any other part of the code to interact with the UI interfaces (GWT, RCP client, Swing client, etc). Java is the most common denominator and  when we have an API in Java it's then easy to access it from any other technology (the other direction is not always true).

Thanks
-Vincent

On 3/20/07, Vincent Massol <[hidden email]> wrote:
Hi,

I'd like to propose the following general principles for the V2
Architecture (<a href="http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> 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 <a href="http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2

Thanks
-Vincent



--
<a href="http://purl.org/net/sergiu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://purl.org/net/sergiu



--
http://purl.org/net/sergiu

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

kaaloo
In reply to this post by vmassol
Vincent,

I'm just thinking that one of the requirements for a component
architecture that interacts with the UI is on the order of
granularity.  For instance, maybe a component wishes to insert a menu
item some where in the toolbar, or propose a new panel to be available
to the panel manager, or maybe a new feature in the WYSIWYG editor.
Is the page level API that you are discussing here supposed to cover
these types of participation or integration in the UI ?

Another example, let's say we wish to have a component that enables
entering comments that are linked to content in a page and are
displayed "in situ" instead of at the bottom of the page.

--
Luis Arias
http://www.xwiki.com
+33 6 14 20 87 93
skype : kaaloo



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

vmassol
Administrator

On Mar 21, 2007, at 9:52 AM, Luis Arias wrote:

> Vincent,
>
> I'm just thinking that one of the requirements for a component
> architecture that interacts with the UI is on the order of
> granularity.  For instance, maybe a component wishes to insert a menu
> item some where in the toolbar, or propose a new panel to be available
> to the panel manager, or maybe a new feature in the WYSIWYG editor.
> Is the page level API that you are discussing here supposed to cover
> these types of participation or integration in the UI ?
>
> Another example, let's say we wish to have a component that enables
> entering comments that are linked to content in a page and are
> displayed "in situ" instead of at the bottom of the page.
Luis, I was only discussing general principles and not details. The  
page stuff was only one example of one interface. This is why I said:

"<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>"

:)

Now that said, I need to read Sergiu's emails and answer. That'll  
take me a bit as I'm talking at conference today and this is not  
something you read quickly. I'll need to digest it :)

Thanks
-Vincent




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

kaaloo
Ok Vincent, sounds cool !  I hope your conference went well !

Luis

On 3/21/07, Vincent Massol <[hidden email]> wrote:

>
>
> Luis, I was only discussing general principles and not details. The
> page stuff was only one example of one interface. This is why I said:
>
> "<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>"
>
> :)
>
> Now that said, I need to read Sergiu's emails and answer. That'll
> take me a bit as I'm talking at conference today and this is not
> something you read quickly. I'll need to digest it :)
>
--
Luis Arias
http://www.xwiki.com
+33 6 14 20 87 93
skype : kaaloo



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Catalin Hritcu
It took me quite a while to understand Sergiu's ideas, but now that I
think I did they seem quite convincing. Here are two points on which I
agree with Sergiu.

It's highly unlikely that we can specify all possible extension points
in any interface using XWiki, especially if we want to keep things
easily extensible in the future. So instead of trying to enumerate the
ones we currently know about, it would make sense to use a more
generic way of specifying extension points. For better understanding,
you can view an extension point as something as simple as a HTML id or
class, so just a string identifier.

Another point is that it should be possible to add such extension
points not only from Java components, but also from Velocity, Groovy
or Xwiki objects etc, so from the user interface itself. First,
because it would be convenient for users. Most users will have the
permissions to add new Velocity code for example, while adding a new
Java component is not an option unless you are an administrator.
Second, if the syntax is simple enough the designers themselves will
be able to add the extension points to their user interface, without
needing a programmer's assistance.

Regards,
Catalin

On 3/21/07, Luis Arias <[hidden email]> wrote:

> Ok Vincent, sounds cool !  I hope your conference went well !
>
> Luis
>
> On 3/21/07, Vincent Massol <[hidden email]> wrote:
> >
> >
> > Luis, I was only discussing general principles and not details. The
> > page stuff was only one example of one interface. This is why I said:
> >
> > "<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>"
> >
> > :)
> >
> > Now that said, I need to read Sergiu's emails and answer. That'll
> > take me a bit as I'm talking at conference today and this is not
> > something you read quickly. I'll need to digest it :)
> >
>
> --
> Luis Arias
> http://www.xwiki.com
> +33 6 14 20 87 93
> skype : kaaloo
>
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Sergiu Dumitriu
In reply to this post by Sergiu Dumitriu
Just to clarify some things which might cause confusion:

On 3/20/07, Sergiu Dumitriu <[hidden email]> wrote:


On 3/20/07, Vincent Massol <[hidden email]> wrote:

On Mar 20, 2007, at 4:31 PM, Sergiu Dumitriu wrote:

Hi,

To me this seems to have too much Java. I was thinking of a more wiki-like solution, using documents, tags and POXO (plain old xwiki objects :p ).

We can discuss pros and cons if you want. Could you explain the solution you would prefer over the one below and why?

XWiki promotes the idea that it allows easy collaborative web application development. Such an application might want to add an entry in the menu, or a [ <a href="http://del.icio.us" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">del.icio.us] link to the document footer.
1. If we require users to write a java class, compile it, package it in a jar and distribute it, then we lose the collaborative/online/easy parts.
2. If we list a number of interfaces that can be extended, then we would probably have forgotten the document footer. So we limit the extension points drastically. On the other hand, if we do list all the extension points, then we'll have minor releases with something like "added an EP for this and that", and we'll have dozens of interfaces.
3. I still dream of the wiki that supports importable xar-lets (well, named differently, as we agreed .xar is not a good extension), which can contribute anything, from simple pages to complete skins, interface elements, new classes/templates/sheets. Interface elements seem hard to add if we require java classes, right?


I have developed some Firefox extensions in the past, so I am a bit biased when I insist on taking a XUL-like approach. Here are some ideas (see also <a href="http://jira.xwiki.org/jira/browse/XWIKI-649" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://jira.xwiki.org/jira/browse/XWIKI-649 ):

1. Right now we are putting Interface Elements (IE for short, also stands for Interface Extension) manually in the current skin. The only thing aggregated are the panels. Each of these elements is put in a <div>, maybe with an id and class. In XUL, each element having an id is a possible extension point (EP for short). It would be hard to use divs and ids, that's why we should replace these with something like #startelement("id", "class") and #endelement("id" "class"). These macros create extension points, and they aggregate any content that wants to be included in here. (as a bonus, we can keep a stack of open elements, and when we close an element (with an id) we can automatically close the missing #endelement-s)

- Any one of "id" and "class" can be missing, but not both at the same time.
- If an ID is used more than one time, then it is an interface error. We should provide either a namespace-like feature ("ns", "id", "class"), or require (recommend) a safe naming convention. However, we don't need another stack trace or not-so-user-friendly error message, we should just ignore this error, and the result is that both elements have the same extensions.

2. An IE that wants to extend something can specify an id or/and class name, a position (before, after, at the begin, at the end), and some ordering hints. And the content, of course. What's more, an IE can add new EPs. In the wiki/velocity world, this is best accomplished using XObjects.

- The content can be static text, velocity or groovy code, or a simple call to a java method (we still need a scripting language to make the call).
- If an IE can add content to a class of elements, we need to make sure that the context is known. For example, if we make an extension that adds permalinks to comments, how do we identify the comment? This requires that each EP also list the context-dependent variables that are available, and these variables should have the same name under all skins.
- XObject means XWiki document objects.

2a. If we want to push things to an advanced level, we can make the selection not just by an id or classname, but something like (basic) XPath or like the css (basic) selectors.
3. For java, we can create an interface equivalent to the EP XWiki class. This has the advantages that:
- it's only one interface, similar in Java and the wiki
- it can extend anything

- This is an AND item, not an XOR one. So we have both wiki EP+IE, and java EP+IE, sharing the same structure. So the java interface looks like the wiki class, and a java implementation does the same thing as a wiki object.
- "It can extend anything" means it can be an Interface Extension for any Extension point defined in the wiki or in another java interface component.

4. #startelement and #endelement are implemented in java, by one or more components (at least one for java IE and one for wiki IE). In order to speed things up, we can make a cache of the extension points. When the platform start, it should search for the available extensions, and already prepare the list of elements to be added for each element. When startelement is called, don't search for anything, just flush the prepared list. We register a listener, so when a page is saved, check if it contains an IE object and update the affected list of extensions.
5. We should document the extension points present in the skins. First of all, we should identify a core list of EPs that should exist in all skins, with the same id/class. Each skin can add new EPs, which must be documented, and we should warn (outside) developers that only core EPs are guaranteed to exist in all the skins.

As I said above in another comment, each EP should also list the context-dependent variables that can be used, and when they can be used: at the start or/and at the end.

6. Each xarlet/plugin should list in the documentation the EPs affected and the EPs added. We can have extensions (xarlets) that mainly add a new EP, which other xarlets can use (like greasemonkey does for firefox).

WDYT?

Sergiu

An example is needed for a better understanding:

Scenario: Comments currently don't have user pictures attached (not in the albatross skin). How does an extension that wants to add them work?

Step 1: defining the extension points
The comments should be defined as extension points

#foreach($comment in $comments)
#startelement("comment_${comment.number}" "comment")
#startelement("" "commentauthor")${ comment.author} said: #endelement("" "commentauthor")
#startelement("" "commentbody")${comment.content}#endelement("" "commentbody")
#endelement("comment_${ comment.number}" "comment")
#end

A comment is an extension point with the id of the form "comment_<number>" and the class "comment". It contains two sub-EPs, for the author and the content. The context dependent variable is $comment

Step 2: defining the extension
There should be a document named (for example) Extensions.CommentAvatar, with an attached object with the class Extensions.ExtensionClass

object.name = Avatar for comments
object.selector = .comment
( .class selects a class and #id selects an id )
object.position = start
object.orderRules = first
object.content = #startelement("" "commentavatar")$xwiki.getAvatar($comment.author)#endelement("" "commentavatar")

Note that this avatar is also an extension point, so another extension can put something around the avatar.

Step 3: how things work
The core component managing extension points and interface extensions will detect the fact that Extensions.CommentAvatar is an InterfaceExtension and will register it for the elements having the class "comment" (object.selector). It also knows that it must be placed at the start of the comment (object.position ) and if no other extensions ask to be placed first, it will be the first one to be added (object.orderRules).

When the rendering engine interprets the #startelement macro, it will trigger the extension insertion mechanism.
- First the list of extensions to be placed before the EP is inserted (none here)
- First the html code for an element start is printed : <div id="comment_2" class="comment">
- Then the list of extension that are to be placed at the start of an element (but inside) are inserted. In this case, CommentsAvatar. The content of the object.content is parsed and then it is copied to the output. We need to parse it first because it contains velocity code that must be executed. Because it also defines an EP, there will be a recursive call following the same stes. Result: <div class="commentavatar"><img src=" my.png"/></div>
- The content of the comment is parsed. Result: <div class="commentauthor">John Doe</div><div class="commentbody">Nice thing!</div>
- The list of extension to be placed at the end of the extension point is inserted. None in this case
- The end element is printed: </div>
- The list of extension to be placed after the extension point is inserted. None in this case


So we saw:
- how easy it is to define a new EP (just use #startelement instead of <div id="">)
- what an wiki IE looks like (a simple wiki object)
- how an IE tells what it wants to extend (selector, position, orderRules properties of the object)
- how the insertion algorithm works (outputting the list of extensions before and after the start tag, before and after the end tag of the element)

Using a java extension is pretty much the same, but instead of using a wiki object, we make a class implementing the InterfaceExtension interface, having getters with the same name as the wiki object (getName, getSelector, getContent...)

Hope this clears the fog a bit...

Sergiu
--
http://purl.org/net/sergiu

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Sergiu Dumitriu
In reply to this post by Catalin Hritcu


On 3/22/07, Catalin Hritcu <[hidden email]> wrote:
It took me quite a while to understand Sergiu's ideas, but now that I
think I did they seem quite convincing. Here are two points on which I
agree with Sergiu.

It's highly unlikely that we can specify all possible extension points
in any interface using XWiki, especially if we want to keep things
easily extensible in the future. So instead of trying to enumerate the
ones we currently know about, it would make sense to use a more
generic way of specifying extension points. For better understanding,
you can view an extension point as something as simple as a HTML id or
class, so just a string identifier.

Another point is that it should be possible to add such extension
points not only from Java components, but also from Velocity, Groovy
or Xwiki objects etc, so from the user interface itself. First,
because it would be convenient for users. Most users will have the
permissions to add new Velocity code for example, while adding a new
Java component is not an option unless you are an administrator.
Second, if the syntax is simple enough the designers themselves will
be able to add the extension points to their user interface, without
needing a programmer's assistance.

We still need to decide who can add a new extension, and who affects such an extension. My first idea is to allow anybody to add EPs and IEs, but unless such a document is certified somehow, it will only affect the current user. We need to make the distinction between global and user-specific extensions. This complicates a bit the algorithm for fast IE output, but I think we can manage to keep it fast enough.

Regards,
Catalin

On 3/21/07, Luis Arias <[hidden email]> wrote:

> Ok Vincent, sounds cool !  I hope your conference went well !
>
> Luis
>
> On 3/21/07, Vincent Massol <[hidden email]> wrote:
> >
> >
> > Luis, I was only discussing general principles and not details. The
> > page stuff was only one example of one interface. This is why I said:
> >
> > "<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>"
> >
> > :)
> >
> > Now that said, I need to read Sergiu's emails and answer. That'll
> > take me a bit as I'm talking at conference today and this is not
> > something you read quickly. I'll need to digest it :)
> >
>


--
http://purl.org/net/sergiu

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Catalin Hritcu
In reply to this post by Sergiu Dumitriu
Hi Sergiu,

On 3/22/07, Sergiu Dumitriu <[hidden email]> wrote:

> Just to clarify some things which might cause confusion:
>
> On 3/20/07, Sergiu Dumitriu <[hidden email] > wrote:
> >
> >
> >
> > On 3/20/07, Vincent Massol <[hidden email]> wrote:
> > >
> > >
> > >
> > >
> > > On Mar 20, 2007, at 4:31 PM, Sergiu Dumitriu wrote:
> > >
> > > Hi,
> > >
> > > To me this seems to have too much Java. I was thinking of a more
> wiki-like solution, using documents, tags and POXO (plain old xwiki objects
> :p ).
> > >
> > >
> > >
> > > We can discuss pros and cons if you want. Could you explain the solution
> you would prefer over the one below and why?
> >
> >
> > XWiki promotes the idea that it allows easy collaborative web application
> development. Such an application might want to add an entry in the menu, or
> a [ del.icio.us] link to the document footer.
> > 1. If we require users to write a java class, compile it, package it in a
> jar and distribute it, then we lose the collaborative/online/easy parts.
> > 2. If we list a number of interfaces that can be extended, then we would
> probably have forgotten the document footer. So we limit the extension
> points drastically. On the other hand, if we do list all the extension
> points, then we'll have minor releases with something like "added an EP for
> this and that", and we'll have dozens of interfaces.
> > 3. I still dream of the wiki that supports importable xar-lets (well,
> named differently, as we agreed .xar is not a good extension), which can
> contribute anything, from simple pages to complete skins, interface
> elements, new classes/templates/sheets. Interface elements seem hard to add
> if we require java classes, right?
> >
> >
> > I have developed some Firefox extensions in the past, so I am a bit biased
> when I insist on taking a XUL-like approach. Here are some ideas (see also
> http://jira.xwiki.org/jira/browse/XWIKI-649 ):
> >
> > 1. Right now we are putting Interface Elements (IE for short, also stands
> for Interface Extension) manually in the current skin. The only thing
> aggregated are the panels. Each of these elements is put in a <div>, maybe
> with an id and class. In XUL, each element having an id is a possible
> extension point (EP for short). It would be hard to use divs and ids, that's
> why we should replace these with something like #startelement("id", "class")
> and #endelement("id" "class"). These macros create extension points, and
> they aggregate any content that wants to be included in here. (as a bonus,
> we can keep a stack of open elements, and when we close an element (with an
> id) we can automatically close the missing #endelement-s)
>
In your example you expanded #startelement some times to a div tag,
but some other time to an img tag (which was wrapped in a div just to
make things fit). This probably means in the end you would have a
#startelement("div" "id" "class") in the first case, and a
#startelement("img" "id" "class") in the second. So one more "tag"
argument.

To me this seems like reinventing HTML tags in Velocity. Why couldn't
we do it in plain HTML using id's and classes for the usual HTML
elements (not necessarily divs)? Every element that wants to be an
extension point could also have class "ep". At this point I don't see
why this wouldn't work. We could just pass the page first through a
very simple "extension renderer", which might even expand begin and
end tags to velocity #startelement-s and #endelement-s, and then leave
the work to Velocity.

The advantage of this would be a very simple syntax with which
designers are already used to (plain HTML), rather that one that looks
like HTML but with an awkward syntax.

> - Any one of "id" and "class" can be missing, but not both at the same time.
> - If an ID is used more than one time, then it is an interface error. We
> should provide either a namespace-like feature ("ns", "id", "class"), or
> require (recommend) a safe naming convention. However, we don't need another
> stack trace or not-so-user-friendly error message, we should just ignore
> this error, and the result is that both elements have the same extensions.
>
> >
> >
> > 2. An IE that wants to extend something can specify an id or/and class
> name, a position (before, after, at the begin, at the end), and some
> ordering hints. And the content, of course. What's more, an IE can add new
> EPs. In the wiki/velocity world, this is best accomplished using XObjects.
>
> - The content can be static text, velocity or groovy code, or a simple call
> to a java method (we still need a scripting language to make the call).
> - If an IE can add content to a class of elements, we need to make sure that
> the context is known. For example, if we make an extension that adds
> permalinks to comments, how do we identify the comment? This requires that
> each EP also list the context-dependent variables that are available, and
> these variables should have the same name under all skins.
> - XObject means XWiki document objects.
>
> >
> >
> > 2a. If we want to push things to an advanced level, we can make the
> selection not just by an id or classname, but something like (basic) XPath
> or like the css (basic) selectors.
> > 3. For java, we can create an interface equivalent to the EP XWiki class.
> This has the advantages that:
> > - it's only one interface, similar in Java and the wiki
> > - it can extend anything
>
> - This is an AND item, not an XOR one. So we have both wiki EP+IE, and java
> EP+IE, sharing the same structure. So the java interface looks like the wiki
> class, and a java implementation does the same thing as a wiki object.
> - "It can extend anything" means it can be an Interface Extension for any
> Extension point defined in the wiki or in another java interface component.
>
> >
> >
> > 4. #startelement and #endelement are implemented in java, by one or more
> components (at least one for java IE and one for wiki IE). In order to speed
> things up, we can make a cache of the extension points. When the platform
> start, it should search for the available extensions, and already prepare
> the list of elements to be added for each element. When startelement is
> called, don't search for anything, just flush the prepared list. We register
> a listener, so when a page is saved, check if it contains an IE object and
> update the affected list of extensions.
> > 5. We should document the extension points present in the skins. First of
> all, we should identify a core list of EPs that should exist in all skins,
> with the same id/class. Each skin can add new EPs, which must be documented,
> and we should warn (outside) developers that only core EPs are guaranteed to
> exist in all the skins.
>
> As I said above in another comment, each EP should also list the
> context-dependent variables that can be used, and when they can be used: at
> the start or/and at the end.
>
> >
> >
> > 6. Each xarlet/plugin should list in the documentation the EPs affected
> and the EPs added. We can have extensions (xarlets) that mainly add a new
> EP, which other xarlets can use (like greasemonkey does for firefox).
> >
> > WDYT?
> >
> > Sergiu
>
> An example is needed for a better understanding:
>
> Scenario: Comments currently don't have user pictures attached (not in the
> albatross skin). How does an extension that wants to add them work?
>
> Step 1: defining the extension points
> The comments should be defined as extension points
>
> #foreach($comment in $comments)
> #startelement("comment_${comment.number}" "comment")
> #startelement("" "commentauthor")${ comment.author} said: #endelement(""
> "commentauthor")
> #startelement("" "commentbody")${comment.content}#endelement(""
> "commentbody")
> #endelement("comment_${ comment.number}" "comment")
> #end
>
Here is how the same thing would look like in HTML:

#foreach($comment in $comments)
<div id="comment_${comment.number}" class="ep comment">
   <div class="ep commentauthor">${ comment.author} said:</div>
   <div class="commentbody">${comment.content}</div>
</div>
#end

To me it looks a lot cleaner since I don't have to care how these
things are handled internally. Maybe during processing everything is
expanded to the version using velocity macros Sergiu presented, but as
an interface designer why should I care about that?

Also notice that I left out the ep class for the "commentbody" just to
exemplify that it can be a lot easier done. In this case this would be
a normal div which nobody can extend (which probably makes sense in a
lot of cases).

> A comment is an extension point with the id of the form "comment_<number>"
> and the class "comment". It contains two sub-EPs, for the author and the
> content. The context dependent variable is $comment
>
> Step 2: defining the extension
> There should be a document named (for example) Extensions.CommentAvatar,
> with an attached object with the class Extensions.ExtensionClass
>
> object.name = Avatar for comments
> object.selector = .comment
> ( .class selects a class and #id selects an id )
> object.position = start
> object.orderRules = first
> object.content = #startelement(""
> "commentavatar")$xwiki.getAvatar($comment.author)#endelement(""
> "commentavatar")
>
What about something like this?
object.content=<img src="$xwiki.getAvatar($comment.author)" class="ep
commentavatar"/>

> Note that this avatar is also an extension point, so another extension can
> put something around the avatar.
>
> Step 3: how things work
> The core component managing extension points and interface extensions will
> detect the fact that Extensions.CommentAvatar is an InterfaceExtension and
> will register it for the elements having the class "comment"
> (object.selector). It also knows that it must be placed at the start of the
> comment (object.position ) and if no other extensions ask to be placed
> first, it will be the first one to be added (object.orderRules).
>
> When the rendering engine interprets the #startelement macro, it will
> trigger the extension insertion mechanism.
> - First the list of extensions to be placed before the EP is inserted (none
> here)
> - First the html code for an element start is printed : <div id="comment_2"
> class="comment">
> - Then the list of extension that are to be placed at the start of an
> element (but inside) are inserted. In this case, CommentsAvatar. The content
> of the object.content is parsed and then it is copied to the output. We need
> to parse it first because it contains velocity code that must be executed.
> Because it also defines an EP, there will be a recursive call following the
> same stes. Result: <div class="commentavatar"><img src=" my.png"/></div>
> - The content of the comment is parsed. Result: <div
> class="commentauthor">John Doe</div><div class="commentbody">Nice
> thing!</div>
> - The list of extension to be placed at the end of the extension point is
> inserted. None in this case
> - The end element is printed: </div>
> - The list of extension to be placed after the extension point is inserted.
> None in this case
>
>
> So we saw:
> - how easy it is to define a new EP (just use #startelement instead of <div
> id="">)
> - what an wiki IE looks like (a simple wiki object)
> - how an IE tells what it wants to extend (selector, position, orderRules
> properties of the object)
> - how the insertion algorithm works (outputting the list of extensions
> before and after the start tag, before and after the end tag of the element)
>
> Using a java extension is pretty much the same, but instead of using a wiki
> object, we make a class implementing the InterfaceExtension interface,
> having getters with the same name as the wiki object (getName, getSelector,
> getContent...)
>
> Hope this clears the fog a bit...
>
> Sergiu
>
> --
Am I missing something ?

Catalin



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Sergiu Dumitriu

On 3/22/07, Catalin Hritcu <[hidden email]> wrote:
Hi Sergiu,

> > 1. Right now we are putting Interface Elements (IE for short, also stands
> for Interface Extension) manually in the current skin. The only thing
> aggregated are the panels. Each of these elements is put in a <div>, maybe
> with an id and class. In XUL, each element having an id is a possible
> extension point (EP for short). It would be hard to use divs and ids, that's
> why we should replace these with something like #startelement("id", "class")
> and #endelement("id" "class"). These macros create extension points, and
> they aggregate any content that wants to be included in here. (as a bonus,
> we can keep a stack of open elements, and when we close an element (with an
> id) we can automatically close the missing #endelement-s)
>
In your example you expanded #startelement some times to a div tag,
but some other time to an img tag (which was wrapped in a div just to
make things fit). This probably means in the end you would have a
#startelement("div" "id" "class") in the first case, and a
#startelement("img" "id" "class") in the second. So one more "tag"
argument.

To me this seems like reinventing HTML tags in Velocity. Why couldn't
we do it in plain HTML using id's and classes for the usual HTML
elements (not necessarily divs)? Every element that wants to be an
extension point could also have class "ep". At this point I don't see
why this wouldn't work. We could just pass the page first through a
very simple "extension renderer", which might even expand begin and
end tags to velocity #startelement-s and #endelement-s, and then leave
the work to Velocity.

I know it is difficult to use #startelement and #endelement. This is not a final decision, but rather an idea of how it could be done in the given architecture (velocity + radeox). Maybe it could be done a lot easier in wikimodel.

Using HTML only means that we need to add a new rendering engine, one that expands extension points. It is a better idea, but it needs more work. More, we don't need any special syntax, and it does not depend on velocity. Even more, we're not bound to using only div elements or specifying all the attributes that we might want to set to the generated element; all the markup is already there.

Before jumping to the implementation, we do need to define how exactly is an EP defined, and when and how are they filled in. What we need to decide is the architecture, meaning what is an extension point and what is an extension.

The advantage of this would be a very simple syntax with which
designers are already used to (plain HTML), rather that one that looks
like HTML but with an awkward syntax.


--
http://purl.org/net/sergiu

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

vmassol
Administrator
In reply to this post by vmassol
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
>



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Catalin Hritcu
Hello,

I could add two more open issues.

On 3/22/07, Vincent Massol <[hidden email]> 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 [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Sergiu Dumitriu
In reply to this post by vmassol


On 3/22/07, Vincent Massol <[hidden email]> 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

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Sergiu Dumitriu
In reply to this post by Catalin Hritcu


On 3/25/07, Catalin Hritcu <[hidden email]> wrote:
Hello,

I could add two more open issues.

>
> 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.

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
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

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Sergiu Dumitriu
In reply to this post by Catalin Hritcu
Another issue:

* How do we prevent users from hijacking a selector? Assume an administration link should only appear inside "#admin #searchresults .item", somebody could write empty divs to reproduce this. If the access rights are well defined, then we should not fear this. Anything that will appear this way in the interface, could be accessed in another manner anyway.

On 3/25/07, Catalin Hritcu <[hidden email]> wrote:
Hello,

I could add two more open issues.

On 3/22/07, Vincent Massol <[hidden email]> 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
> >
>
>
>
--
http://purl.org/net/sergiu

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Stéphane Laurière-6
In reply to this post by vmassol
Hi Vincent and all,

Vincent Massol wrote:
[...]

> * 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.
you probably considered it already, but couldn't we try to simply use
the Eclipse UI extension points mechanism?

btw this project may be of interest to us:
Rich Server Platform – User Interface Framework (RSP-UI)
http://www.eclipse.org/proposals/rsp/
"The Eclipse/OSGi development model, applied to the server-side, allows
the creation of truly pluggable, componentized, server-side
applications. Plug-ins can communicate at a logic layer with each other
using established and tested methods, such as extension points and OSGi
services. What is needed for the UI layer is a UI composition framework
which we propose in the form of RSP-UI."


Stéphane




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] UI Interfaces

Sergiu Dumitriu
In reply to this post by Sergiu Dumitriu


On 3/25/07, Sergiu Dumitriu <[hidden email]> wrote:


On 3/22/07, Vincent Massol <[hidden email]> 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.


OK, I think I found something which brings us closer to achieving this.

The only way to incrementally add extensions and extension points, without continuously reparsing the rendered content, is to use a SAX-based parser (let's call it EP-parser) on the input and output streams for the renderers, which checks whenever a new tag is introduced if it corresponds to an EP. If it does, then instead of sending the next characters from the original input to be processed, it sends the code of the extension point.

However, there is an issue here, with the context. For example, consider the following (pseudo)script:

#foreach($i in $xwiki.searchDocuments($someQuery))
#set($qdoc = $xwiki.getDocument($i))
#set($qobj = $qdoc.getObject("Some.Class"))
<span class="EP-class">qobj.display("desc")</span>
#end

...and an extension which needs the $qobj variable. If the velocity parser uses a buffer, then the SAX-parser will only receive the full list of spans, with the $qobj variable set to the last value. We need to see if Velocity can be forced (or already does) not to use buffers. Then, if the EP-parser and Velocity share the context/vcontext, and if we can stop the current velocity rendering thread after each EP-trigger, we might have a solution (at least for the velocity rendering).

We need to see how we can mix the different renderers, so that the velocity context is still available after expanding a radeox macro or filter.

Also, we need to consider the WEM (Wiki Event Model) from WikiModel as a possible starting point for the EP-parser. I really have to find some time to take a deeper look at WM.

Does anybody see some holes in this solution? Can we start filling in the Ideas page on xwiki.org?

Thanks,
Sergiu
--
<a href="http://purl.org/net/sergiu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://purl.org/net/sergiu

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws