Definition and configuration items

Version: 9.0

You use definition items to create SPEAK pages and configuration items to set the properties and behaviors of the definition items. You organize these items in the Sitecore content tree. If you follow the guidelines given here for organizing your application items, it will be easier to develop and maintain your application.

Page definition items

A SPEAK page definition item is a Sitecore item that defines a SPEAK page. The position of the page definition item in the content tree determines the URL that you use to access the page in your browser.

A page definition item has properties. You do not have to set very many of these properties, but the following are mandatory:

  • BrowserTitle: the title that the page has in the browser

  • Theme: the visual theme (this should normally be set as "Harvard")

A page definition item has a normal Sitecore layout; however SPEAK pages must use a layout designed for SPEAK. This ensures that the visual appearance of the page conforms to the SPEAK UI guidelines.

Templates for page definition items

When you use Sitecore Rocks to add a page definition item to the content tree, you can choose from a number of templates.

The templates create a basic page definition item, but do not contain any content. To include basic content, you can use a branch template instead. Branch templates are based on the standard templates, but they also contain the basic configuration and structural components that a SPEAK page needs for it to work.

There is a separate description of the page templates and branches that has more detail

When you work on an application with many pages that have a lot in common, you can create your own templates to make it easier to start each page you add.

Configuration items

All the components you add to a page have properties. These properties specify the behavior of the component and its interaction with other components and items. You can set these properties in the property sheet of the component.

Instead of setting the properties of the components in the property sheet in Sitecore Rocks, you can create a configuration item, set the properties as field values in this configuration item, and point the component to the configuration item. Now, you can change the values of these fields in the Content Editor.

You point a component to a configuration item by setting the value of the DataSource property of the component to the Sitecore ID of the configuration item.

You normally create configuration items as children of a PageSettings item, and you create the PageSettings items as children of the page definition item.

Generally, the templates for configuration items have names like: "<name of component> Parameters".

In applications that have multiple pages, pages sometimes have configurations in common. You can create a folder for these shared or common configuration items, and point all pages that need the shared configurations to this folder instead of replicating the configuration for each page.

Some components use configuration item templates that do more than replicate the properties of the component. The descriptions of the components in the SPEAK Component Reference describe what these templates are and how you use them.

Configuration items for multiple languages

If you want your application – now or later – to support multiple languages, you must use configuration items for all texts that end-users can see. For example, this text is in properties such as "Text" and "Tooltip," and for some components perhaps in other properties as well. The SPEAK Component Reference has details about this for each of the components.

When you use a configuration item for text, this text is the value of a field in a regular Sitecore item. This means that the standard Sitecore tools for text translation can be used to translate the text.

If you do not use configuration items, texts are stored as component properties, and the translation tools do not work for these texts.

Organizing application items

Some SPEAK applications have many pages and many page definition items. They tend to have many configuration items, too. Therefore, it is a good idea to define an information architecture before you start developing so that you immediately know where to store and find items once you start the development process.

For example, a simple application with relatively few pages could have an information architecture similar to this:

RequestResponse
<Application Folder>
    <Pages Folder>
        <Page1 Definition Item>
            PageSettings
                <Component1 Configuration Item>
                <Component2 Configuration Item>
        <Page2 Definition Item>
            PageSettings
                <Component1 Configuration Item>
                <Component2 Configuration Item>
    <Shared Settings Folder>
        <Common Component1 Configuration Item>
        <Common Component2 Configuration Item>
    <Templates>
        <X entity template>
        <Y entity template>
    <Test Data Folder>
        <X Entities>
            <X entity1>
            <X entity2>
        <Y Entities>
            <Y entity1>
            <Y entity2>

Do you have some feedback for us?

If you have suggestions for improving this article,