Hi Alex, Here my comments :
On 2/5/06, Alexandru Popescu <[EMAIL PROTECTED]> 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
