On 7/15/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi, On 7/15/06, Christophe Lombart <[EMAIL PROTECTED]> wrote: > Ooops - I'm very sorry, the OCM unit tests are in : > /jcr/jcr-mapping/src/test (not in /components/src/test) No problem. At the moment I'm really more interested in how the Graffito portlet components use the persistence API than in the specifics of the way it is implemented by the OCM tool. Once I've understood the Graffito core model, I'll have a better grasp on how the OCM tool fits into the picture. I hope you'll have the patience to help me through this. :-) > > What is the "folder" instance in this case? Is it a plain data object > > or an adapter to an underlying folder concept? > > it points to a plain data object. A usual pojo with simple > getters/setters. Is this POJO class shared by the different persistence implementations (DB, JCR, etc.) or does each implementation have it's own POJO classes that implement the core model interfaces?
The same pojo can be persisted anywhere (DB, JCR, custom, ...). What I'm getting at here is that if the "folder" in the example is a
data object, why do we need the Folder interface? Wouldn't it make more sense to replace the Folder interface with a shared data object class?
Right ! The interfaces are not really useful until now.
> Can I implement my own Folder class and pass instances of it to the > > persistence layer? > > yes but you have to specify the interface "Folder" and the class "MyFolder" > it in the mapping file. OK. But if I write a Graffito portal component that relies on this, wouldn't the requirement to have a JCR-specific mapping file break the indepence from the underlying persistence model? How would I map that custom class to a DB storage?
The mapping file referenced in my previous mail is JCR specific. So, this JCR mapping file is not required for another persistence store type. The independence from the underlying persistence model is still there because we are managing simple pojo objects. The persistence service works with "Content Stores" (see org/apache/portals/graffito/store/ContentStore). A content store represents a specific content server running somewhere. There is one content store implemented with OJB to store content objects in a DB. A JCR store is not yet implemented. Of course, I would like to build the JCR store with our OCM tools. If needed, you can write your own content store. FYI, each time the persistence service wants to deal with a content object (update, insert, retrieve, ...), it redirects the request to the appropriate content store. The persistence layer is just there to group together different content servers and present them to portal components. So, the portal can access to heterogeneous content server I think I have to review the page : http://incubator.apache.org/graffito/architecture.html which is not very clear. Maybe sequence diagrams will be. There is also in my language a mix between store and server. Supporting different content types (eg. JCR & DB in the same running application) is not fully tested. I expected that some work has to be done. -- Best regards, Christophe
