Cool !
On 2/8/06, Alexandru Popescu <[EMAIL PROTECTED]> 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
