5 Jun
2007
5 Jun
'07
8:40 p.m.
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 <sergiu.dumitriu(a)gmail.com> wrote:
On 6/4/07, Vincent Massol <vincent(a)massol.net>
wrote:
--
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.
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