I'd agree that using unstructured types can be useful for prototyping when the final structure is changing frequently. But I would be cautious about that approach for a production system. Unstructured node types can be a security hole since anyone with rights to modify properties on an unstructured node can add arbitrary garbage to your repository. Well defined node types provide a nice guard against that since unexpected child nodes and properties can not be added.
-Eric On Oct 12, 2012 7:46 AM, "Alexander Klimetschek" <[email protected]> wrote: > On 12.10.2012, at 09:27, Dimitar Dimitrov <[email protected]> wrote: > > > But from now I have a need of user defined types which then will be > > managed by filtering and transforming to other structures. Exactly for > > the filtering needs I should now the type primary type of the nodes. > > Then these nodes will be transformed to visual component in the Flex > > based interface. For that I need of object persistence also, but I have > > not implemented yet, because of asynchronous nature of the Sling CRUD. > > Use properties to "mark" your types, and using sling:resourceType for that > is usually the best way to go, as you get Sling's flexible rendering for > free. > > Properties can be updated, easily searched for, replaced over time with a > new way if it comes up, you can use additional properties for "sub types" > etc. > > You don't get any constraints this way, but encoding application/ui > constraints into the storage layer is usually not a good idea, as these > change over time. Hence it's best to put them in the application layer. > > HTH, > Alex > >
