Great - thanks a lot.
Stefan Guggisberg wrote:
On 9/5/05, lists <[EMAIL PROTECTED]> wrote:
Thanks Stefan,
I'd actually snipped out the supertypes, so that's all working fine.
Will recompile the latest source and see if it makes a difference. Were
you suggesting that I also need to change my child node definitions?
your first example will not validate anymore because those child node
definitions were ambiguous. by additionally specifying different required
types in those child node definitions you actually removed the ambiguity,
i.e. they're fine now.
cheers
stefan
Digby
Stefan Guggisberg wrote:
On 9/1/05, lists <[EMAIL PROTECTED]> wrote:
Hi,
I'm just wondering if I've found a bug with the above method, or if I
just don't understand the way it should work.
I have the following content type defined (stripped down a little):
<nodeType name="article" isMixin="false"
hasOrderableChildNodes="true" primaryItemName="">
<childNodeDefinition name="*" defaultPrimaryType="paragraph"
autoCreated="false" mandatory="false" onParentVersion="COPY"
protected="false" sameNameSiblings="true" />
<childNodeDefinition name="*" defaultPrimaryType="attachment"
autoCreated="false" mandatory="false" onParentVersion="COPY"
protected="false" sameNameSiblings="true" />
</nodeType>
When i run the following code (where nt is the article NodeType):
NodeDefinition[] defs = (NodeDefinition[]) nt.getChildNodeDefinitions();
for (int i=0; i<defs.length; i++) {
System.out.println(defs[i].getDefaultPrimaryType().getName());
}
I get:
attachment
attachment
rather than:
paragraph
attachment
Is this expected?
nope, that's a bug, or more precisely: a side effect of a bug in the
node type validation
code. your node type contains ambiguous child node definitions, i.e. your
node type definition is not valid.
i fixed this issue in rev. 267220.
btw: your definitions are missing the supertypes declaration, but
that's another issue.
cheers
stefan
Many thanks in advance,
Digby
