I know that it is not perfect, but the user is aware of its existence.
Otherwise, if you add a mixin than the user may have big problems:

1/ convincing the admin to add the new type def
2/ change the migration tools to support this mixin

The latest problem is quite serious, because currently the migration
tools are mostly inhouse tools, and you wouldn't like to have to
change it just to allow you to work with a lightweight mapping tool
like graffito.

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


On 5/23/06, Christophe Lombart <[EMAIL PROTECTED]> wrote:
Alex,

This solution is completly transparent for the developer :
1/ no specific field is required in the pojo which is excellent in point of
view object model.
2/ the mixin node type "graffito:discriminator" is added at runtime in the
target node. The Developer doesn't know this existence of this mixin type.

It only requires repository setting (add the mixin node type
graffito:discriminator) but I'm agree it is not the perfect solution.
I think the "discriminator field" is not also perfect. I don't like the idea
to add a technical attribute in the pojo.

Let me think about it !


On 5/22/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
>
> Hi Chris!
>
> I just noticed this comment and I am not 100% I like the solution for
> the discriminator mixin which seems obtrusive. It is like requiring a
> class to implement a special interface just to make it work with
> graffito and this is not good. The user must have the freedom to
> define his nodetypes and create no dependencies upon graffito and for
> this small thing it is really easy to configure hust a field name to
> make it work.
>
> br,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>
>
> On 5/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: clombart
> > Date: Sat May 13 08:07:23 2006
> > New Revision: 406117
> >
> > URL: http://svn.apache.org/viewcvs?rev=406117&view=rev
> > Log:
> > Add several modifications :
> >
> > * jcrNodeType is not mandatory.If not present the default value is
> "nt:unstructured".
> > * discriminator field descriptor was removed. Only the flag
> discriminator is defined on the class descriptor.
> >         If this flag is true, a mixin node type "graffito:discriminator"
> is added to the node.
> >         This type contains one property to store the java classname
> (graffito:classname).
> >     With this implementation, the discriminator field is not necessary.
> So, the persistence mechanism is still transparent for the jaba beans.
> >
> > * Interface support : like the inheritance support, there are 2
> differents strategies : node type per concrete class or per complete
> hierarchy. The hierarchy strategy requires a discriminator node type.
> >
> > Added:
> >
> 
incubator/graffito/trunk/jcr/jcr-mapping/src/test/org/apache/portals/graffito/jcr/testmodel/interfaces/
> >
> >
>



--
Best regards,

Christophe


Reply via email to