I have two document types. I'd like to bring in the tabs of one into the other. I understand that you can do this by choosing a composite doc type from the compositions menu:
The doc type I want to bring over is not in the menu. How do I add a doc type to the composition menu to be used in other doc types?
Is your 'Listing' Document Type 'composed' of other compositions?
There is a restriction in the UI to prevent nesting of compositions.
so you can't use a Doc Type as a Composition if 'itself' is composed from other Document Types. (I think because there are performance considerations if this was allowed to be infinitely nestable, and to avoid adding the same Composition multiple times to a Doc Type, once directly and then indirectly via other Doc Types...)
(Also if the Document Type is marked as an Element Type it can't be used as a composition.)
So a good strategy with Compositions is to try and think more granularly... eg have a Listing Settings Composition, with properties only referring to the 'Listing' aspect eg 'ArticleDate' or 'ListingImage' .... then your Listing Document Type is composed of this composition + your base content composition etc... then you can always add 'Listing' functionality to other Document Types at a later date...
... but it's hard, to refactor, particularly if you already have a Document Type created with tons of content filled in...
... and it can be hard to know at the time of creation, when a set of properties might be useful to be reused and when they will only be specific to that Doc Type... you can get 'tooo granular' and starting having a composition for every property!!! So there are always pragmatic choices to be made, and in hindsight they aren't always right!
Thanks for the reply and sorry for the late response.
Here's a screen shot of the Listing doc type with compositions open:
It looks like it contains its own native tab called "Shop" plus a "Navigation & SEO" which seems to be from a composite doc type. I guess this means I can't make it into a composite itself.
So if you had a 'Shop' Composition, with those Shop properties on, you could add that composition to the Listing Document Type, and Listing would have the same properties as it has now, coming from Shop and from NavigationBase compositions.
Then in your new Document Type you could choose the Shop composition and NavigationBase (if required) to be able to share those sets of properties across multiple doc types.
The tricky part is if you already have content for the Listing Document Type!
As in the Umbraco Backoffice, removing the properties from Listing and adding them to a Shop composition and adding that Composition back into Listing, even if the Alias are the same for the properties will result in any data in those fields being lost from Content Items based on 'Listing'...
So if you have only one or two listing pages, this refactor might be worthwhile in the long run...
If you have 100's of Listing pages, then it's still possible to refactor, but you have to operate directly on the database - I have a blog post that outlines the queries involved: http://tooorangey.co.uk/posts/moving-just-keep-moving/
(Element Types are V8 - it's a new way of defining the Doc Type to use with repeating properties like Nested Content)
I don't think I'll refactor. I'll just remember this for future tabs and properties I think I'd want to inherit in other doc types. The only thing I need from the Shop tab is the Listy Icon property, so any doc type that is a child of Listing needs that property. It's not hard to add that extra property manually so it's not a huge pain.
How do I add doc types to the compositions menu?
Hello,
I have two document types. I'd like to bring in the tabs of one into the other. I understand that you can do this by choosing a composite doc type from the compositions menu:
The doc type I want to bring over is not in the menu. How do I add a doc type to the composition menu to be used in other doc types?
Hi Gibran
Is your 'Listing' Document Type 'composed' of other compositions?
There is a restriction in the UI to prevent nesting of compositions.
so you can't use a Doc Type as a Composition if 'itself' is composed from other Document Types. (I think because there are performance considerations if this was allowed to be infinitely nestable, and to avoid adding the same Composition multiple times to a Doc Type, once directly and then indirectly via other Doc Types...)
(Also if the Document Type is marked as an Element Type it can't be used as a composition.)
So a good strategy with Compositions is to try and think more granularly... eg have a Listing Settings Composition, with properties only referring to the 'Listing' aspect eg 'ArticleDate' or 'ListingImage' .... then your Listing Document Type is composed of this composition + your base content composition etc... then you can always add 'Listing' functionality to other Document Types at a later date...
... but it's hard, to refactor, particularly if you already have a Document Type created with tons of content filled in...
... and it can be hard to know at the time of creation, when a set of properties might be useful to be reused and when they will only be specific to that Doc Type... you can get 'tooo granular' and starting having a composition for every property!!! So there are always pragmatic choices to be made, and in hindsight they aren't always right!
regards
Marc
Hey Marc,
Thanks for the reply and sorry for the late response.
Here's a screen shot of the Listing doc type with compositions open:
It looks like it contains its own native tab called "Shop" plus a "Navigation & SEO" which seems to be from a composite doc type. I guess this means I can't make it into a composite itself.
BTW, what is an Element Type?
Hi Gibran
Yes, that is the problem here...
So if you had a 'Shop' Composition, with those Shop properties on, you could add that composition to the Listing Document Type, and Listing would have the same properties as it has now, coming from Shop and from NavigationBase compositions.
Then in your new Document Type you could choose the Shop composition and NavigationBase (if required) to be able to share those sets of properties across multiple doc types.
The tricky part is if you already have content for the Listing Document Type!
As in the Umbraco Backoffice, removing the properties from Listing and adding them to a Shop composition and adding that Composition back into Listing, even if the Alias are the same for the properties will result in any data in those fields being lost from Content Items based on 'Listing'...
So if you have only one or two listing pages, this refactor might be worthwhile in the long run...
If you have 100's of Listing pages, then it's still possible to refactor, but you have to operate directly on the database - I have a blog post that outlines the queries involved: http://tooorangey.co.uk/posts/moving-just-keep-moving/
(Element Types are V8 - it's a new way of defining the Doc Type to use with repeating properties like Nested Content)
regards
marc
Ah, thanks for the insight Marc.
I don't think I'll refactor. I'll just remember this for future tabs and properties I think I'd want to inherit in other doc types. The only thing I need from the Shop tab is the Listy Icon property, so any doc type that is a child of Listing needs that property. It's not hard to add that extra property manually so it's not a huge pain.
Thanks again for the help.
is working on a reply...