30 May
2007
30 May
'07
11:07 a.m.
Hi everyone,
The issue of requirements seems very interesting to me with respect to this
discussion. Clearly JCR and XWiki do not have the same requirements but
there is certainly a lot to be learned from a generic content repository
architecture for XWiki. My first thought is that given the importance of
wiki level scripting in XWiki everything must be done to move towards an
easy to use, flexible and powerful system at that level. On the other hand,
a first class citizen abstract JCR compatible content model in the core
sounds like it would also have many advantages including the capacity to
span different concrete repository implementations. Actually the JCR model
proposal is basically a meta model for a domain specific XWiki model at it
seems we would need both to get the best of both worlds.
Now looking at this from the scripting side, it would be very cool at one
point to go even further and actually be able to benefit from a solid
extensible meta model in the core by mapping an XWiki application level data
model composed of Wiki level classes and objects and their relationships
into scripting. For instance, let's say a project management application
and being able to easily navigate between projects, tasks, milestones,
resources and other application level concepts in scripting. It seems to me
that this is the type of thing that could be enabled at one point by having
a solid meta model in place like the one suggested by Stéphane.
Luis
On 5/29/07, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
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 :
--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic
--
You receive this message as a subscriber of the xwiki-dev(a)objectweb.orgmailing 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
--
Luis Arias
http://www.xwiki.com
+33 6 14 20 87 93
skype : kaaloo
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/…
[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.orgmailing 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:
> 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.