Items, in an abstract view, are the values that Modules (if configured to be item-based) create. When viewing a Node, the grid in the content area lists Items that were created by their respective Modules. A Module can be seen as a group of programming code whose purpose is to provide a specific set of functionality such as an Image Gallery Module. In turn, Items are the data that Modules create to allow you to define multiple and separate instances. Therefore an Image Gallery Module might be used to create an Image Gallery Item for friends and another Image Gallery Item for family. Similarly, the core Page Module allows a website to have multiple web pages, each containing different values. A Module is responsible for creating, managing and updating its Items. Because Modules can come in various shapes, sizes and functions, an Item is designed to be flexible in how it stores its information. How a Module decides to store its values and in what structure is up to the Module itself.

Allowing a Module to maintain a complex data structure enables them to provide rich and powerful features. The CMS framework takes the burden of managing each data structure off of the Module and provides an easy to read hierarchical structure.

Value Paths

Even though a Module can store certain values as private, it is encouraged to publicize the structure in which it stores its values. When any one value in an Item’s collection of values is made public or searchable, then it can be referenced by its Value Path.

Examples of how Value Paths can look like:

/Title
/Home/PhoneNumber
/Configuration/Animation/Speed
/Configuration/Animation/*     <-- This will return all values under "Animation"
/Configuration/Animation/[0]   <-  This will return the first sub value under "Animation". The indexer is zero based.
/MenuItems/Items/Item[AttributeName='Value'] <-- In addition to the path, an attribute name "AttributeName" with the value of "Value" must match in order for the value to be returned.

All Value Paths start with a ‘/’ and each level is further separated by a ‘/’. In the example /Title, the Module that stores this value in its Item, intends to store the Title value at the path /Title.

Value Paths can be at any depth. In the example /Configuration/Animation/Speed, there is a level ‘Configuration’ which contains Item configuration settings. Under it, there may be more settings other than Animation such as /Configuration/Performance or /Configuration/Language. Any of these may contain more settings under it such as /Configuration/Performance/Caching and so on.

To view an item's value details, open an item in the Workspace and click the "V" icon next to the Item name.

Data Types

Below is a table listing the supported value data types.

Name	Summary
Boolean	True or false
Integer	-2,147,483,648 to 2,147,483,647
Decimal	(-7.9 x 1028 to 7.9 x 1028) / (100 to 28)
DateTime	Example: 12/25/2010 12:00 PM
Guid	Global unique identifier. Example: DFA672A1-AB04-4DB9-91F3-DC044439F4FA
String	Plain text. Empty strings are not allowed and are converted to NULL.

Attributes

A single value can also contain a collection of attributes. Attributes are key and value pairs where the value does not have multi-language support. The value of an attribute is a string data type and therefore the CMS framework does not provide any additional validation.

Multi-Language

Connected Apps CMS framework provides built-in multi-language support to Item values without any additional effort required from modules. When marked for multi-language support, a value is able to accept multiple culture specific content. The cultures a value can hold is dependent on the languages enabled in the site settings. Learn how to manage support languages.

CMS users will be able to store language specific content across all items once a new language is enabled. During the CMS signup process, a default language is chosen and all Item values created are marked with this language. As new languages are enabled, CMS users will have the opportunity to provide value translations or equivalents for each Item. When browsing a multi-language enabled site, the user can be given the opportunity to set the language in which they wish to view content. If a request is made to an Item in a different language other than the default one, the framework will attempt to pull the requested language value, if none exist, then the framework will instead serve up the default language value.

Often times, a CMS user might be located in a different culture other than the default language or would simply prefer to work in the workspace in a specific language. To do this, a CMS user can simply change their preferred language in the Preferences area. Otherwise, a CMS user has the opportunity to being editing a Draft Item in a different language at any time by changing the Draft Item’s language.

Reference Values

If a value is marked as a Reference value, then the value and all sub values (regardless if any sub value is marked Reference or not) are stored in a separate location and are only referenced and merge into the Item value at run-time. Reference values can have different sub value structures depending on the language that is requested.

/PageTitle
/SliderImages
    /Image/src
    /Image/src

Take for example, in a non-reference value like above, there are two instances of "Image" located under the path /SliderImages. This is a static value structure that remains the same no matter what language is requested. If the CMS instance has enabled English and Chinese, when switching languages to edit, the value structure is the same in both languages. If a new "Image" is added to /SliderImages in English, then this is reflected in Chinese as well.

If the value at /SliderImages is marked as a reference value, then it and all sub values are independent of the overall Item value structure. In our example, the English and Chinese versions of the value can then be modified apart from each other. During rendering, reference values are merged with the overall Item value and provided to the owner Module to be rendered.

Index Values