jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <s.boe...@inovex.de>
Subject Re: Getting "custom" objects from the repository?
Date Mon, 18 Apr 2005 13:50:40 GMT
Hi Stefan,

 > check out 
sorry, but I don't see in this article, how registering of nodetypes 
will later be accessable. Can you please clearify what I'am miss here?



Stefan Guggisberg wrote:
> hi sandro,
> On 4/18/05, Sandro Böhme <s.boehme@inovex.de> wrote:
>>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.
>>Ben Pickering wrote:
>>>[fwding as I think I missed jackrabbit-dev with this]
>>>>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.

View raw message