hi sandro, On 4/18/05, Sandro B�hme <[EMAIL PROTECTED]> 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 cheers stefan > > 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 > > > > > >
