On Mon, Apr 4, 2011 at 3:24 PM, Alexander Klimetschek <[email protected]> wrote: > On 04.04.11 15:16, "Markus Joschko" <[email protected]> wrote: >>When the name is the id I would have expected jcr to check against the >>definition, notice that the more specific defintion >>of the property does not match the input and throw an error. >> >>Otherwise nt:unstructured is kind of dangerous as it silently swallows >>everything thrown at it. > > The idea is that once you introduce a residual property or child node > definition, you make it "unstructured", including descendant node types. > > IIUC the JCR node typing is in general not allowing to put on more > constraints on a sub node type - which is in line with how OO in most > languages work. Otherwise finding e.g. all "nt:unstructured" nodes in the > repo, but then not being allowed to change properties freely, because some > of the nodes are of a sub-type with more restrictions, would defeat the > purpose of the inheritance model. >
That theoretically means, that a node inheriting from nt:unstructure shouldn't have any properties because it will always override the catch all of nt:unstructure. How is validation handled? If my subnode defines a simple string property but limits what can be entered. Is validation ignored when getting an instance as nt:unstructured or is the illusion destroyed? > Regards, > Alex > > -- > Alexander Klimetschek > Developer // Adobe (Day) // Berlin - Basel > > > > >
