Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Jonas Eriksson 930 posts 1825 karma points
    Feb 25, 2010 @ 12:49
    Jonas Eriksson
    0

    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

  • Douglas Robar 3567 posts 4647 karma points MVP 6x admin c-trib
    Feb 25, 2010 @ 13:12
    Douglas Robar
    1

    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.

  • Matt Brailsford 2298 posts 11146 karma points MVP 6x c-trib
    Feb 25, 2010 @ 13:20
    Matt Brailsford
    0

    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

  • Jonas Eriksson 930 posts 1825 karma points
    Feb 25, 2010 @ 14:48
    Jonas Eriksson
    0

    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

  • Jonas Eriksson 930 posts 1825 karma points
    Feb 25, 2010 @ 14:53
    Jonas Eriksson
    0

    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.)

  • Thomas 49 posts 78 karma points c-trib
    Jan 05, 2011 @ 17:27
    Thomas
    0

    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"....

  • Rasmus Berntsen 213 posts 251 karma points c-trib
    Jan 08, 2011 @ 17:01
    Rasmus Berntsen
    0

    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. :)

Please Sign in or register to post replies

Write your reply to:

Draft