jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "hsp" <piccina...@ibest.com.br>
Subject Re: About child Nodes
Date Thu, 20 Apr 2006 18:44:48 GMT
>Hi Helio,
>On 4/20/06, hsp 	 wrote:
>> >your 'esc:categ' is defined as mixin nodetype. do you mix-it in to
>> >something? or do you use it as a primary nodetype?
>> The nodes with this type will be under nt:folder nodes or some other kind that is
its child.
>> Under a node 'esc:categ' must be only another(s) node 'esc:categ'.
>> I defined it as mixin because I thought this way when the esc:categ is created, it
also will
>> have the property defined for nt:folder types like 'jcr:primaryType' and 'jcr:created',
>> because 'nt:folder' is its supertype.
>All esc:categ nodes will have those properties anyway, simply because
>nt:folder is declared as a supertype of esc:categ. Judging from your
>description I think you should not define esc:categ as a mixin. I
>think what you want is a primary type: then you can assign it on node
>creation with addNode("mynode","esc:categ").
Ok, really it is what I want to do now, thanks. By the way, I almost know all about mixin
types, I think this kind is for extend some primary type, but it is not what the declaration
supertype does?? What is the difference between two same node types  where in one "isMixin=true"
and  in another "isMixin=false" ?

>Also notice that if you want esc:categ nodes to only allow esc:categ
>children, then you should not make nt:folder a supertype of esc:categ.
>As it is, esc:categ inherits the child node defs of nt:folder, which
>allows any child nodes of type nt:hierarchy...so this means that
>esc:categ nodes can have child nodes of type esc:categ AND child nodes
>of type nt:hierarchy.
Ok, now its more clear for me, thanks.

>> >furthermore, the nt:folder supertype already defined a childnode
>> >definition for 'nt:hierarchyNode'. so you at least can add those.
>> >
>> >how do you create your property?
>> >
>> I thought that declaring properties inside the nodetype declaration would register
>> like that nodetype properties. Is not this way?
>Yes this is correct. You declare the property in the node type, and
>then you make a node of that type and then you do a setProperty on
>that node with a property name and value type that matches the one you
>defined in the node type.

I've notice this is happen with the propertie of "requiredType=Reference". I can't assign
a value to this propertie this way: Node.setPropertie(prop:Reference,"uuid")...The others
are ok to set.
Tks Peter

View raw message