incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (GRFT-111) Extend Bean/Collection/FieldDescriptor with support for node type management tools
Date Thu, 19 Oct 2006 06:04:36 GMT
    [ 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

        

Mime
View raw message