---------- Forwarded message ---------- From: Asiri Rathnayake <[email protected]> Date: Mon, Mar 10, 2008 at 4:55 AM Subject: Re: [xwiki-devs] xwiki-sandbox/org.xwiki.model vs xwiki-sandbox/components/xwiki-model To: Vincent Massol <[email protected]> Cc: XWiki Developers <[email protected]> Hi Vincent, Following is a simple discussion of the two implementations of the new data-model of ArchitectureV2. Both of these implementations are not complete yet and my knowledge of xwiki is still limited. There for, there may be short-commings in the following discussion, please bare with me and try to correct me where i'm wrong (this will help me a lot). xwiki-sandbox/components/xwiki-model (Vincent) ----------------------------------------------------------------------- -> Represents a clear hierarchical view of domain objects (Server->Wiki->Space->Page) [ A simple graphical representation of the model is attached. ] -> Does not include any administrative / security / rights related code (simple model definitions). -> Currently upward navigation (given a page find it's parent space) is not possible. (but i believe this can be implemented at a higher layer) -> PropertyDefinition class is currently isolated, and no mention about Users. -> No mention about persistence related issues (DAOs). -> All are concrete classes Q.) Shouldn't we have interfaces (with a default impl) rather than classes here ? xwiki-sandbox/org.xwiki.model (Mikhail, Stéphane) ------------------------------------------------------------------------- -> The business layer (org.xwiki.model) contains model classes (Farm, Wiki, Space, Document, User) Along with (Session and XWikiException) Q.) Strictly speaking, Session and XWikiException are not domain classes. Shouldn't we try to keep things more simple in the model ? -> Here the notion of a hierarchy seems to be little blured, Farm doesn't have any method like getWikis() but it seems to contain some administrative / authentication related methods like createUser() and checkPassword() (This looks quite odd for me). And with this model it is possible to navigate upwards the hierarchy (Page->Space->Wiki). -> Some domain classes have code related to session handling / user rights. (is this ok?) -> In a sense, domain classes seems to be active rather than being passive (getters / setters). Example : space.addPage(Page page) <- passive, space.newPage(, , ,) <- active Example (imaginary) : space.getPages(SomeFilter) <- passive, space.getPages(...) {/* perform validations, access rights and return */} <- active -> There is a persistance layer (org.xwiki.model.dao). If we are to have two seperate plexus components for storage and data-model (or in other words, to decouple the model from storage), DAO classes should actually go inside the storage component. Having DAO classes inside the model will automatically bind the model to a particular storage implementation. -> org.xwiki.model.dao seems to have a single DAO interface (IWikiDAO) to access the storage rather than having separate DAO classes for each domain class. Q.) Why not have separate DAO classes for each model class ? Q.) org.xwiki.model.dao has *Value classes for each domain class. Why not use domain classes directly ? -> There is a default in-memory implementation of IWikiDAO inside org.xwiki.model.dao.memory I think that's all for the moment. Thanks. - Asiri On Sun, Mar 9, 2008 at 7:48 PM, Vincent Massol <[email protected]> wrote:

Hi Asiri,

On Mar 9, 2008, at 2:25 PM, Asiri Rathnayake wrote:

...

Hi Stéphane,

I think the new data model is commited at xwiki-sandbox/ org.xwiki.model. But i'm bit confused with xwiki-sandbox/components/ xwiki-model. What does the latter stand for ?

The one in org.xwiki.model was done by Stephane and the other one by me ;)

I guess they are two proposals for the same thing so we'll need to decide which one to use. Note that the one I have isn't finished either. We need to continue working on it, make proposals, etc. Maybe you could review both and send an email with the differences.

This is an area I'd like to work on actively too. I've just been busy with the 1.3 release but now it's done I'll try to spend more time on the v2 components. However for this to happen we need someone to work actively on fixing the important 1.3 bugs, releasing a 1.3.1 (for example to fix the login issue with tomcat/IE7) and taking the lead on 1.4.

Anyone interested in doing this or simply helping out?

Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs