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:
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/W...
[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:
On 5/28/07, Vincent Massol <[email protected]> wrote:
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
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.
[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 [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic