[ 
http://issues.apache.org/jira/browse/GRFT-111?page=comments#action_12443418 ] 
            
Felix Meschberger commented on GRFT-111:
----------------------------------------

Thanks for applying the patches to the mapping project. In fact it is not my 
intention for my NodeTypeManagerImpl class to be injected into the node type 
management project. I merely attached it to illustrate, how I use the new 
functionality in my own implementation. Also my implementation internally works 
different, than the graffito node type management approach, so it is not 
applicable anyway as such.

Concluding from your remarks, I will provide a patch to the existing 
(jackrabbit based) NodeTypeManagerImpl class which leverages the new 
functionality.

> Extend Bean/Collection/FieldDescriptor with support for node type management 
> tools
> ----------------------------------------------------------------------------------
>
>                 Key: GRFT-111
>                 URL: http://issues.apache.org/jira/browse/GRFT-111
>             Project: Graffito
>          Issue Type: Improvement
>            Reporter: Felix Meschberger
>         Assigned To: Christophe Lombart
>         Attachments: GRFT-111.zip, NodeTypeManagerImpl.java
>
>
> I started working with Graffito JCR-Mapping some weeks ago noticing that it 
> actually implements what I planned to implement in my own tool - and more :-) 
> So I started to like that thing. While working on it I thought, that it would 
> be nice to define node types based on the mapping definitions and also 
> noticed, that this is actually also supported by the mapping descriptors.
> Still, the support by the descriptors has some drawbacks: Field descriptors 
> are thought to only map to properties, while collection and bean descriptors 
> are thought to only map to child nodes. Consequently the field descriptors 
> support attributes for property definition while bean and collection 
> definitions support attributes for child node definition. While this 
> assumption is mostly true, it fails in the case of multi-valued properties, 
> which is implemented using a collection descriptor. I myself implemented 
> another CollectionConverter, which supports residual jcrName values. Also in 
> this case, the collection descriptor maps properties.
> Hence I proopse to extend the bean and collection descriptors with attributes 
> for property definition. Namely I propose the addition of "jcrType" and 
> "jcrMultiple" attributes which should contain the property type and 
> multi-value flag respectively. The respective BeanDescriptor and 
> CollectionDescriptor classes are to be extended for these attributes.
> To further simplify node type management tools, I further propose, to define 
> two interfaces - PropertyDefDescriptor and ChildNodeDefDescriptor - which may 
> be used by node type management tools to extract the relevant information to 
> define properties and child nodes. The FieldDescriptor will only implement 
> the PropertyDefDescriptor while the BeanDescriptor and CollectionDescriptor 
> classes will implement both interfaces. The node type management tool will 
> then have to apply heuristics to decide, whether a property or a child node 
> should be defined.
> Attached you will find the patchs to the FieldDescriptor, BeanDescriptor and 
> CollectionDescriptor classes as well as the proposed interfaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to