Compared to Umbraco, Sitecore CMS has a similar (but more complex) way of constructing document types. (the term in Sitecore is actually not document type, but I'll continue using the Umbraco terms...)

One nice feature of Sitecore CMS is the possiblity of creating "partial" document types. In umbraco terms: The possibility to create and save tabs on document types seperately with the possibility to use them in other document types. Simply by adding reference in a multiselect "based on the following partial document types". Of course after that, your own properties can be added to your new document type.

An example:
A partial document type which is named: "Metadata" would include some fields for page title and some metatags.

Each newly created document type can now be based on this metadata tab. Every page eventually has metadata. Adding 1 extra property to the "Metadata" partial document type will add it automatically to every document type.

Is this something that is also possible in umbraco?

Nico

With all due respect to Neils, I agree 100% with Nico. I actually posted a question about this the other day. The concept of object inheritance is not at all complicated IMHO. It greatly simplifies coding and in my opinion would make life easier for those of us who create umbraco sites.

The problem (at least in my case) is that, as I build my site I discover things that should have been added to my document types but were not. Also, requirements tend to change over time. If I have 20 or so document types, this means I have to go back and change every one. Since I am picky about keeping field names consistent within a site, this means I have to be careful about making all these changes. Adding a copy document type feature would not be all that helpful in this case. But the ability to inherit from other base document types would be.

Every day, I am amazed at the genius of this framework as I discover new hidden gems, and I am grateful to those who have worked hard to develop it and make it available as open source. But this is a major shortcoming. Again, just my opinion as a fairly new umbraco user.

---

Pete Koutoulas • Fayette County Public Schools • Lexington, Kentucky

Fair enough, Neils. I'm not sure about the implementation details -- in fact, I don't have a clue -- but I am hoping that others with more framework knowledge will agree that this is needed and provide some detail.

As for me, all I can tell you is that I can see this as a real time saver. Here's a real-world example.

On my site, every content node which will be rendered as an HTML page needs to have a basic set of properties such as: title, author, description, keywords, etc. Defining a base document type as HTML page with those properties would greatly speed up the creation of new HTML document types. More importantly, if in the future we decide that all HTML documents should have a new property called isDeprecated, this would only have to be done in one place.

As far as I am concerned, I would rather that any fields added or deleted to a base doc type be immediately propagated to all children doc type and content nodes without the need to re-publish. That might be asking too much but that is how I would like to see it work.

(Of course, templates are another issue and if fields appear in templates then I can't see any way to have changes made automatically. That would still be a manual process.)

Thanks for listening. If not many people see this as something that is needed, then I'll shut up about it. ;)

---

Pete Koutoulas • Fayette County Public Schools • Lexington, Kentucky

Just bumping this topic for further discussion because there seems to be some renewed interest in it.

---

Pete Koutoulas • Fayette County Public Schools • Lexington, Kentucky

Hi, if only reason to create document type inheritance is creating properties, this can be solved by something like property copyer. You can select property chooce copyTo and select documentTypes to which it will be copied. Miss I something ?

Petr

Neil,

I understand that copying is not same as inheriting, but in real sites I will use inheritance only to defining properties once. Sometimes can be better if you can change property only for one document type (for example from mediapicker to upload) sometimes not.

Come up with a real scenario and I'll think about it. But the taxi/cop car is not an umbraco sample, it's a OO sample. Partial doctypes/doctype inheritance is only about sharing a couple of properties.

And adding partialism doesn't save you a lot of time in the example above. It saves you a couple of minutes.

---

Jeeeez, did I really start this :-)
Founder of the Umbraco project

All,

I am working on a large site with a lot of different doc types. They do all share some common properties - Breadcrumb name, and menu name for example. I also need to add Metadata fields to each of these document types at some point.

Niels is probably correct - "inheritance" would save me half an hour here, half an hour there. But I do still think it would make my life easier and take some of the tedium out of website development!

I have been giving this some thought over the last few days and wondered if some of my thoughts would be of use to anybody.

Aims of DocType Inheritance
1. Ability to inherit the properties defined in a base Document Type
2. When the base document type properties change, these changes should propogate to child types.

Examples of DocType Inheritance
1. Car website - base "Auto" doctype with child "CopCar" doctype
2. Metadata - all/most documents require Keywords, Description, Title, breadcrumb name

Simple Implementation
If the purpose of DocType inheritance is to re-use common fields, this can be achieved without making any changes to Umbraco and without even adding any packages to Umbraco (although, some Action Handlers could make the experience a little nicer).

I'm not saying this is a solution that everyone will want to use, but it is a possibility, and it works without any changes to Umbraco.

Meta Data
Here is a scenario:
1. a DocType called "BaseDocType" which has the properties "MetaKeywords", "MetaDescription".
The "BaseDocType" does not have a template assigned (@template=0)

2. a DocType called "Blog" which has the properties "blogImage" and "blogText" and "author"

3. a DocType called "Homepage" which has the properties "bodyText" and "featuredBlogPosts"

If we want all of our documents to use the properties in "BaseDocType" then the simplest way is to allow "BaseDocType" to be a child node of the other two - on the "Structure" tab of the Document Type, make sure that "BaseDocType" is an allowed child node.




WEBSITE
|
|-----------Homepage
| |---------- BaseDocType
|
|-----------Blog Post 1
| |---------- BaseDocType
|
|-----------Blog Post 2
| |---------- BaseDocType



You can write some XSLT, Python, or in Umbraco v4 you can write some C# straight into the page, to retrieve the properties of the child basedoctype.



Multiple Inheritance (BaseAuto)
Now we could add some more document types:
4. BaseAuto (With engine, transmission, topSpeed properties)
Again, no template should be selected for the base type (@template=0)

5. CopCar (With SirenColour and optional Doughnut holder)

Now you can re-use both the BaseAuto and the BaseDocType as follows:

WEBSITE
|
|-----------Homepage
| |---------- BaseDocType
|
|-----------Blog Post
| |---------- BaseDocType
|
|-----------Cop Car
| |---------- BaseDocType
| |---------- BaseAuto


@template=0
When writing menus, sitemaps, breadcrumbs etc you may already have come across 'umbracoNaviHide'. This is a flag which can be used to tell XSLT not to render links to some pages.
I also use the @template attribute for the same purpose.

So, if @template=0 - do not render that page in any navigation or sitemaps.

Some Action Handlers
This could be made more user friendly by writing some action handlers. For example, if the user attempts to create a CopCar, then an action handler could automatically create the BaseDocType and BaseAuto child nodes.

This will require a more formal way of specifying the "inheritance" - so that the action handler knows which child documents to create. I think this could be done with a simple data type / label which identifies the child document types or by using the Document type "name"



Some tweaks
You could arrange your content in reverse - which would give a view which looks more like an inheritance tree.

WEBSITE
|
|-----------BaseDocType
| |---------- Homepage

This would allow you to use Umbraco's <GET_ITEM recursive=true> tag, and a little less XSLT.
However, you would need to redirect from the BaseDocType to its child node (using an Umbraco Redirect package?) which I think would make this structure unuseable.

The "real" thing
For those of you who still want "proper" doctype inheritance, this is how I think it could be done as an Umbraco Package using Action Handlers.

Naming convention: Use the DocType naming convention mentioned above (A extends B).
An ActionHandler or .NET event will fire when the DocType is saved. The action handler will check the name of the DocType - parse the "extends B" and add any properties from DocType B to DocType A.

If DocType B is modified, an ActionHandler or .NET event will modify all doctypes which extend DocType B.

I think you would also need to have a sensible naming convention for properties. For example, all properties of DocType B would be named "B.poperty" - to simulate namespaces and avoid duplicate variable names.

Special care would need to be taken to handle deep inheritance (A extends B, B extends C - so when C is modified, B would be modified, which would cause A to be modified).

Conclusion
So - thats how I think it could be done. What do you think?

---

Adam Perry (blog, twitter), developing Umbraco based websites and applications for ConnectDigital.

While you're looking at Document Types can we please have default values that are applied if the content item doesn't supply a value (i.e. the developer can apply sitewide settings if the editor does not).

Also, can we please please please have a confirmation dialogue to confirm documenttype deletion? I'm sick of losing 100's of pages just because the content tree node reload was too slow and therefore selected the wrong documenttype for deletion (and if you delete the documenttype, say goodbye to all the pages you created using that dt!).

Richard

---

2 * 3 * 3 * 37 : The prime factorisation of The Beast.

Yes I would agree with all of the above.



I'm pretty sure there is a confirmation box (certainly in Umbraco v4)


Actually I think that is a great alternative solution to the problem.
You can ALMOST do this by creating your own data type now. The problem is that data types return a single property (so you end up with <data alias="myalias">singleproperty</data>.
If data types could also return an array or Dictionary of values, navigable with XSLT, you could certainly create a data type to solve this problem.

<data alias="myalias" subproperty="MetaKeywords">keywords</data>
<data alias="myalias" subproperty="MetaDescription>description</data>

---

Adam Perry (blog, twitter), developing Umbraco based websites and applications for ConnectDigital.