jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Douglass" <douglass.d...@gmail.com>
Subject Re: node type definitions and mixin overrides
Date Fri, 16 Jun 2006 18:05:35 GMT
Thanks for the reply Stefan.

I finally got a unit test up and going and got the results you describe --
jackrabbit doesn't support/allowing it:

javax.jcr.nodetype.ConstraintViolationException: The property definition for

   '{http://www.foo.com/compass/content/1.0}operatingSystem' in node type
   with node type '{http://www.foo.com/compass/content/1.0}productImage':
   ambiguous property definition at

This isn't a show-stopper for us, but it does beg the question of whether we
should be using Decorators to enforce business rules within of domain model?
I could just as easily make an argument for using different Strategies to
enforce these rules as the Decorators aren't really adding any new behavior,
just enforcing required properties. Either way, the domain model will have
to enforce these rules since we can't push them down into the the JCR


On 6/16/06, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> On 6/15/06, Doug Douglass <douglass.doug@gmail.com> wrote:
> > More of a JCR question than Jackrabbit: Can a mixin add the mandatory
> > attribute to a property defined in the primary node type?
> the semantics of node type inheritance are not clearly specified by
> jsr-170,
> i.e. there's no concept of overriding definitions in the spec.
> this has been discussed in the jsr-283 expert group. the semantics will be
> clarified in a maintenance relsease of the spec.
> jackrabbit currently doesn't support overriding of child node/property
> definitions.
> cheers
> stefan
> >
> > The Jackrabbit CompactNodeTypeDefReader class seems to allow this, but
> does
> > it really validate the CND? I haven't yet attempted to load the CNDs
> into
> > the registry.
> >
> > Our use case is a set of images depicting product data: all possible
> product
> > metadata will be declared as properties by the primary node type (e.g.,
> > ns:productImage), we'd like to use mixins to require values for specific
> > properties. This matches our domain model where we use the decorator
> pattern
> > to allow product images to dynamically transition between different
> image
> > "types" (e.g., a close-up image vs. room vs. outdoor, etc).
> >
> > TIA,
> > Doug
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message