---------- Forwarded message ---------- From: Asiri Rathnayake &lt;asiri.rathnayake(a)gmail.com&gt; 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 &lt;vincent(a)massol.net&gt; Cc: XWiki Developers &lt;devs(a)xwiki.org&gt; 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 &lt;vincent(a)massol.net&gt; wrote: