[xwiki-dev] [ArchitectureV2] Model proposal

[Sergiu Dumitriu]

On 5/29/07, Vincent Massol <vincent at massol.net> 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 <vincent at massol.net> wrote:
> >>> Hi,
> >>> Starting from today I'm going to spend some time every week on the
> >>>  V2 Architecture/Redesign. Today I'd like to start at the heart of
> >>>  the topic with the domain model. Here's my proposal:
> >>> * Model classes are classes representing the XWiki model. The
> >>> main classes are: - Farm - Wiki - Space - Document - XObject -
> >>> XClass
> >> Attachment
> >
> >
> > Couldn't we try to merge the Document, XObject and Attachment classes
> > into a single class, along the lines of the JCR API where there is
> > mainly a Node class that can have various types and various
> > properties?
> > An Attachment would be represented by a Node with a property
> > containing
> > a binary stream and possibly other properties such as the text
> > description, the title etc. The advantage of this approach is to
> > offer a simplified and more flexible model.
>
> [snip]
>
> That's an interesting idea. However for me the relationship with JCR
> is not an advantage and certainly not a requirement. We want our
> model classes to be independent on any storage mechanism. However
> from a design perspective it's interesting to evaluate how the model
> classes could look like if they were using a Node API similar in
> design to the JCR (which I don't know so well but I guess it's
> similar to the DOM API too).
>
> I can see some pros and cons:
>
> Pros:
> - flexibility in that it's easy to add a new node type
> - genericity in that it's a hierarchical structure (a graph) and it
> would support nested nodes
>
> Cons:
> - less strongly typed API in general a more generic API vs a more
> business oriented API with the API I proposed. Compare
> Space.getDocuments() to node.getElementsByType(NodeType.DOCUMENT). Of
> course I guess we could add a SpaceNode class that implements the
> Node interface and that method could then have a getDocuments() API
> which internally would be implemented as getElementsByType
> (NodeType.DOCUMENT). There's still the problem of doing "if"s on the
> node type to cast to the correct specific node class. Personally I've
> always found the DOM API to be a real pain (which is probably why
> there are frameworks like JDOM, DOM4J, etc).
> - There are business APIs to implement too (not just navigating) and
> these APIs don't make much sense applied to a Node. They do make
> sense applied to business objects.
>
> We need to discuss this more and I need to think more about this too
> to evaluate the consequences.
>
> Thanks for this interesting discussion Stephane
> -Vincent
>
>
>

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