Re: [ArchitectureV2] Model proposal

Some more details on this topic: * We should have a consistent naming. Either we use XObjects/XClass and then we have to use X in front of everything: XFarm, XWiki (funny), XSpace, XDocument, etc or we agree that the namespace is enough (org.xwiki.model) to indicate that these are all XWiki classes and we drop the X. This is my preference. When we write documentation we can refer to XObjects/XClass/ to separate them from Java Objects/ Class though. * Here's a cardinality and dependency graph of main model classes: (Farm) 1 --> * (Wiki) 1 --> * (Space) 1 --> * (Document) 1 --> * (Object) 1 --> * (Property) * I want to come back on something I said in the email below. I said the Model classes shouldn't depend on any other component. I don't think this is true anymore. The reason is that I think we need to model the cardinality defined above in the model classes. For example: Farm: - addWiki(Wiki wiki) - removeWiki(String wikiName) - List getWikis() - Wiki getWiki(String wikiName) Wiki: - addSpace(Space space) - removeSpace(String spaceName) - List getSpaces() - Space getSpace(String spaceName) - Farm getFarm() Space: - addDocument(Document document) - removeDocument(String documentName) - List getDocuments() - Document getDocument(String documentName) - Wiki getWiki() The same applies to Document and Object. Now the interesting part is what happens for example when Space.getDocuments() is called? The user will expect that it returns the lists of documents in the space. This requires access to the storage component. Thus I now believe we should have the model classes have the storage component injected. The alternative is either to not have the above-defined methods in the model classes (which I think would be a pity) or have some external services to load the data in the model objects. But that's tricky because it would mean loading the whole object graph at once or doing some tricky transparent lazy loading. Thus my preference goes to adding a dependency to the storage component in the model classes. * Now we'll want to cache data instead of hitting the database every time. We could do this in several ways: using the database cache, using a delegating caching storage implementation or doing the caching in the model classes themselves using a caching service. I'm not sure here but a delegation at the level of the storage component sounds nicer to me at first glance. WDYT? Thanks -Vincent On May 28, 2007, at 9:38 AM, Vincent Massol wrote: