[xwiki-dev] [ArchitectureV2] Model proposal

Vincent Massol vincent at massol.net
Mon Jun 4 15:41:03 CEST 2007


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- 
> dev at objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe at objectweb.org
> For general help: mailto:sympa at objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/ 
> wws





More information about the devs mailing list