20 Mar
2007
20 Mar
'07
7:02 p.m.
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 <vincent(a)massol.net>
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 xwiki-
dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/
wws