29 May
2007
29 May
'07
8:55 p.m.
Hi,
Concerning the XWiki model and the JCR model, this is a really
interesting and important discussion..
There are quite a few benefits to have our objects comply with the JCR
model. I've thought a few times about and XWiki model on top of JCR, and
this not only for storage.
I don't think we should view right away JCR as "storage".. We can
definitively view it as an API also..
The main question we should ask ourselves is:
1/ Can we maintain the old XWiki api to have a layer of compatibility on
top of an XWiki model being a superset of the JCR model.
2/ Can we support a different storage mecanism using the JCR model than
the JCR storage API
3/ Can we extend the JCR model with an XWiki model
4/ Do we like the JCR model (is it a api that is nice to use)
5/ How would the XWiki scripting api (new version, not compatible) look
like using the JCR model
Concerning the mapping of XWiki<->JCR. I'm not sure that Farm is JCR
engine..
In the current usage of the Farm, we have different DBs for different
wikis in a farm.. Are we sure we can get this behavior from
engine/repository
Farm <=> JCR engine
Wiki <=> Repository
Space <=> Node
Ludovic
Vincent Massol a écrit :
Hi everyone,
On May 29, 2007, at 5:43 PM, Stéphane Laurière wrote:
--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic
Hi Vincent, Sergiu and all,
Some remarks below after having discussed today with Mikhail Kotelnikov
(in CC, author of WikiModel, co-founder of Cognium Systems, a partner of
Nepomuk that XWiki company is part of [3]).
[1]
http://nepomuk.semanticdesktop.org/xwiki/bin/view/Components/WikiModel
* WikiModel v2 contains an alpha version of a JavaCC grammar for the
XWiki syntax. WikiModelv2 is common event model working currently with
several wiki syntaxes: creole, gwiki, jspwiki, mediawiki, xwiki.
[2] WikiModel v2 source code download:
http://nepomuk.semanticdesktop.org/xwiki/bin/download/Components/WikiModel/…
[3] http://nepomuk.semanticdesktop.org
[4] http://www.cogniumsystems.com
The topic is not easy, we are aware several strategies are possible,
here's a contribution :-)
Sergiu Dumitriu wrote:
[snip]
That's an interesting idea. However for me the relationship with JCR
is not an advantage and certainly not a requirement. We want our model
classes to be independent on any storage mechanism. However from a
design perspective it's interesting to evaluate how the model classes
could look like if they were using a Node API similar in design to the
JCR (which I don't know so well but I guess it's similar to the DOM
API too).
I can see some pros and cons:
Pros:
- flexibility in that it's easy to add a new node type
- genericity in that it's a hierarchical structure (a graph) and it
would support nested nodes
Cons:
- less strongly typed API in general a more generic API vs a more
business oriented API with the API I proposed. Compare
Space.getDocuments() to node.getElementsByType(NodeType.DOCUMENT). Of
course I guess we could add a SpaceNode class that implements the Node
interface and that method could then have a getDocuments() API which
internally would be implemented as
getElementsByType(NodeType.DOCUMENT). There's still the problem of
doing "if"s on the node type to cast to the correct specific node
class. Personally I've always found the DOM API to be a real pain
(which is probably why there are frameworks like JDOM, DOM4J, etc).
- There are business APIs to implement too (not just navigating) and
these APIs don't make much sense applied to a Node. They do make sense
applied to business objects.
We need to discuss this more and I need to think more about this too
to evaluate the consequences.
Thanks for this interesting discussion Stephane
-Vincent
------------------------------------------------------------------------
--
You receive this message as a subscriber of the xwiki-dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
On 5/28/07, Vincent Massol
<vincent(a)massol.net> wrote:
Couldn't we try to merge the Document, XObject and Attachment classes
into a single class, along the lines of the JCR API where there is
mainly a Node class that can have various types and various properties?
An Attachment would be represented by a Node with a property containing
a binary stream and possibly other properties such as the text
description, the title etc. The advantage of this approach is to
offer a simplified and more flexible model. Hi,
Starting from today I'm going to spend some time every week on the
V2 Architecture/Redesign. Today I'd like to start at the heart of
the topic with the domain model. Here's my proposal:
* Model classes are classes representing the XWiki model. The main
classes are: - Farm - Wiki - Space - Document - XObject - XClass
Attachment