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 Sun, 05 Feb 2006 22:21:44 GMT
Hi Alex,

Here my comments :

On 2/5/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:


> 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.
>

Oliver needs this information to create the JCR node types from our
mapping files (see the subproject jcr-nodemanagement).  This is not a
mandatory attribute.

> 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.

Please can you give me an example - thanks !
>
> 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.
>

Excellent ! +1 of course. The same can apply on the simple field-descriptors.

> 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.
>

I'm just curious to know the scenarios you are thinking about :-)

> 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.
>

Oliver needs this information to create the JCR node types from our
mapping files (see the subproject jcr-nodemanagement).  They are not
mandatory attributes.

> 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
>

Cool !

> 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).
>
>

If I understand, you will create new ObjectConverter implementations
(one for each scenarios b (already exist), c.1 (GRFT-54) and c.2
(reference).
If yes, is it possible to create a generic ObjectConverter
implementations that support GRFT-54 ?

> 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"
>
>

Oliver needs this information to create the JCR node types from our
mapping files (see the subproject jcr-nodemanagement).  There are not
mandatory attributes.

> As pointed previously, there are a few more things we need to define: review collection-descriptor,

I'm also curious to know more on that.

> define behavior for interface/inheritance (for queries, and persistence too).
>

Yes. those points are very important. Personnally, I don't see an
interest to persist interface & ancestor. +1 for queries

> 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,

Thanks  for this nice work.

--
Best regards,

Christophe

Mime
View raw message