30 May
2007
30 May
'07
1:55 a.m.
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 <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
- (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