On Tue, Feb 28, 2012 at 3:19 PM, Michael Dürig <[email protected]> wrote: > > > On 28.2.12 13:17, Alexander Klimetschek wrote: >> >> Am 23.02.2012 um 12:33 schrieb Michael Dürig: >>> >>> Having node.type.management.orderable.child.nodes.supported = false >>> might be a bit harsh. But orderable child node lists and large number of >>> child nodes are definitely in each other's way. I think we should come >>> up with a way to let users choose. >> >> >> Users can already chose: using the node type parameter "orderable". >> >> A repository-global decision to use either or does not really help, as in >> most cases you will have the need for both cases (huge unordered bunch + >> smaller ordered list). > > > That's right and I think this is the way to go. We should however make it > clear, that having orderable child nodes comes with a cost. > > A remaining issue is that currently nt:unstructured is orderable. So we > might want to factor orderable out into a mixin.
i have no idea how that would work. can you please give an example? we could add a new node type (e.g. nt:scalable), specified like nt:unstructered but with orderable=false. cheers stefan > > Michael >
