Do I really need Document Types as well as Templates?
This may sound like a stupid question, but I cant see why I need Document Types - they just add to the confusion!
It looks like I can create just a Template only and then create a new content page and link to that template. Are Document Types just for creating advanced functionality or something?
Yes, you really need Document Types, that is, if you want any dynamic content in your Templates. Where Templates are all about presentation, Document Types are all about your data, and how you structure it.
As Anthony is explaining above document types are the fundament for any Umbraco solution you build since it's going to contain all the data of the website.
What is it that you find confusing about them? Do the above posted links make sense in the way they explain the concept of document types or do you feel it can be explained more explicitly?
I've seen the links and watched the videos so many times, but they weren't doing it for me. I have today managed to kind of get my head around it,noy from the documentation but simply from trial and error.
It just seems very complicated to me. The documentaion is very weak, and Googling seems to just yield many other developers with a multitude of problems.There should be a step by step guide that covers multiple scenarios - for the more I learn, the more more questions I think of.
The biggest learning step to take with Umbraco is to tie all the different concepts - document types, templates, data types, macros, scripts - together. Once you have taken that step, you'll understand how everything logically ties together, and how well structured and maintainable an Umbraco website is. A description of Document Types, that did it well for me, was the comparison of Document Types with tables in a database. If I need to build a webpage showing, let's say, 'activities' of a student club website, I start with the Document Type and I take an 'activity' as a logical unit:
1. So the first thing I do is to create an 'activity' document type
Then I need to think which activity data I would like to show to a visitor on the 'activity' webpage. This visitor will likely be interested in 'when' this activity takes place.
2. So I create an 'activity date' property for my document type.
This 'activity date' property is analogous to a 'field' in a database table, and just as is the case with a table field, I need to assign a data type to it. This is where the Umbraco Data Types comes into play. I could choose a 'Textstring' for my 'activity date' property, this would make editors have to manually type in a date for the activity item they create in the backoffice. But to prevent editors from having to manually type in a date, and to have a consistent date format, I choose a Data Type that is more fit to hold dates, I choose a Date Picker data type.
As you see, I'm having two concerns here:
1. What does my data consist of, how should I structure it.
2. How do I want the editors of the website to deal with this data.
With the second concerning also come the 'tabs' into play. On a document type you can define 'tabs'. It's a way to group your properties in the Umbraco Backoffice, and it is completely up to you how you group them. You're not even obliged to create tabs, you could order all of your properties under the default tab 'generic properties'. To make life on my editors easy, I define three tabs for my 'activity' document type:
'Details': holding the properties for practical data like: date, place, subscription price
Description: holding a 'Activity Description' property
At this point in time, I have created an 'activity' Document Type, and set some properties on it, holding the data of my 'activity item'. Editors can now start to enter 'activities' in the Umbraco Backoffice. However, I don't have any means of showing these activities to the web visitors. This is where Umbraco Templates come into play.
So I'll create an 'Activity' Template where I present my activity data to the visitor of the website.
The reason why the storage and structuring of data in Document Types is seperated from the presentation of this data through Templates, is a very deliberate choice. It enables Umbraco developers to be in complete control of the html markup of their webpages. As a matter of fact, when you create a template, and add no markup and dynamic data to it, you'll see a blank page with no html markup in it's source code. This is a domain where Umbraco differentiates itself from other CMS's that inject all kinds of markup and code into the pages that were created by editors, making it sometimes hard to optimize the markup for Search Index Optimisation, semantically correct markup, compliance to Web Standards, etc ...
So to summarize:
There are three main concepts interacting with each other:
Document Types for structuring and holding your data
Data Types for telling the system which kind of data the document type is holding
Templates for presenting this data on a webpage.
I you understand these three concepts and how they interact with each other, you'll be able to create websites that are maintainable, get indexed well by search engines like Google and have clean markup that complies to Web Standards.
Do I really need Document Types
Hi,
Do I really need Document Types as well as Templates?
This may sound like a stupid question, but I cant see why I need Document Types - they just add to the confusion!
It looks like I can create just a Template only and then create a new content page and link to that template. Are Document Types just for creating advanced functionality or something?
Hi Richrd,
Yes, you really need Document Types, that is, if you want any dynamic content in your Templates. Where Templates are all about presentation, Document Types are all about your data, and how you structure it.
Talk a look at Umbraco TV for a video about Document Types:
Or take a look at the Umbraco Documentation http://our.umbraco.org/documentation/v480/Using-Umbraco/Backoffice-Overview/Document-Types/
greetings,
Anthony
Hi Richard
As Anthony is explaining above document types are the fundament for any Umbraco solution you build since it's going to contain all the data of the website.
What is it that you find confusing about them? Do the above posted links make sense in the way they explain the concept of document types or do you feel it can be explained more explicitly?
/Jan
Thank you, and sorry for the the delay.
I've seen the links and watched the videos so many times, but they weren't doing it for me. I have today managed to kind of get my head around it,noy from the documentation but simply from trial and error.
It just seems very complicated to me. The documentaion is very weak, and Googling seems to just yield many other developers with a multitude of problems.There should be a step by step guide that covers multiple scenarios - for the more I learn, the more more questions I think of.
Thanks.
Hi Richard,
The biggest learning step to take with Umbraco is to tie all the different concepts - document types, templates, data types, macros, scripts - together. Once you have taken that step, you'll understand how everything logically ties together, and how well structured and maintainable an Umbraco website is. A description of Document Types, that did it well for me, was the comparison of Document Types with tables in a database. If I need to build a webpage showing, let's say, 'activities' of a student club website, I start with the Document Type and I take an 'activity' as a logical unit:
1. So the first thing I do is to create an 'activity' document type
Then I need to think which activity data I would like to show to a visitor on the 'activity' webpage. This visitor will likely be interested in 'when' this activity takes place.
2. So I create an 'activity date' property for my document type.
This 'activity date' property is analogous to a 'field' in a database table, and just as is the case with a table field, I need to assign a data type to it. This is where the Umbraco Data Types comes into play. I could choose a 'Textstring' for my 'activity date' property, this would make editors have to manually type in a date for the activity item they create in the backoffice. But to prevent editors from having to manually type in a date, and to have a consistent date format, I choose a Data Type that is more fit to hold dates, I choose a Date Picker data type.
As you see, I'm having two concerns here:
1. What does my data consist of, how should I structure it.
2. How do I want the editors of the website to deal with this data.
With the second concerning also come the 'tabs' into play. On a document type you can define 'tabs'. It's a way to group your properties in the Umbraco Backoffice, and it is completely up to you how you group them. You're not even obliged to create tabs, you could order all of your properties under the default tab 'generic properties'. To make life on my editors easy, I define three tabs for my 'activity' document type:
'Details': holding the properties for practical data like: date, place, subscription price
Description: holding a 'Activity Description' property
Download: holding a Activity Download property (for flyers, brochures, etc ...)
At this point in time, I have created an 'activity' Document Type, and set some properties on it, holding the data of my 'activity item'. Editors can now start to enter 'activities' in the Umbraco Backoffice. However, I don't have any means of showing these activities to the web visitors. This is where Umbraco Templates come into play.
So I'll create an 'Activity' Template where I present my activity data to the visitor of the website.
The reason why the storage and structuring of data in Document Types is seperated from the presentation of this data through Templates, is a very deliberate choice. It enables Umbraco developers to be in complete control of the html markup of their webpages. As a matter of fact, when you create a template, and add no markup and dynamic data to it, you'll see a blank page with no html markup in it's source code. This is a domain where Umbraco differentiates itself from other CMS's that inject all kinds of markup and code into the pages that were created by editors, making it sometimes hard to optimize the markup for Search Index Optimisation, semantically correct markup, compliance to Web Standards, etc ...
So to summarize:
There are three main concepts interacting with each other:
Document Types for structuring and holding your data
Data Types for telling the system which kind of data the document type is holding
Templates for presenting this data on a webpage.
I you understand these three concepts and how they interact with each other, you'll be able to create websites that are maintainable, get indexed well by search engines like Google and have clean markup that complies to Web Standards.
hope this helps,
greetings,
Anthony
is working on a reply...