incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <the.mindstorm.mailingl...@gmail.com>
Subject Re: mapping descriptor revisited
Date Wed, 08 Feb 2006 11:18:52 GMT
Hi!

All the features considered in this mail were implemented, (tested) and are in the SVN head.

Later this week, I will look into collection-descriptors and interface/inheritance. For the
moment, 
I cannot promise anything, but I really hope to find a  couple of hours to do it.

cheers,

./alex
--
.w( the_mindstorm )p.

#: Alexandru Popescu changed the world a bit at a time by saying (astral date: 2/5/2006 10:32
PM) :#
> Hi!
> 
> I finally had the time to revisit the mapping descriptor for class-descriptor, field-descriptor
and 
> bean-descriptor. So far here are my conclusions:
> 
> A] class-descriptor
> 
> i/ jcrSuperTypes: doesn't seem to make sense to be used, cause we are not gonna create
custom node 
> definitions. These are already defined within the repository and the information is contained
in the 
> description of the jcrNodeType.
> 
> ii/ there is no way to declare that the node to be created has mixins. I would like to
add a 
> jcrMixinTypes that specifies a comma separated list of mixins for the node to be created.
> 
> Adding mixins to a node at runtime is an allowed operation and I have good examples where
this would 
> make sense.
> 
> iii/ there is no way to declare a custom converter. Currently a class-descriptor is 
> persisted/fetched by the ObjectConverterImpl. But considering the following suggestions
(see 
> bean-descriptor) it would make sense to allow specifying a custom converter.
> 
> iv/ Currently there is not possible to provide multiple mappings for the same class.
This may sound 
> weird in the first place, but I think there are scenarios where this would make sense.
However, I 
> don't consider this a high priority.
> 
> B] field-descriptor
> 
> The following attributes used inside the mapping:
> 
> jcrAutoCreated (true | false) "false"
> jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) "COPY"
> jcrMandatory (true | false) "false"
> 
> are duplicating the definition of a node type and cannot really be used (they are just
informal). I 
> would suggest removing them.
> 
> C] bean-descriptor
> 
> The current bean-descriptor is able to handle only the scenario where the properties
of the bean are 
> persisted on a direct subnode of the current node. As I pointed in a separate thread
and Christophe 
> marked in the http://issues.apache.org/jira/browse/GRFT-54, the bean-descriptor should
be able to 
> handle at least 3 scenarios:
> 
> a/ persisting the properties of the bean on the current node (a component bean)
> b/ persisting the properties of the bean on a direct subnode of the current node (the
current behavior)
> c/ persisting the properties of the bean on subtree structure of the current node or
an independent 
> node in the repository (consider GRFT-54 for the first part and a referenceable node
for the 2nd part).
> 
> The modifications needed for this to work are quite simple:
> 
> a/ add a inline attribute with true/false values: if set to true, the bean properties
are created as 
> properties of the current node
> 
> b/ add a converter attribute with a fully qualified name of a converter class, that will
be 
> responsible for persisting/fetching the node. The API for this converter is a reduced
version of the 
> current ObjectConverter interface. If not specified the converter to be used is the 
> ObjectConverterImpl (the current implementation).
> 
> 
> I would also like to remove the following attributes from the mapping. They are duplicating
a node 
> type definition and cannot be directly used:
> 
> jcrAutoCreated (true | false) "false"
> jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) "COPY"
> jcrSameNameSiblings (true | false) "false"
> 
> 
> As pointed previously, there are a few more things we need to define: review collection-descriptor,

> define behavior for interface/inheritance (for queries, and persistence too).
> 
> However, once agreeing on the above points will allow me to implement the changes right
away. Than 
> we can continue with the rest.
> 
> I would like to start doing the above changes right away, so I am eager to hear your
opinions and 
> comments as soon as possible. Than we will have a new face of the OCM :-). Thanks in
advance,
> 
> ./alex
> --
> .w( the_mindstorm )p.
> 
> 


Mime
View raw message