Last time, I talked about how to get information about the current document type from a controller, or a view in, How To Get The Current Page In Umbraco 7.  Today I'm going to go over how to get data from other document types.

Getting Information About Another Page

Let's say you want to link to the search page from the header.  You could use this snippet of code:

In this snippet, I have hardcoded the Id of the search page in the code.  For anyone who is new to CMS development, this is a terrible idea and will give you no ends up bugs and deployment problems in your production environment. 

Let's say a content editor wants to delete the search page and create a new one, without updating your code, checking it in and deploying it (all tasks involving a developer) they won't be able to do it.  When you link to other pages you want to do it either by filtering a result set, or by getting the data from the CMS. I'm going to cover both approaches, but I'll start with filtering first.

Filtering Results

In a lot of situations, you may want to get one off pages, say a 'Search Results' document type, or a contact us document type.  These pages will probably live under your homepage.  Getting a reference to the homepage is easy, we can use (see How To Get The Home Page In Umbraco? for more info).

One approach to resolving the issue to dynamically getting a reference to a page, is to simply look for the children under the home page for the document type you care about, so:

If your page doesn't live under the homepage, then you could use this snippet:

Both of these snippets are better than hard-coding the ID.  In this code snippet, nothing is tied to a single Id.  A content editor can now add a new search page in the back-end, test it, delete the old one and the code will just magically update without any developer intervention.  Brilliant? The downside of this code is that we've hardcoded the document types alias in both.  Granted the document alias is a lot less likely to change, but there is also another approach.

The Settings Document Type

A settings page is a document type that is used solely as a container for all of your website's global settings.  This approach abstracts the need for any sort of hard-coding of pages to an Id or a document alias in your templates.  The benefit of this approach is that instead of having to duplicate code all over your codebase to look-up pages, you load the container page, get the setting/link you care about and off you go.

If a content editor wants to create a completely new search page using a completely different document type, they can update the setting page property and the website will just update without the need to get a developer involved at all. Using a template or document type as a settings container is a common pattern amongst any CMS build. 

To give you a quick idea, in your settings document type, go to the 'Generic Properties' tab, and click 'Add New Properties'


Call your field whatever you want and set the 'Type' to a content picker.  Now, when you create an instance of your 'Settings Document Type', the content editor can set the page to whatever they want.


Now if you use this code:

You can get access to the search page without having to hard-code anything. If you are like me, you may be looking at this code and thinking but this still breaks the separation of concerns in several ways.  First, the "SettingsPage" alias is still hard-coded.  If you want to get rid of this, you can add a content picker property on your home page and then get the setting page this route. The second issue is that we've hard-coded the "SearchPage" property. 

There are several ways to get over this and I'll cover the different approaches in another tutorial. One of the more common approaches would be to define your document types in code, using uSiteBuilder. 

More information can be found here.  Although this isn't the only option.