I have just installed and setup v7.2 Beta2 - I thought I would use the new Compositions feature for Doc Types but then realised ... I wasn't really sure when or why I would need to!?
SEO is one reason I have seen mentioned, but I usually have a "base" content DocType that all other content types inherit from, which means they all automatically have SEO fields.
Is there an easily explainable case for using Compositions rather than the structure I have used before?
Also, with Compositions, if a DocType is composed of multiple DocTypes, will DocTypes that inherit from it work as before - i.e. inherit all parent data fields?
I think one of the concepts of using compositions is that you can for instance create each of the tabs that a document type should consist of as a composition. So if you have "Content", "Settings" and "SEO" tabs for instance each of those can be created as compositions and you can easily build your document types based on the compositions if you for instance don't need to have a settings section on a certain document type or if you for some reason don't need a content tab on another one.
But the approach of simply inheriting a tab from a master document type to your page document types beneath it is also a viable approach. But it's just really hard to change things if you for some reason create a document type under your master document type by mistake since it should not have inherited the "SEO" tab but should have all the other tabs. Then you need to delete the document type and create it once again, this time not inheriting from the Master document type...and without compositions you need to Add the tabs and properties once again manually. With compositions you can just add the tabs needed for the document type and you don't have to rely on inheriting. Inheriting can get really messy if you make too many levels and it can be hard to reorganize or change things.
But fortunately you have the freedom to decide and choose how you would like to build your document types using the techniques you like. By using compositions you have another neat option to create chunks that can easily be reused on your document types without relying on inheritance - Or you could mix the two if it makes sense :)
This is just my 2 cents - Hope you find it useful.
Yes, OK - I can appreciate that. Also, it wasn't clear that you could mix the two concepts.
Using the inheritance option - assuming you get it right - gives a visual organisation to the doc types. I know that it is hard to rearrange them, however I usually use uSiteBuilder (up to Umbraco V6) which makes rearranging doc types very easy.
I saw this http://issues.umbraco.org/issue/U4-5769 and thought the suggestion of splitting Doc Types and Composition elements into different sections was a good idea. Otherwise, it could be hard to figure out what is what on larger projects!
Compositions - when to use
I have just installed and setup v7.2 Beta2 - I thought I would use the new Compositions feature for Doc Types but then realised ... I wasn't really sure when or why I would need to!?
SEO is one reason I have seen mentioned, but I usually have a "base" content DocType that all other content types inherit from, which means they all automatically have SEO fields.
Is there an easily explainable case for using Compositions rather than the structure I have used before?
Also, with Compositions, if a DocType is composed of multiple DocTypes, will DocTypes that inherit from it work as before - i.e. inherit all parent data fields?
Hi Gordon
I think one of the concepts of using compositions is that you can for instance create each of the tabs that a document type should consist of as a composition. So if you have "Content", "Settings" and "SEO" tabs for instance each of those can be created as compositions and you can easily build your document types based on the compositions if you for instance don't need to have a settings section on a certain document type or if you for some reason don't need a content tab on another one.
But the approach of simply inheriting a tab from a master document type to your page document types beneath it is also a viable approach. But it's just really hard to change things if you for some reason create a document type under your master document type by mistake since it should not have inherited the "SEO" tab but should have all the other tabs. Then you need to delete the document type and create it once again, this time not inheriting from the Master document type...and without compositions you need to Add the tabs and properties once again manually. With compositions you can just add the tabs needed for the document type and you don't have to rely on inheriting. Inheriting can get really messy if you make too many levels and it can be hard to reorganize or change things.
But fortunately you have the freedom to decide and choose how you would like to build your document types using the techniques you like. By using compositions you have another neat option to create chunks that can easily be reused on your document types without relying on inheritance - Or you could mix the two if it makes sense :)
This is just my 2 cents - Hope you find it useful.
/Jan
Yes, OK - I can appreciate that. Also, it wasn't clear that you could mix the two concepts.
Using the inheritance option - assuming you get it right - gives a visual organisation to the doc types. I know that it is hard to rearrange them, however I usually use uSiteBuilder (up to Umbraco V6) which makes rearranging doc types very easy.
I saw this http://issues.umbraco.org/issue/U4-5769 and thought the suggestion of splitting Doc Types and Composition elements into different sections was a good idea. Otherwise, it could be hard to figure out what is what on larger projects!
is working on a reply...