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? 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?
> 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? BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
