jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Getting "custom" objects from the repository?
Date Mon, 18 Apr 2005 13:42:08 GMT
hi sandro,

On 4/18/05, Sandro Böhme <s.boehme@inovex.de> wrote:
> Hello,
> sorry, but the "poor-man's object-repository-mapping" is already done by
> me ;-) with help of Oliver Kiessler and Christophe Lombart of the
> Graffito community (both not responsible for the poor part ;-) ).
> I submitted a proof of concept code as jira issue to the jcr-mapping
> subproject of Graffito but I would also like to work with the jackrabbit
> community. We just have to clearify where the code belongs to.
> Personally, I would like to head in a JDO and MDA-like direction to make
> the nodetype creation an easy task.
> It would be good to know how the registering of nodetypes will be
> accessable in jackrabbit in the future. By the api, by the
> custom_nodetypes.xml or both? Any hint is very much appreciated.

check out http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/702


> Just a quick edited copy and past from the Graffito mailing list:
> It's just an initial version with the following three usecases for the
> JCR Mapping:
> 1. Registering custom nodetypes according to a Java Bean model at
>     compile time.
> 2. Persist a Java Bean at runtime.
> 3. Loading a Java Bean from the repository at runtime.
> ==>1. For registering nodetypes I put the custom_nodetypes.xml in the
> nodetypes repository folder. Creating the xml file is realized with
> JAXB.  The BeanConverter class maps the Java class structure to the
> nodetype structure and marshalls the custom_nodetypes.xml to the
> configured nodetype folder. I did not check the schema
> against the spec yet, because it will change anyway.
> At the moment I work on a xdoclet module to replace the jaxb part.
> ==>2. Persisting simply works like that:
>      PersistenceManager pm = new PersistenceManager(jcrSession);
>      String relPath = pm.insert(folder);
> ==>3. Loading can be implemented this way:
>          Folder loadedFolder = (Folder) pm.getObject(relPath);
> All information for reading and writing a bean can be gained by the
> class itself. It does not need to implement an interface or something.
> The path acts like a unambiguous database id.
> ++ limitations ++
> o no complex property types can be saved (Folder.getDocument())
> at the moment
> o collections are not yet supported
> o deletion is not yet supported
> o only the basic JCR Types (String, boolean,...) and java.util.Date (not
> a JCR-basic type) are supported
> o the bean converter is not yet adapted to Graffito converter handling
> o mixin's (=Interfaces) are not yet supported
> ++ next steps ++
> o much more test cases need to be added and I'm sure according bug's
> need to be fixed  ;-)
> o also delete the data created in the test cases
> o pm.update and pm.delete() need to be added
> o more atomic types (like Character,...) need to be added
> o support for complex types
> o support for collections
> o support for interfaces
> o make the namespace "graffito" configurable
> o support for JCR features like searching, versioning,...
> o creating an Ant target for registering Java classes as nodetypes
> o refactor some responsibilties and names of some classes
> o support queries
> o ...
> ++ configuration ++
> I don't think it is ready for check in because the configuration is not
> very clean at the moment, it has not enough test cases,...
> Please tell me your opinions about all this. Thank you very much.
> Regards,
> Sandro
> Ben Pickering wrote:
> > [fwding as I think I missed jackrabbit-dev with this]
> >
> > David,
> >
> >
> >>i think mapping of content to pojo's is not something that should
> >>be covered in the jcr-spec at this point. much like the
> >>ejb (or jdo) and jdbc specs are separate for good reasons i
> >>believe this should be the same for jcr.
> >
> >
> > I agree 100% with you.  Perhaps I was misleading when I spoke about
> > 'standardising'.  I meant perhaps a related 'best practice' more than
> > anything formal.
> >
> >
> >>i think it could get very interesting assuming hierarchies of
> >>child nodes and inheritance of nodetypes.
> >>does that make sense? this could be the start of a
> >>poor-man's object-repository-mapping.
> >
> >
> > The basics are pretty clear, yes.  The idea of hierarchies of child
> > nodes is the interesting bit  and where I came in, really, with the
> > thread about importing XML text to node hierarchies.  I'm happy to be
> > a poor man if I don't have to write all that complex stuff Daniel
> > wants :)  I'm sure Day has it in the labs anyway, heh?
> >
> >
> >>no, i think this is all very reasonable, and i think that if something
> >>like the above is what you are looking for, then this should be
> >>implemented reasonably fast. would that be something that
> >>you are interested in working on?
> >
> >
> > Well, I only checked out jackrabbit the other day, but I do intend to
> > take a look when I have the time.  I guess it's all changed by now :)
> >
> > Glad I could finally be clear enough to explain what I was getting at.
> >
> > --
> > Cheers,
> > Ben
> >
> >

View raw message