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