[
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.
