[ArchitectureV2] Model proposal
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 - (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API) WDYT? Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome. Thanks -Vincent
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 XPropertyMeta XPropertyDefintion XProperty
- (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Agree
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -Vincent
Agree for XWiki, but I don't know why should we have a Space object in the old Document. Are there any Space methods in the current code? You have my support. As much as my time allows, I'll help you on this. Sergiu -- http://purl.org/net/sergiu
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.
XPropertyMeta
What would XPropertyMeta stand for? With Mikhail we tried to produce a wiki model that can be easily mapped to the JCR model, and we came up with the following core elements: - Node (Document, XObject, Attachment would then be represented using Node instances) - NodeType (JCR terminology, equivalent to XClass) - ID: our proposal would be to create a top level class for IDs so that (i) can have several URIs for the same ID, (2) all manipulations with IDs (renaming: giving a new URI for an ID) are distinct from Node manipulation, (iii) this will allow the implementation of a service dealing only with IDs and URIs separately from the Node implementation. - Session: similar to the XWikiContext and to the JCR Session class: it's the user's context, giving access to all repository services adapted to that context. In addition to these core elements, we should add to the model a Version class, but its scope remains to be discussed. Just to see where we are on the map, we also drew the comparison below between the XWiki2 and JCR models: Farm <=> JCR engine Wiki <=> Repository Space <=> Node Document <=> Node Attachment <=> Node XClass <=> NodeType XPropertyDefinition <=> PropertyDefinition XProperty <=> Property XObject <=> Node From the discussion we had, it appears that at least Cognium Systems would be interested in designing core wiki libraries that could be then used by their collaborative engine in addition to being used by XWiki. Obviously, other companies and researchers are likely to take part in the design of such libraries, given the importance of wikis. We believe that such libraries would have more impact if they are maintained by a wide community of companies and researchers, avoiding the situation where a given community fears to use some library because it has too tight links with a single company. This has to be assessed, though. What do you think? Within Nepomuk, we're currently designing such core wiki libraries. We will upload a Node API proposal this week, and we plan to implement it on top of Jackrabbit by mid-june. The more we can share efforts toward a sound and flexible implementation of the core services, the better, but obviously the XWiki2 strategy regarding the Nepomuk effort remains to be investigated and discussed. Stéphane and Mikhail
XPropertyDefintion XProperty
- (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Agree
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -Vincent
Agree for XWiki, but I don't know why should we have a Space object in the old Document. Are there any Space methods in the current code?
You have my support. As much as my time allows, I'll help you on this.
Sergiu
-- Stéphane Laurière [email protected] XWiki Research http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org
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 <[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
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
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 <[email protected]> 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 :
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] 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
-- You receive this message as a subscriber of the [email protected] 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
-- Luis Arias http://www.xwiki.com +33 6 14 20 87 93 skype : kaaloo
On 5/29/07, Vincent Massol <[email protected]> wrote:
Hi everyone,
On May 29, 2007, at 5:43 PM, Stéphane Laurière wrote:
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
We have something similar already. All model classes are derived from BaseElement, and those that have sub-items are derived from BaseCollection, like: Object |_ BaseElement |____ BaseProperty | |_ StringProperty, DateProperty, NumberProperty... |____ BaseCollection |_ BaseClass | |_ PropertyMetaClass |_ BaseObject |_ PropertyClass So, a Node can be the equivalent of BaseElement. -- http://purl.org/net/sergiu
On 5/29/07, Stéphane Laurière <[email protected]> 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.
We can make a unified API for all these classes, and (as I said in my previous email) we already have something similar with BaseElement/BaseCollection. But I don't agree that this is where we should stop. Having specific classes to ease the usage is a must. Like Vincent said, why call node.getElementsByType(NodeType.DOCUMENT) when we know we want the documents in a space? This is why DOM didn't stop at Node, and it provides Attribute and Element interfaces, and even specific interfaces for the elements in HTML.
XPropertyMeta
What would XPropertyMeta stand for?
XPropertyMeta is the definition of XPropertyDefinition; a Meta lists the various settings for the different types of properties, thus defining what is a StringProperty, what is a NumberProperty, etc.
With Mikhail we tried to produce a wiki model that can be easily mapped to the JCR model, and we came up with the following core elements:
Why the JCR model? Does it provide any advantages that cannot be easily obtained with a different model? We should keep the model independent from the actual storage, because there are lots of storage models: relational, JCR, XML, RDF, db4o are the ones that get in my mind right now.
- Node (Document, XObject, Attachment would then be represented using Node instances) - NodeType (JCR terminology, equivalent to XClass)
- ID: our proposal would be to create a top level class for IDs so that (i) can have several URIs for the same ID, (2) all manipulations with IDs (renaming: giving a new URI for an ID) are distinct from Node manipulation, (iii) this will allow the implementation of a service dealing only with IDs and URIs separately from the Node implementation.
This is something I like. We should make ID-s independent from the name, as at the moment ID-s are strongly related to the name of the document, classname and number of the object. And this makes renames very hard, and aliases almost impossible.
- Session: similar to the XWikiContext and to the JCR Session class: it's the user's context, giving access to all repository services adapted to that context.
Is a session part of the *data* model?
In addition to these core elements, we should add to the model a Version class, but its scope remains to be discussed.
Just to see where we are on the map, we also drew the comparison below between the XWiki2 and JCR models: Farm <=> JCR engine Wiki <=> Repository Space <=> Node Document <=> Node Attachment <=> Node XClass <=> NodeType XPropertyDefinition <=> PropertyDefinition XProperty <=> Property XObject <=> Node
From the discussion we had, it appears that at least Cognium Systems would be interested in designing core wiki libraries that could be then used by their collaborative engine in addition to being used by XWiki. Obviously, other companies and researchers are likely to take part in the design of such libraries, given the importance of wikis. We believe that such libraries would have more impact if they are maintained by a wide community of companies and researchers, avoiding the situation where a given community fears to use some library because it has too tight links with a single company. This has to be assessed, though. What do you think?
I agree.
Within Nepomuk, we're currently designing such core wiki libraries. We will upload a Node API proposal this week, and we plan to implement it on top of Jackrabbit by mid-june. The more we can share efforts toward a sound and flexible implementation of the core services, the better, but obviously the XWiki2 strategy regarding the Nepomuk effort remains to be investigated and discussed.
Stéphane and Mikhail
XPropertyDefintion XProperty
- (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Agree
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -Vincent
Agree for XWiki, but I don't know why should we have a Space object in the old Document. Are there any Space methods in the current code?
You have my support. As much as my time allows, I'll help you on this.
Sergiu
-- Stéphane Laurière [email protected]
XWiki Research http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org
Sergiu -- http://purl.org/net/sergiu
I'll answer in a separate mail the discussion about JCR.. Sergiu Dumitriu a écrit :
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 I prefer MultiWiki
- Wiki - Space - Document - XObject I agree with Stephane that we should look to merge Document, XObject into XObject, Document should be a superset of XObject. Attachment I think should not be a superset of XObject put a superset of XProperty
- XClass
Attachment XPropertyMeta XPropertyDefintion
I don't understand the difference between XPropertyMeta and XPropertyDefinition I would prefer XMetaProperty or XClassProperty or XPropertyClass (we are using PropertyClass currently) There is also XMetaClass to define the class.
XProperty
Ludovic I -- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
Some more details on this topic: * We should have a consistent naming. Either we use XObjects/XClass and then we have to use X in front of everything: XFarm, XWiki (funny), XSpace, XDocument, etc or we agree that the namespace is enough (org.xwiki.model) to indicate that these are all XWiki classes and we drop the X. This is my preference. When we write documentation we can refer to XObjects/XClass/ to separate them from Java Objects/ Class though. * Here's a cardinality and dependency graph of main model classes: (Farm) 1 --> * (Wiki) 1 --> * (Space) 1 --> * (Document) 1 --> * (Object) 1 --> * (Property) * I want to come back on something I said in the email below. I said the Model classes shouldn't depend on any other component. I don't think this is true anymore. The reason is that I think we need to model the cardinality defined above in the model classes. For example: Farm: - addWiki(Wiki wiki) - removeWiki(String wikiName) - List getWikis() - Wiki getWiki(String wikiName) Wiki: - addSpace(Space space) - removeSpace(String spaceName) - List getSpaces() - Space getSpace(String spaceName) - Farm getFarm() Space: - addDocument(Document document) - removeDocument(String documentName) - List getDocuments() - Document getDocument(String documentName) - Wiki getWiki() The same applies to Document and Object. Now the interesting part is what happens for example when Space.getDocuments() is called? The user will expect that it returns the lists of documents in the space. This requires access to the storage component. Thus I now believe we should have the model classes have the storage component injected. The alternative is either to not have the above-defined methods in the model classes (which I think would be a pity) or have some external services to load the data in the model objects. But that's tricky because it would mean loading the whole object graph at once or doing some tricky transparent lazy loading. Thus my preference goes to adding a dependency to the storage component in the model classes. * Now we'll want to cache data instead of hitting the database every time. We could do this in several ways: using the database cache, using a delegating caching storage implementation or doing the caching in the model classes themselves using a caching service. I'm not sure here but a delegation at the level of the storage component sounds nicer to me at first glance. WDYT? Thanks -Vincent On May 28, 2007, at 9:38 AM, Vincent Massol 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 - (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -Vincent
On 5/29/07, Vincent Massol <[email protected]> wrote:
Some more details on this topic:
* We should have a consistent naming. Either we use XObjects/XClass and then we have to use X in front of everything: XFarm, XWiki (funny), XSpace, XDocument, etc or we agree that the namespace is enough (org.xwiki.model) to indicate that these are all XWiki classes and we drop the X. This is my preference. When we write documentation we can refer to XObjects/XClass/ to separate them from Java Objects/ Class though.
I'm for the second option, with the minor objection that I don't like having an Object class. Name collision with the most used class in the Java world. But I can deal with this inconvenience.
* Here's a cardinality and dependency graph of main model classes:
(Farm) 1 --> * (Wiki) 1 --> * (Space) 1 --> * (Document) 1 --> * (Object) 1 --> * (Property)
There's also: (Document) 1 --> 0..1 (Class) 1 --> * (PropertyDefinition) 1 --> 1 (PropertyMeta) 1 --> * (PropertyDefinition) 1 --> * (primitives [string, int]) This is the current model, and it might need adjustments. For example, the PropertyMeta can only be defined in the Java world in this model, and we'd like to change this.
* I want to come back on something I said in the email below. I said the Model classes shouldn't depend on any other component. I don't think this is true anymore. The reason is that I think we need to model the cardinality defined above in the model classes. For example:
Farm: - addWiki(Wiki wiki) - removeWiki(String wikiName) - List getWikis() - Wiki getWiki(String wikiName)
Wiki: - addSpace(Space space) - removeSpace(String spaceName) - List getSpaces() - Space getSpace(String spaceName) - Farm getFarm()
Space: - addDocument(Document document) - removeDocument(String documentName) - List getDocuments() - Document getDocument(String documentName) - Wiki getWiki()
The same applies to Document and Object.
Now the interesting part is what happens for example when Space.getDocuments() is called? The user will expect that it returns the lists of documents in the space. This requires access to the storage component. Thus I now believe we should have the model classes have the storage component injected. The alternative is either to not have the above-defined methods in the model classes (which I think would be a pity) or have some external services to load the data in the model objects. But that's tricky because it would mean loading the whole object graph at once or doing some tricky transparent lazy loading. Thus my preference goes to adding a dependency to the storage component in the model classes.
Here's something I don't like in the current core: $xwiki.getDocument("Some.Doc").getObject("Some.Class", 13) When calling this, the document, along with all its attachments, objects, class, is completely restored from the database. If there are 500 objects, and I'm only interested in number 13, there's a complete waste of time and memory. We should consider this when deciding how do we retrieve stuff from the storage. Lazy types are not good, as they are storage dependent. Hibernate has this feature, but how about XML Database servers, or JCR? We'd probably have to write our own storage-dependent wrappers. On the other hand, I'd like *not* to have a storage dependency inside the model classes. The model should only contain data. Pros and cons of lazy loading data: Pros - We can reduce the amount of time/memory needed to load a document - There's no dependency on the storage inside the model Cons - We need an intermediate between storage and model (decorator?) - We might have to write the intermediate along with the storage, as not all storage systems support lazy loading. This is not as bad as it looks, because basically we're moving storage.load() from a model class to a decorator class, and the decorator can be storage-dependent. Can we use JPOX ( http://www.jpox.org/ ) as the decorator for some storage systems? Should we?
* Now we'll want to cache data instead of hitting the database every time. We could do this in several ways: using the database cache, using a delegating caching storage implementation or doing the caching in the model classes themselves using a caching service. I'm not sure here but a delegation at the level of the storage component sounds nicer to me at first glance.
+1 for the storage cache. The data model should not be concerned with caching.
WDYT?
Thanks -Vincent
On May 28, 2007, at 9:38 AM, Vincent Massol 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 - (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -Vincent
Sergiu -- http://purl.org/net/sergiu
On May 30, 2007, at 12:59 AM, Sergiu Dumitriu wrote: [snip]
Lazy types are not good, as they are storage dependent. Hibernate has this feature, but how about XML Database servers, or JCR? We'd probably have to write our own storage-dependent wrappers.
On the other hand, I'd like *not* to have a storage dependency inside the model classes. The model should only contain data.
The model should only contain data AND behaviors associated with this data. For example I'm pretty confident we want to have Space.getDocuments() for example in the model.
Pros and cons of lazy loading data: Pros - We can reduce the amount of time/memory needed to load a document
Well this is the same as with the other option I believe as for example we would retrieve documents only when Space.getDocuments() get called the first time. Or do you mean something else?
- There's no dependency on the storage inside the model
There's a dependency but it's a runtime dependency rather than a source time dependency.
Cons - We need an intermediate between storage and model (decorator?)
Yes, this requires some magic (byte code enhancement) if you want to make it transparent. Otherwise you need an API to load data and then only you're allowed to use the domain objects, which isn't nice.
- We might have to write the intermediate along with the storage, as not all storage systems support lazy loading. This is not as bad as it looks, because basically we're moving storage.load() from a model class to a decorator class, and the decorator can be storage-dependent.
Can we use JPOX ( http://www.jpox.org/ ) as the decorator for some storage systems? Should we?
Yes we could. I know someone who's using it. I'll check with him. [snip] Thanks -Vincent
On 5/30/07, Vincent Massol <[email protected]> wrote:
On May 30, 2007, at 12:59 AM, Sergiu Dumitriu wrote:
[snip]
Lazy types are not good, as they are storage dependent. Hibernate has this feature, but how about XML Database servers, or JCR? We'd probably have to write our own storage-dependent wrappers.
On the other hand, I'd like *not* to have a storage dependency inside the model classes. The model should only contain data.
The model should only contain data AND behaviors associated with this data. For example I'm pretty confident we want to have Space.getDocuments() for example in the model.
Of course. Data alone = storage.
Pros and cons of lazy loading data: Pros - We can reduce the amount of time/memory needed to load a document
Well this is the same as with the other option I believe as for example we would retrieve documents only when Space.getDocuments() get called the first time. Or do you mean something else?
Not quite. Space.getDocuments can do: 1. load from the storage all the documents in that space 2. load a lazy list that reflects the number of documents in the database. When we try to access an entry in the database, we load that document, and only that document.
- There's no dependency on the storage inside the model
There's a dependency but it's a runtime dependency rather than a source time dependency.
The dependency is hidden inside the decorator, and isn't visible in the model classes. So yes, it's a runtime dependency.
Cons - We need an intermediate between storage and model (decorator?)
Yes, this requires some magic (byte code enhancement) if you want to make it transparent. Otherwise you need an API to load data and then only you're allowed to use the domain objects, which isn't nice.
I don't understand what "domain objects" are. Can you explain?
- We might have to write the intermediate along with the storage, as not all storage systems support lazy loading. This is not as bad as it looks, because basically we're moving storage.load() from a model class to a decorator class, and the decorator can be storage-dependent.
Can we use JPOX ( http://www.jpox.org/ ) as the decorator for some storage systems? Should we?
Yes we could. I know someone who's using it. I'll check with him.
[snip]
Thanks -Vincent
Sergiu -- http://purl.org/net/sergiu
On May 30, 2007, at 11:54 AM, Sergiu Dumitriu wrote: [snip]
Pros and cons of lazy loading data: Pros - We can reduce the amount of time/memory needed to load a document
Well this is the same as with the other option I believe as for example we would retrieve documents only when Space.getDocuments() get called the first time. Or do you mean something else?
Not quite. Space.getDocuments can do: 1. load from the storage all the documents in that space 2. load a lazy list that reflects the number of documents in the database. When we try to access an entry in the database, we load that document, and only that document.
Ok I agree but this can be done with either solutions. So I think we agree we want to have the Space.getDocuments() methods in the model classes and calling them will return database data (either when they are called or when the relationship is navigated).
- There's no dependency on the storage inside the model
There's a dependency but it's a runtime dependency rather than a source time dependency.
The dependency is hidden inside the decorator, and isn't visible in the model classes. So yes, it's a runtime dependency.
One drawback is that you need to tell somewhere where you want the interceptor to plug into. This can be done with a configuration file (I don't know how jpox does it) or it can be done using some annotation. In that case we come back to a source dependency but it has the advantage of being more maintainable (otherwise you need to ensure you config file and your class/methode names are always in sync).
Cons - We need an intermediate between storage and model (decorator?)
Yes, this requires some magic (byte code enhancement) if you want to make it transparent. Otherwise you need an API to load data and then only you're allowed to use the domain objects, which isn't nice.
I don't understand what "domain objects" are. Can you explain?
I meant model classes. [snip] Thanks -Vincent
Hi, On 5/30/07, Sergiu Dumitriu <[email protected]> wrote:
On 5/29/07, Vincent Massol <[email protected]> wrote:
Some more details on this topic:
* We should have a consistent naming. Either we use XObjects/XClass and then we have to use X in front of everything: XFarm, XWiki (funny), XSpace, XDocument, etc or we agree that the namespace is enough (org.xwiki.model) to indicate that these are all XWiki classes and we drop the X. This is my preference. When we write documentation we can refer to XObjects/XClass/ to separate them from Java Objects/ Class though.
I'm for the second option, with the minor objection that I don't like having an Object class. Name collision with the most used class in the Java world. But I can deal with this inconvenience.
Sorry if I seem picky about a naming issue, but I think that naming any class Class or Object is _extremely_ confusing, not only in the discussions but also when reading code. One of the many reasons is that the java.lang package doesn't need to be imported explicitly. We already had a proposal we accepted to call them XClass and XObject: http://mail-archive.objectweb.org/xwiki-dev/2007-04/msg00073.html I think that naming consistency should not come at the expense of clarity. And if you still want naming consistency then I suggest calling them MetaClass and MetaObject, instead of perpending all the other concepts by an "X". Regards, Catalin
On May 31, 2007, at 7:17 PM, Catalin Hritcu wrote:
Hi,
On 5/30/07, Sergiu Dumitriu <[email protected]> wrote:
On 5/29/07, Vincent Massol <[email protected]> wrote:
Some more details on this topic:
* We should have a consistent naming. Either we use XObjects/XClass and then we have to use X in front of everything: XFarm, XWiki (funny), XSpace, XDocument, etc or we agree that the namespace is enough (org.xwiki.model) to indicate that these are all XWiki classes and we drop the X. This is my preference. When we write documentation we can refer to XObjects/XClass/ to separate them from Java Objects/ Class though.
I'm for the second option, with the minor objection that I don't like having an Object class. Name collision with the most used class in the Java world. But I can deal with this inconvenience.
Sorry if I seem picky about a naming issue, but I think that naming any class Class or Object is _extremely_ confusing, not only in the discussions but also when reading code. One of the many reasons is that the java.lang package doesn't need to be imported explicitly. We already had a proposal we accepted to call them XClass and XObject: http://mail-archive.objectweb.org/xwiki-dev/2007-04/msg00073.html
I think that naming consistency should not come at the expense of clarity.
In that case they shouldn't be named XClass and XObject because this doesn't mean much. In no time we'll start calling XWiki developers X- Men... ;-) If we want to say "XWiki Class/Object" they should be named XWikiClass and XWikiObject. Same for Document, Space, Farm, etc because for example Document can be confused with DOM Document class, and we can probably find other libraries using Space, Farm, etc. Personally Class/Object doesn't bother me as it's in a separate namespace.
And if you still want naming consistency then I suggest calling them MetaClass and MetaObject, instead of perpending all the other concepts by an "X".
Yes, that's a good idea. If we wanted to go that way, we could also call them something more business oriented like Definition (for Class) and DocumentMetadata (for Object). But I'm not 100% convinced yet we need to rename them. We can think about it. For now I think the most important decision is deciding what we do with Stephane's proposition of a JCR-like model. Thanks -Vincent
We should also consider the following use-cases: Class inheritance. We have User as a generic wiki user, Teacher as a user that has a scientific title, a department, etc, Student as a user that has a generation, an ID, a status... This can also be achieved by placing more objects on the same page, but it's not nice, and it certainly requires more Velocity code (I know, I had to implement something like this). We should consider multiple inheritance and deep hierarchies, too. Objects with more than one class. There are some users that are both Student and Teacher. It's not nice to explicitly create a class inheriting both parent classes, so instead we should combine them in-place, like an anonymous class. Another example, consider a BlogArticle that describes an Event; we could write a single object that will be displayed in the blog and in the EventCalendar. Anonymous objects. We can write objects that don't have a fixed structure, but are rather a collection of properties defined ad-hoc. Anonymous object properties. We can add some extra properties to a typed object, although they are not specified in the class. Anonymous document properties. We should be able to add properties directly to the document, not just to an object. These properties act like document metadata. Re-casting objects. Should we allow changing the type of an object? For example, a Student graduated and was hired as a Professor. Also, if we allow adding a new class to an object, do we also allow removing one? Observations: The properties added to a document, or an object, should be defined somewhere or not? Meaning, in order to add an "StartDate" property to an object, should we define it in the wiki, or the user just enters both the name and the value? I'd say yes, as in RDF a property must be defined before being used. We should be able to remove from an object anonymous properties, but not the properties defined in the object's class. When removing a class from an object, or recasting an object, the properties that are no longer defined in a class should remain as anonymous properties until manually removed? 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 - (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -Vincent
Sergiu -- http://purl.org/net/sergiu
ok I'll try to summarize my current thinking after all the exchanged emails: * I don't think we should model our Model classes using a similar API as the JCR one. I much prefer we have an expressive Model with a strongly typed API, with objects like Document, Space, MetaData, Farm, Wiki, etc. Stephane, I keep turning this in my head and I can't figure a good reason to have a JRC like API for our model. Maybe you're seeing something that I don't see? Ludovic also said "[...] quite a few benefits to have our objects comply with the JCR model". I don't see them so maybe someone could enlighten me. * Our model classes should call the storage interface for any methods requiring storage access (for example: Space.getDocuments()). If other services are required they should be called out too. We still need to define a rule for when a new method can be added to the model classes and when a new component should rather be created. I have some ideas but I'm not 100% sure here so I'd like to hear what you think. * I think it would be a good idea to have our model defined independently of the language (for example in XML - Here's for example the Maven model defined in xml: http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/ src/main/mdo/maven.mdo The reason is that this will allow us to generate lots of things from this model: - Java bindings - XSD - Documentation - Any other language bindings - etc We could use Modello for doing this. It's well integrated into Maven2 and is easy to use. * I don't think we should use JPOX. Jason, whom I trust, says it's been a bad decision for Continuum (they use jpox) and that there are only 2 active developers for jpox which makes bugs take time to fix, etc. In addition, I'm not sure what this would buy us as I think we should have storage interface and a JCR implementation of it that would map to whatever underlying store is configured. Not sure where we would fit JPOX in there. WDYT? Thanks -Vincent On May 28, 2007, at 9:38 AM, Vincent Massol 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 - (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -Vincent
-- You receive this message as a subscriber of the xwiki- [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
On 6/4/07, Vincent Massol <[email protected]> wrote:
ok I'll try to summarize my current thinking after all the exchanged emails:
* I don't think we should model our Model classes using a similar API as the JCR one. I much prefer we have an expressive Model with a strongly typed API, with objects like Document, Space, MetaData, Farm, Wiki, etc. Stephane, I keep turning this in my head and I can't figure a good reason to have a JRC like API for our model. Maybe you're seeing something that I don't see? Ludovic also said "[...] quite a few benefits to have our objects comply with the JCR model". I don't see them so maybe someone could enlighten me.
I don't see those benefits, either. So I'm +1 for your proposal.
* Our model classes should call the storage interface for any methods requiring storage access (for example: Space.getDocuments()). If other services are required they should be called out too. We still need to define a rule for when a new method can be added to the model classes and when a new component should rather be created. I have some ideas but I'm not 100% sure here so I'd like to hear what you think.
This requires less programming than writing our own lazy loaders, and is safer than using JPOX. I wish there was a better method to hide the storage, and still not load the complete database in memory. Btw, space.getDocuments() returns all the documents in that space, fully loaded? space.getDocumentsNames() loads the list of documents, or just retrieves the names? Regarding the latter issue, we should try to make the components as stable as possible. After we all agree on a component, we need strong reasons to introduce something new. Another issue, as far as I remember, components should be interfaces. Will the model be an interface, too, with a default implementation? Or will it not be a component?
* I think it would be a good idea to have our model defined independently of the language (for example in XML - Here's for example the Maven model defined in xml: http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/ src/main/mdo/maven.mdo
+1 on that, as I'm a total adept of XML. But, what language should we use for the definition? I'd go for XSD, as I know nothing about Modello.
The reason is that this will allow us to generate lots of things from this model: - Java bindings - XSD - Documentation - Any other language bindings - etc
We could use Modello for doing this. It's well integrated into Maven2 and is easy to use.
* I don't think we should use JPOX. Jason, whom I trust, says it's been a bad decision for Continuum (they use jpox) and that there are only 2 active developers for jpox which makes bugs take time to fix, etc. In addition, I'm not sure what this would buy us as I think we should have storage interface and a JCR implementation of it that would map to whatever underlying store is configured. Not sure where we would fit JPOX in there.
OK. I mentioned JPOX only because I encountered it on several forums, and proposed it as an alternative.
WDYT?
Thanks -Vincent
On May 28, 2007, at 9:38 AM, Vincent Massol 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 - (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -Vincent
Sergiu -- http://purl.org/net/sergiu
One more question. Do the model classes perform access rights checks? Or we assume that once they get past the API everything is OK? I'd say that all the rights checks should be performed outside the model; perhaps the API, as it is now. Btw, do we keep the "API" name for the scriptable model wrapper? On 6/4/07, Sergiu Dumitriu <[email protected]> wrote:
On 6/4/07, Vincent Massol <[email protected]> wrote:
ok I'll try to summarize my current thinking after all the exchanged emails:
* I don't think we should model our Model classes using a similar API as the JCR one. I much prefer we have an expressive Model with a strongly typed API, with objects like Document, Space, MetaData, Farm, Wiki, etc. Stephane, I keep turning this in my head and I can't figure a good reason to have a JRC like API for our model. Maybe you're seeing something that I don't see? Ludovic also said "[...] quite a few benefits to have our objects comply with the JCR model". I don't see them so maybe someone could enlighten me.
I don't see those benefits, either. So I'm +1 for your proposal.
* Our model classes should call the storage interface for any methods requiring storage access (for example: Space.getDocuments()). If other services are required they should be called out too. We still need to define a rule for when a new method can be added to the model classes and when a new component should rather be created. I have some ideas but I'm not 100% sure here so I'd like to hear what you think.
This requires less programming than writing our own lazy loaders, and is safer than using JPOX. I wish there was a better method to hide the storage, and still not load the complete database in memory.
Btw, space.getDocuments() returns all the documents in that space, fully loaded? space.getDocumentsNames() loads the list of documents, or just retrieves the names?
Regarding the latter issue, we should try to make the components as stable as possible. After we all agree on a component, we need strong reasons to introduce something new.
Another issue, as far as I remember, components should be interfaces. Will the model be an interface, too, with a default implementation? Or will it not be a component?
* I think it would be a good idea to have our model defined independently of the language (for example in XML - Here's for example the Maven model defined in xml: http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/ src/main/mdo/maven.mdo
+1 on that, as I'm a total adept of XML. But, what language should we use for the definition? I'd go for XSD, as I know nothing about Modello.
The reason is that this will allow us to generate lots of things from this model: - Java bindings - XSD - Documentation - Any other language bindings - etc
We could use Modello for doing this. It's well integrated into Maven2 and is easy to use.
* I don't think we should use JPOX. Jason, whom I trust, says it's been a bad decision for Continuum (they use jpox) and that there are only 2 active developers for jpox which makes bugs take time to fix, etc. In addition, I'm not sure what this would buy us as I think we should have storage interface and a JCR implementation of it that would map to whatever underlying store is configured. Not sure where we would fit JPOX in there.
OK. I mentioned JPOX only because I encountered it on several forums, and proposed it as an alternative.
WDYT?
Thanks -Vincent
On May 28, 2007, at 9:38 AM, Vincent Massol 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 - (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -Vincent
Sergiu -- http://purl.org/net/sergiu
On Jun 4, 2007, at 9:34 PM, Sergiu Dumitriu wrote: [snip]
* Our model classes should call the storage interface for any methods requiring storage access (for example: Space.getDocuments()). If other services are required they should be called out too. We still need to define a rule for when a new method can be added to the model classes and when a new component should rather be created. I have some ideas but I'm not 100% sure here so I'd like to hear what you think.
This requires less programming than writing our own lazy loaders, and is safer than using JPOX. I wish there was a better method to hide the storage, and still not load the complete database in memory.
Btw, space.getDocuments() returns all the documents in that space, fully loaded?
Yes. We need to think about how many methods do we offer in the Model API. For example do we offer: Space.getDocuments(DocumentFilter filter) Space.getDocuments(Query query) Space.getDocument(String name) Space.getDocumentsForXXX(...) or do we create some external Search components for each Model class? I think we could get away with a single Space.getDocument (DocumentFilter filter) + Space.getDocument(String), where DocumentFilter is a way to filter documents independent of the underlying storage mechanism. And we can then have some other Query component that transforms free form queries (like hibernate queries) into DocumentFilter objects (or whatever we want to call it). I haven't thought much about the DocumentFilter API itself but we would need something pretty generic. Anyway the question here right now is whether we think Space.getDocument(DocumentFilter filter) is enough or not? If we agree it's enough then I wonder if Space.getDocuments() should stay. I would be in favor of removing it. It would be replaced by Space.getDocuments(DocumentFilter.ALL). I really like minimal APIs and I don't think overloaded methods should go in the Model classes. But everything has pros and cons. One con: Someone may later create a SpaceHelper.getAllDocuments() helper method/component... Other question: Transversal queries. Example: let's say we want to get the document named D in the S space. Do we offer a Wiki.getDocument(Space space, String docname) API? Or do we say the user has to traverse the object hierarchy: Wiki.getSpace (space).getDocument(docname)? (the latter is my preference). We may need some transversal APIs though but I think these should go in some other component (not sure though).
space.getDocumentsNames() loads the list of documents, or just retrieves the names?
Ah that's another API for getting documents which I haven't listed above... :) I think we should only have one API: Space.getDocuments (DocumentFilter filter). However this will NOT load the metadata of documents. These will be only loaded when Document.getMetadata() is called. Thus retrieving documents or just their names will be about the same in execution time (it'll only load data in one table). WDYT? Are there cases where this is not true?
Regarding the latter issue, we should try to make the components as stable as possible. After we all agree on a component, we need strong reasons to introduce something new.
Agreed. I'd like to use something like Clirr later on to ensure the build fails (see http://blogs.codehaus.org/people/vmassol/archives/ 001324_ensuring_binary_compatibility.html) In any case we need a consensus that changing something in the Model requires a vote.
Another issue, as far as I remember, components should be interfaces. Will the model be an interface, too, with a default implementation? Or will it not be a component?
They shouldn't be components as we need to be able to do new on them and pass them around in method calls, etc.
* I think it would be a good idea to have our model defined independently of the language (for example in XML - Here's for example the Maven model defined in xml: http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/ src/main/mdo/maven.mdo
+1 on that, as I'm a total adept of XML. But, what language should we use for the definition? I'd go for XSD, as I know nothing about Modello.
It's just a build time tool to easily generate stuff. It's pretty powerful, has lots of cool features, integrates supra well with Maven. XSLT transformation is a major PITA and I wouldn't want us to touch that as much as possible ;) Modello can use velocity templates for the generation, java code, etc. [snip] Thanks -Vincent
Hi Vincent, hi all, I tried to explain below which advantages I see in reusing JCR concepts as much as possible. Vincent Massol wrote:
ok I'll try to summarize my current thinking after all the exchanged emails:
* I don't think we should model our Model classes using a similar API as the JCR one. I much prefer we have an expressive Model with a strongly typed API, with objects like Document, Space, MetaData, Farm, Wiki, etc. Stephane, I keep turning this in my head and I can't figure a good reason to have a JRC like API for our model. Maybe you're seeing something that I don't see? Ludovic also said "[...] quite a few benefits to have our objects comply with the JCR model". I don't see them so maybe someone could enlighten me.
I agree we need in any case an expressive model that will capture the specific features of XWiki. However, since a significant part of XWiki features are already quite well expressed by the JCR API, we could take into account the well thought and well accepted JCR content manipulation concepts and APIs such as Node, NodeDefinition, NodeType, Property, PropertyDefinition, PropertyType, Workspace, Session, for adopting the following methodology: we could consider the current version of the JCR as a set of services to be supplemented with services that we're missing for building XWiki features, introducing specific concepts only when necessary. In that sense, I agree with Luis for saying that the JCR is a possible "metamodel" for our specific XWiki model. As Ludovic also pointed out earlier in this thread, we should not reduce the JCR to a storage API, since it is is a general API for representing operations on content, and is, as such, an API that models well part of our application behaviour. Note about Session: Session is not part of the data model indeed, but I think it's a handy class to be present at the model level, avoiding to pass the context to each method of the data model classes, as opposed to the current XWiki API. However, the JCR has drawbacks as well, and it is obviously missing important features needed for XWiki: - the JCR is too monolithic: all the services live in the same API, and new services cannot easily be added. Moreover, the API provides several identical functionalities from different places (redundant API example: a node can be moved from different classes: Session and Workspace). - the JCR is lacking a service for advanced management of properties: for instance, it's not possible with the JCR API to get all the back-references to a Node. - the JCR is obviously missing other services that we need for XWiki. Following a discussion with Mikhail, my proposal would be the following: Step 1: we split the JCR into the following services(to be possibly submitted as a JCR evolution proposal later on): - StorageService for atomic types including binaries - ContentMonitoringService - LockService - IndexingService - RepositoryAccessControlService - QueryService - XMLExportService - VersioningService - TransactionService - TypedPropertyService - DirectReferenceService - [...] probably others Step 2: implement those services using an existing JCR implementation, and also possibly using our own implementation, reusing the XWikiHibernateStore and the surrounding classes. Step 3: supplement these content services with the property management services we're missing for dealing with our XClass functionalities, but not introducing any specific XWiki concept at this stage. The advantage of having those services as extensions to the JCR instead of having them at the XWiki level is that the services would remain as generic as possible while providing easy interoperability with the JCR. Complementing the JCR with services providing advanced management of node properties is a topic that is currently of high interest to several communities. Participating in that effort may lead to a sound and standard API, implemented by several vendors, XWiki among others, and may make our community a strategic one among the emerging semantic web content repository initiatives. The needs for these supplementary services are well captured by the idea of a "Semantic Web Content Repository" in the slides below by Max Völkel [1],[2] and are mentioned in a recent email to the jackrabbit-dev list [3]. [1] http://swecr.googlecode.com/files/2007-03-12-SWECR-2.pdf [2] SWECR project: http://code.google.com/p/swecr/ [3] http://www.mail-archive.com/[email protected]/msg05524.html The services we're speaking about are typically the following: - ReferenceService (for manipulating object properties) - SparqlService (if we go for RDF for representing our classes and instances) - IdentityService (ID/URI mapping) - InferenceService They should in particular cover the use cases described by Sergiu in a previous post, which are of great relevance indeed [4]. Cognium Systems has expressed interest for co-developing such services with us, in an Apache License-like. [4] http://www.nabble.com/Re%3A--ArchitectureV2--Model-proposal-p10865097.html). Step 4: specify the specific XWiki services for dealing with structured and unstructured data as complementary services to the SWECR, and design an expressive model describing XWiki specific artifacts on top of the SWECR. Step 5: implement these services on top of an SWCR implementation Step 6: design and implement the other XWiki services (i.e. all those that do not directly relate to content manipulation). As a summary, here are two schematic stacks of models and services for comparing the two approaches we're discussing, as I understand them. Approach 1 stack ================ XWiki services --------------------------- XWiki type model: XClass, XProperty --------------------------- XWiki document model: Document, Space, Attachment, Wiki, Farm --------------------------- XWiki persistence service: Data Access Objects --------------------------- JCR impl.|Relational impl.|... Advantages: - we can quite easily implement several storages (JCR, relational storage) using Data Access Objects - the model is quite close to the existing one - we don't modify the JCR Cons: - the management of types and properties is not generic - people used to the JCR concepts have a complete new model to learn, without clear correspondance between XWiki concepts and JCR concepts - we have no obvious reason to participate in content management standardization efforts Approach 2 stack ================ XWiki services -------------------------- XWiki document model --------------------------- SWCR services: - Type/Property services - JCR services splitted into serveral ones ---------------------------- JCR document model, JCR type model --------------------------- JCR impl.|Relational storage impl|... Pros: - genericity of the property/types services - we embrace the JCR movement, and take part in its evolution - we take part in the emerging area of semantic web content repositories and the design of standard Semantic Web APIs complementing the JCR Cons: - larger effort - probably harder to implement a compatibility layer with XWiki 1.0 API - bigger performance risks Stéphane
* Our model classes should call the storage interface for any methods requiring storage access (for example: Space.getDocuments()). If other services are required they should be called out too. We still need to define a rule for when a new method can be added to the model classes and when a new component should rather be created. I have some ideas but I'm not 100% sure here so I'd like to hear what you think.
* I think it would be a good idea to have our model defined independently of the language (for example in XML - Here's for example the Maven model defined in xml: http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/src/main/...
The reason is that this will allow us to generate lots of things from this model: - Java bindings - XSD - Documentation - Any other language bindings - etc
We could use Modello for doing this. It's well integrated into Maven2 and is easy to use.
* I don't think we should use JPOX. Jason, whom I trust, says it's been a bad decision for Continuum (they use jpox) and that there are only 2 active developers for jpox which makes bugs take time to fix, etc. In addition, I'm not sure what this would buy us as I think we should have storage interface and a JCR implementation of it that would map to whatever underlying store is configured. Not sure where we would fit JPOX in there.
WDYT?
Thanks -Vincent
On May 28, 2007, at 9:38 AM, Vincent Massol 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 - (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -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
-- Stéphane Laurière [email protected] XWiki Research http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org
participants (6)
-
Catalin Hritcu -
Ludovic Dubost -
Luis Arias -
Sergiu Dumitriu -
Stéphane Laurière -
Vincent Massol