I made a doc type "Content" with header, body and some properties. Then a child doc type "ContentSpecial" with some more properties. Worked fine... Until my customer wants me to change the header & body properties description ONLY for ContenSpecial-pages.
No way to fix that without recreating the ContentSpecial doc type without the master document type set. Right? (Kinda easiest way to do this is editing the exported udt).
This makes it seem to me it's easiest to work without child document types at all. But then again, one misses the easiness of changing one thing for all similar document types. How do you structure your document types?
I don't use master/childe docTypes personally. Partly because of issues like the one you mention, partly because they are harder to handle in packages, and partly becase of the inertia caused by the fact that I started with umbraco before they were available and am a bit set in my ways.
None of these are particularly good reasons of course. But the choice to use or not use master docTypes is an important one... as you've discovered, it can be difficult to change them in some cases.
In my sites I generally create a generic docType that has all the tabs and common properties I use all the time. I then "copy" that docType for each new docType I need. I add a few properties and delete anything I don't need, which is very fast and easy to do. I try to give a lot of thought to my docTypes before making them so I don't ususally have to go back and change them very often.
This is how I handle docTypes in my sites, anyway. Others will no doubt have their own conventions and preferences.
A little bit dirty I know, but you could just change the doc types masterContentType back to 0 in the cmsContentType database table, and then just add those properties directly onto the template with what ever changes you need.
I'm not sure whether any data would get carried over to the new properties though (I guess it depends whether Umbraco remembers the actualy id for the data type, or just the alias).
Thanks, feels good I'm alone with this. I found it was kind of easy to create new one by exporting both document types (master and child) as udt's and edit the xml in a ordinary text editor, then importing the merged one back again. In my case I did not dare to try the db-way, I recreated the documents manually instead, was only two of them luckily.
err... feels good I'm *not* alone with this... Then I know I understood the principle correct and, hopefully some future improvements can be expected. (Yeah, I could do some efforts to it also, I should, just wait and see.)
Thanks for asking this question - I was pondering the same thing thing myself.
The overall problem in this kind of reminds me of the classic OO issue around classical inheritance vs interfaces - so you have the classic problem of a rigid object graph all inheriting from one base type - and then change requests (as always) come in and all of a sudden you have to start refactoring the whole graph just to add/change/remove a small behaviour, on one small section of the graph.
The solution here is often to programme to an interface, i.e. to define the required behaviour and then allow classes to choose if and how to implement that behaviour. Kind of made me think that an approximation of same thing might be possible for document types... if the Tabs were the actual behaviour, and one could then define standalone sets of these, and then attach these into the document type hierarchy at various points (as necessary)? So you would have classic document type inheritance for the really globally shared "will never change in a thousand years" stuff, and then the option to create/modify and attach/detach chunks of document type definitions (i.e. Tabs) where ever you need this. Might be a more flexible approach?
Anyways - there's a thought for you, standalone "Plug and Play Document Type Tabs"....
I'm always using a master doctype... 9/10 of my documenttypes needs to have some basic fields like Meta Description, Meta Keywords, Title Tag, No Index, UmbracoNaviHide etc. If a doctype shouldn't have theses properties I'll just create it without the master doctype and add the necessary fields, that'll take around two mins. But yearh, my master doctype is only with the very, very basic stuff, so all of the properties makes sense on a inherited doctype. :)
Best practice child document types or not?
I made a doc type "Content" with header, body and some properties. Then a child doc type "ContentSpecial" with some more properties. Worked fine... Until my customer wants me to change the header & body properties description ONLY for ContenSpecial-pages.
No way to fix that without recreating the ContentSpecial doc type without the master document type set. Right? (Kinda easiest way to do this is editing the exported udt).
This makes it seem to me it's easiest to work without child document types at all. But then again, one misses the easiness of changing one thing for all similar document types. How do you structure your document types?
Regards,
Jonas
I don't use master/childe docTypes personally. Partly because of issues like the one you mention, partly because they are harder to handle in packages, and partly becase of the inertia caused by the fact that I started with umbraco before they were available and am a bit set in my ways.
None of these are particularly good reasons of course. But the choice to use or not use master docTypes is an important one... as you've discovered, it can be difficult to change them in some cases.
In my sites I generally create a generic docType that has all the tabs and common properties I use all the time. I then "copy" that docType for each new docType I need. I add a few properties and delete anything I don't need, which is very fast and easy to do. I try to give a lot of thought to my docTypes before making them so I don't ususally have to go back and change them very often.
This is how I handle docTypes in my sites, anyway. Others will no doubt have their own conventions and preferences.
cheers,
doug.
A little bit dirty I know, but you could just change the doc types masterContentType back to 0 in the cmsContentType database table, and then just add those properties directly onto the template with what ever changes you need.
I'm not sure whether any data would get carried over to the new properties though (I guess it depends whether Umbraco remembers the actualy id for the data type, or just the alias).
Many thanks
Matt
Thanks, feels good I'm alone with this. I found it was kind of easy to create new one by exporting both document types (master and child) as udt's and edit the xml in a ordinary text editor, then importing the merged one back again. In my case I did not dare to try the db-way, I recreated the documents manually instead, was only two of them luckily.
Regards
Jonas
err... feels good I'm *not* alone with this... Then I know I understood the principle correct and, hopefully some future improvements can be expected. (Yeah, I could do some efforts to it also, I should, just wait and see.)
Thanks for asking this question - I was pondering the same thing thing myself.
The overall problem in this kind of reminds me of the classic OO issue around classical inheritance vs interfaces - so you have the classic problem of a rigid object graph all inheriting from one base type - and then change requests (as always) come in and all of a sudden you have to start refactoring the whole graph just to add/change/remove a small behaviour, on one small section of the graph.
The solution here is often to programme to an interface, i.e. to define the required behaviour and then allow classes to choose if and how to implement that behaviour.
Kind of made me think that an approximation of same thing might be possible for document types... if the Tabs were the actual behaviour, and one could then define standalone sets of these, and then attach these into the document type hierarchy at various points (as necessary)?
So you would have classic document type inheritance for the really globally shared "will never change in a thousand years" stuff, and then the option to create/modify and attach/detach chunks of document type definitions (i.e. Tabs) where ever you need this.
Might be a more flexible approach?
Anyways - there's a thought for you, standalone "Plug and Play Document Type Tabs"....
I'm always using a master doctype... 9/10 of my documenttypes needs to have some basic fields like Meta Description, Meta Keywords, Title Tag, No Index, UmbracoNaviHide etc. If a doctype shouldn't have theses properties I'll just create it without the master doctype and add the necessary fields, that'll take around two mins. But yearh, my master doctype is only with the very, very basic stuff, so all of the properties makes sense on a inherited doctype. :)
is working on a reply...