Minimum Viable Product - Part 3 - Data types

Data types are the most subjective parts of Umbraco

Data types manifest as the user interface between actual data and the human entering it. Because of that pesky human element, deciding which inputs are best for the data can be obvious but can also be very subjective. The data input into data types will end up on the template one way or another. One would argue that you could use a textstring or textarea for just about everything as fairly discrete packets of data, but then that would lead to some pretty ugly parsing on the template. In contrast, you could use the Grid for everything which provides for a nice data entry, but then you would lose the re-usability of data elsewhere in your site. The goal of the developer is to strike a balance between usability with the human editor and the maintainability of the codebase.

The goal of the developer is to strike a balance between usability with the human editor and the maintainability of the codebase.

So for building this blog, I've decided to use mostly built-in core properties and one notable exception. I'll be using Archetype to build the blog articles as 'modules'. We won't cover how to get the data out of the data types just yet, we'll save that for the next part of the series. For now let's just examine a few document types and their data types.

Error Pages

Error pages are boring and usually need some sort of message and in my case, a particular HTTP status code to send to the browser. Examine the image below, you'll notice we've added only two data types (properties) to the document type:

The two data types we selected come pre-configured when you install Umbraco. If a particular data type has options (like the Richtext editor), you can create a new 'instance' of that data type and change the options to suit your needs for a particular document type. If you install a new data type (also called property editor), it will appear in this list usually only after create a new instance of it.

It's usually normal that document types have data types, but for this blog out of the many document types that I created, only three have actual data types on them. Why you ask? Because it's not required that you render your template from properties on a document type. In fact most of my document types will just use static templates. If I want to be able to edit these pages without editing the templates, I'll need to add data types to the document type and then map them to my templates. Since I'm the only one editing this site for now, it's certainly a tradeoff I'm willing to make.

These document types have no data types (presently) along with some possible future properties:

  • BaseData
  • BasePage - Maybe add some SEO fields one day.
  • HomePage
  • BlogsFolder
  • MonthFolder
  • YearFolder
  • AboutMePage - Maybe convert text on page to RTE one day.
  • ContactFormPage - Maybe add form settings, like where to send submissions.
  • SearchPage - Maybe add number of results per page.
  • TagPage

These document types have some data types configured:

  • ErrorPage (see image above)
  • BlogPostPage
  • ContactFormSubmission

So why have so many document types without data types, why not reduce it down? I'm hoping that in the future that if the need arises that I need to edit a page frequently, I already a have document type that represents the type of page I need to edit. For example, if in the future I need to add a property to the AboutMePage, a place to put it already exists. Additionally, I subscribe to the idea that one document type = one template. Though Umbraco allows you to map many templates to one document type, that is just how I normally operate. Every now and then an edge case will appear and I'll map a couple to one. Getting a page to market fast typically means you start with static templates and then wire each one to an Umbraco document type one by one.

I subscribe to the idea that one document type = one template. Though Umbraco allows you to map many templates to one document type, that is just how I normally operate.

The BlogPostPage gets a little tricky

As I mentioned, this entire site has only three of its document types configured with data types. The ErrorPage is described above and we have yet to mention how we did BlogPostPage and ContactFormSubmission. The ContactFormSubmission is very simple, it only has two data types. This document type represents submissions from our yet to be built contact form:

  • Email (alias 'email') of type 'textstring'
  • Message (alias 'message') of type 'textarea'

Note, for those of you wondering why am I storing form submissions in Umbraco instead of in a custom DB table, it's a design decision. I don't expect hundreds of submissions and storing in Umbraco is quick and easy. However if I planned on receiving a high volume of submissions, then I would take the time to save them into a custom table instead. Saving items in Umbraco means overhead from versioning, caching, etc which won't make sense in the long run. But for now, it's quick and easy.

However, the BlogPostPage gets a little tricky because we're going to use Archetype to pull off the following design. I want to be able to write a blog that may or may not have code, may or may not have videos, may or may not have quotes called out and may or may not have rich text. The idea is that at design time (when I'm choosing which data types to put on my document type), I can't commit to the number of rich text editors I will need, or the number of code blocks or the number of quotes that need rendered differently. If you've made an Umbraco site with macros before, you know that they could be used to pull off this functionality. The problem for me (highly opinionated) is that macros clutter up the RTE and can become difficult to manage/edit. We could also use similar items such as the built-in Grid, Sir Trevor or Nested Content to do what I'm suggesting. Since Archetype is near and dear to me, that's the one I typically go for since I understand it the best (I also want to avoid a referendum on the differences :) ).

Note that using one of the just listed property editors creates an issue later on (which we solve easily) when it comes to searching with Examine, the built-in searcher.

Words sometimes aren't enough to explain what it is we're going for so enjoy this short video that shows what we're going for. While we haven't talked templates yet, each module you see in Archetype is mapped to a partial view. So while we're sort of looking into the future, don't get tripped up over the templating stuff just yet.

Configure the BlogPostPage

First things first, let's install Archetype and navigate to the Developer > Data Types section to create a new instance of Archetype. I typically name mine prefixed with the name of the data type along with the instance name (in this case 'Blog Builder'). Once you create the instance, configure the 'Global Fieldset Options' like this:

Then configure the rest of the Archetype like this. I kept this image as an external file to keep the blog post size down. Take care to note that the 'Break Module' has a new instance of a core 'Dropdown' that I created, it looks like this configured.

Then you should have a final result that looks like this:

Now all we need to do is place this newly configured Archetype on the BlogPostPage document type along with a few other properties we'll use. Configure the document type like this:

The tags data type I used in the above image was configured like this.


Whew! That seemed like a bit of work, but in the end I hope you see the value in doing it this way. You might think that using Archetype might not be the quickest option to get something to market. Indeed it takes a bit of planning but will pay dividends in the future for me. To recap we use data types to accept input from the editor. We don't have to put any data types on a document type at all. We can come back at a later date to make our site more dynamic. This is all to set the table for the next part which will cover outputting your data types onto templates.