[xwiki-dev] [ArchitectureV2] Model proposal

[Ludovic Dubost]

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/WikiModelV2.zip 
>>
>>
>> [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 <vincent at massol.net> 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 xwiki-dev at objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe at objectweb.org
> For general help: mailto:sympa at objectweb.org?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