incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Graffito release plans?
Date Sat, 15 Jul 2006 10:55:19 GMT
Hi,

On 7/15/06, Christophe Lombart <christophe.lombart@gmail.com> 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/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message