20 Mar
2007
20 Mar
'07
9:12 p.m.
On 3/20/07, Sergiu Dumitriu <sergiu.dumitriu(a)gmail.com> wrote:
On 3/20/07, Vincent Massol <vincent(a)massol.net> wrote:
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
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?
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)
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
--
http://purl.org/net/sergiu
(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:
--
http://purl.org/net/sergiu
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