incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject Re: mapping descriptor revisited
Date Wed, 08 Feb 2006 11:55:08 GMT
Cool !



On 2/8/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> 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.
> >
> >
>
>


--
Best regards,

Christophe

Mime
View raw message