Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <2053085293.1208509101596.JavaMail.jira@brutus>
Date: Fri, 18 Apr 2008 01:58:21 -0700 (PDT)
From: "angela (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1543) Improve reliability of canAddMixin
In-Reply-To: <1300018901.1208439801599.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590343#action_12590343 ] 

angela commented on JCR-1543:
-----------------------------

sounds reasonable to me.

comments to the patch:

QNodeTypeDefinitionImpl:
- i think having an additional constructor for QNodeTypeDefinitionImpl including the
  supported mixin types would be reasonable.
- the current available constructor would then pass 'null' and just forward the params.
i would prefer that over always returning null.

EffectiveNodeType:
- maybe i would prefer the new method to be name canAddMixin instead of supportsMixin... but
  that's just the first idea. no strong feelings.


> Improve reliability of canAddMixin
> ----------------------------------
>
>                 Key: JCR-1543
>                 URL: https://issues.apache.org/jira/browse/JCR-1543
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-spi
>            Reporter: Julian Reschke
>            Assignee: Julian Reschke
>            Priority: Minor
>         Attachments: JCR1543.diff
>
>
> The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
> This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
> Proposal: enhance QNodeTypeDefinition with
>   public Name[] getSupportedMixins();
> where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.