UMBRACO CONTENT TREE

The Umbraco data model is supported by a number of relational databases. Out of the box, the data layer supports Vista DB, SQL CE, SQL Server, and MySQL databases. As of this writing, it does not support Oracle. Having the properties stored in a relational database makes persisting data convenient and provides developers with an industry standard for working with data. The Umbraco backoffice works directly with the installed database when saving and retrieving content nodes, media items, document types, users, and more. Because the authoring environment will not receive thousands of requests by hundreds of users at the same time, interacting directly with the database is not a performance consideration. If you had a very high-trafficked backoffice, you could run Umbraco in a distributed load-balanced environment. Chapter 13 briefly covers this topic.

Even though the supported databases are all multi-threaded, with thousands of requests coming in at the same time, the serving of content would eventually be hampered, resulting in a slow-responding website—not a desired outcome. Umbraco has a way to resolve this issue by providing the content and media items via a file-based, in-memory XML cache. This cache allows for much faster access to the structured data, and the dependency on making trips to a database is no longer there. It also allows the content management system (CMS) to separate published versus unpublished content because only published nodes will appear in the XML cache.

As of Umbraco version 4.5, the XML schema changed drastically from older versions. Now the XML output is a closer representation of your document types and content structure.

In Listing 2-1 you can see a representation of the legacy schema XML. This is what the XML cache looks like in versions prior to Umbraco 4.5.

<node id=“1188” version=“d45e540f-3162-417d-9861-fb49b13c567a” parentID=“1130”
level=“2” writerID=“0” creatorID=“0” nodeType=“1052” template=“1045”
sortOrder=“1” createDate=“2010-10-01T12:00:00” updateDate=“2010-10-
01T12:01:00” nodeName=“Sample Page” urlName=“sample-page”
writerName=“Administrator” creatorName=“Administrator”
nodeTypeAlias=“ContentPage” path=“-1,1130,1188”>
    <data alias=“pageTitle”>Page Title</data>
    <data alias=“umbracoNaviHide”>0</data>
    <data alias=“pageHeading”>Page Heading</data>
    <data alias=“bodyText”><![CDATA[<p>HTML content here.</p>]]></data>
</node>

Listing 2-2 is a sample, using the same data as in Listing 2-1, of the new XML schema. As you can see, the tags now represent the property names as opposed to Listing 2-1 where the <data> tag was used for all fields. It may not look like much of a change, but it makes a big difference when working with XSLT files in your macros (covered in Chapter 5 and Chapter 11).

<Textpage id=“1188” parentID=“1130” level=“2” writerID=“0” creatorID=“0”
nodeType=“1052” template=“1051” sortOrder=“1” createDate=“2009-11-20T15:50:02”
updateDate=“2010-08-30T13:12:27” nodeName=“Sample Page” urlName=“sample-page”
writerName=“Administrator” creatorName=“Administrator” path=“-1,1130,1188”
isDoc=“”>
    <pageHeading>Page Heading</pageHeading>
    <bodyText><![CDATA[<p>HTML content here.</p>]]></bodyText>
    <pageTitle>Page Title</pageTitle>
    <umbracoNaviHide>0</umbracoNaviHide>
</Textpage>

So, how does this difference matter in how you work with the XML cache? In short, it improves the readability of your code while also reducing the amount of data that's in memory because it reduces the number of attributes for a given tag. Listings 2-3 and 2-4 show the difference between the 4.x schema stylesheet and the 4.5 schema stylesheet.

LISTING 2-3: OutputTextPageOldSchema.xsl

<ul>
    <xsl:for-each select=“$currentPage/node [@nodeTypeAlias =
string(‘TextPage’) and string(data [@alias=‘umbracoNaviHide’]) != ‘1’]”>
        <li>
            <a href=“{umbraco.library:NiceUrl(@id)}”>
                <xsl:value-of select=“@nodeName”/>
            </a>
        </li>
    </xsl:for-each>
</ul>

LISTING 2-4: OutputTextPageNewSchema.xsl

<ul>
    <xsl:for-each select=“$currentPage/* [name() = string(‘TextPage’) and
 string(umbracoNaviHide) != ‘1’]”>
        <li>
            <a href=“{umbraco.library:NiceUrl(@id)}”>
                <xsl:value-of select=“@nodeName”/>
            </a>
        </li>
    </xsl:for-each>
</ul>

You may not notice a big difference between the two preceding listings, but you will notice that instead of cluttering the code with the extra attribute selectors, you can simply target the various properties or tags as defined in the document type that supports this content. Chapters 5 and 11 provide far more detailed examples of the differences.