allow user defined node types ( priviledged users can define how a content type is structured )

[brunoreis]

implement a general concept that would enable users to define new node types (which maybe require other subnodes or extend existing node types etc). this ticket is related to http://github.com/symfony-cmf/symfony-cmf/issues#issue/18 but its not exactly the same as issue #18 talks about giving bundles the ability to construct content from nodes and this ticket talks about making it possible for users to define entirely new node types on their own.

• step 1 would be to define a developer friendly way to define new types
• step 1 would be to add a UI for end users to do so

[lapistano]

I think this is like pandoras box and should not be done in the first place. I propose to go with a predefined set of node types to start with and take a good eye on the implementation so it can be everything else some time for now. I think the hardest thing to do will be the handling of recursions (a content node may contain a content node may contain ...). This is afaik very hard to implement.

[dbu]

@lapistano: can you please clarify what you mean with this? so far we where not talking about recursive type definitions, just about structured content. for example to attach different types of things to nodes. or somebody might want a title, a teaser, a body, a sitemap short description, whatever... i do see the need for some flexibility here.

[lapistano]

@dbu: 'this' = recursive structures
Sure we are ot talking about recurrencing structures... yet. But as we all know there will be a demand for this if we implement those flat structured, basic node types. And we should be aware of the complexity of those special (= recurrencing) node types to be able to implement them without refactoring the complete functioallity. All I am saying is be aware of future changes.

[lsmith77]

@dbu: well i think what lapistano is concerned about arbitrarily deep nesting. the alternative would be to just allow the use of defined node structures. aka "blog" node may consist of any number of image subnodes etc. but i think this a bit too tight a coupling between content and app logic reading the content. but overall the main thing is to find ways to encourage users to maintain a sensible node structure that remains manageable.

[lsmith77]

i should add that in some cases the best solution is not to create a deep structure (of references) and instead use a special node type "search query". aka when putting together an image gallery the best approach would be to simply write a query that searches for the right tags etc instead of making explicit references to each of the images in their various locations.