incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <>
Subject Re: [jira] Created: (GRFT-37) Final JCR Mapping Document PROPOSAL // mapping structure
Date Sun, 28 Aug 2005 21:21:47 GMT
Sandro Böhme wrote:

> explained in the proposal doc, we need to map simple fieds, bean
>> fields and collection. So, we need to use different tags for that.
> Where do you see the difference between field and a bean-field?
There are 4 "types" for attributes/fields :
* Simple fields : primitive data types and simple objects (String, Long, 
Double, ...)
* Bean fields : One class can contain an 1..1 association to another 
bean. In this case, the attribute is a custom object.
* Collection fields : One class can contain an 1..n association to a 
collection of beans (or Map). The m..n association will be also supported.
* Reference field : One good example to understand the "reference" type 
is the Folder concept. A folder "B" can have an attribute called 
"parentFolder" which is a simple field pointing to the parent folder "A" 
. Of course, in a JCR repository, it is a nonsense for persist this 
"parentFolder" attribute into a "B" subnode.</Quote>

We could add a "type" attribute to the field-descriptor or the sub-tag 
(<java-method/>) of it. It can contain not
only primitive types but also custom java classes that have a mapping 
defined in the mapping file. This already
works in my prototype  (The "Folder" has a "Document").

With the interface of the AtomicTypeConverter the user should be able to 
define a custom mapping for
java classes that use bean property types not supported by the JCR.
I used it to define a custom (build in) mapping for java.util.Date 
because the JCR only knows "Calendar".
This way the custom java classes can reuse the date type as their bean 
types and the custom converter
knows how to convert the data. The converters are registered in the 
factory. As soon as the object to
item component or the item to object component hit a registered class 
which is to be persisted it will
use the registered custom converter to do the real conversion.

That's the java.util.Date example:
    private AtomicTypeConverter utilDateTypeConverter = new 
        public String getPropertyType(){
            return PropertyType.TYPENAME_DATE;
        public Value getJcrValueFromJavaObject(Object propValue){
            if (propValue==null) return null;
            Calendar calendar = Calendar.getInstance();
            return this.getValueFactory().createValue(calendar);

        public Object getJavaObjectFromJcr(Node node, String 
jcrPropName) throws ValueFormatException, PathNotFoundException, 
            Calendar calendar =  node.getProperty(jcrPropName).getDate();
            Date date = calendar.getTime();
            return date;
        public Class[] getJavaTypes() {
            Class[] javaTypes ={java.util.Date.class};
            return javaTypes;



View raw message