An under-emphasized feature in Content Server metadata is the use of a path analogy to hold meaningful data.
Most implementations use Contribution Folders to provide a file system-like path to an item, when a path is needed. What happens if a document really needs to exist on multiple paths? Yes, you could create multiple copies of the document, and put a copy in in each folder, but that makes maintaining the content difficult.
To address this shortcoming, many implementations add additional metadata fields to hold data to emulate other paths. Dependent choice lists (“DCLs”) are a popular way to sort and categorize this extra data, but even DCLs have a problem when a document needs multiple sets of data applied to it. Eventually, a lot of extra metadata elements get introduced in the metadata model, often nearly identical to existing fields, resulting in confusion (“Which set of DCLs do I need to fill out to get the new HR policy to show up for both Minneapolis and San Francisco?”)
To address this shortcoming, many implementations add additional metadata fields to hold data to emulate other paths. Dependent choice lists (“DCLs”) are a popular way to sort and categorize this extra data, but even DCLs have a problem when a document needs multiple sets of data applied to it. Eventually, a lot of extra metadata elements get introduced in the metadata model, often nearly identical to existing fields, resulting in confusion (“Which set of DCLs do I need to fill out to get the new HR policy to show up for both Minneapolis and San Francisco?”)
Content Server metadata fields can be configured to use “trees” to store various different path analogies. This makes storing multiple paths very easy, with fewer overall fields than traditional DCLs.
Let’s take a walk through the forest.
In this example, I’m using states and cities, although I can easily use other DCL/relational data.
· Create a schema table called “tblStates” with two columns, “stateID” and “stateName”. “stateID” will hold the two character state abbreviation, and “stateName” will hold the full name of the state (shown later). Create a view in Configuration Manager that exposes all columns in the table as shown. On the “Options” tab in the view, select the “Is Sorted on Database” option, and sort the view on the stateName column.
· Create a schema table called “tblCities” with three columns, “cityID”, “stateID” and “cityName”. “cityID” in this case holds the airport code for the city, “stateID” will hold the two character state abbreviation where the city is located, and “cityName” will hold the full name of the city. Create a view in Configuration Manager that exposes all columns in the table as shown. On the “Options” tab in the view, select the “Is Sorted on Database” option, and sort the view on the “cityName” column.
· Create a relationship in Configuration Manager that ties the states table and the cities table on the “stateID” column in each table.
· Now create a new “memo” metadata field in Configuration Manager, called “xStateCity”. Make this field an option list. When configuring the source of the option list, select “Use Tree”, then select the view of the state table,
then the relationship connecting the state and city views,
and finally, select the view with the city data, if it’s not already filled in by selecting the relationship.
then the relationship connecting the state and city views,
and finally, select the view with the city data, if it’s not already filled in by selecting the relationship.
·
Check the two options at the bottom of the dialog that says “Show complete selection path” and “Store complete selection path”. Use “/” as the path separator.
Check the two options at the bottom of the dialog that says “Show complete selection path” and “Store complete selection path”. Use “/” as the path separator.
· Now when viewing the checkin page, a “Select” button is displayed instead of a typical input field for the field xCityState.
· Clicking the select button shows a popup as shown.
·
Expanding each state shows the cities underneath. Clicking the city adds the city as the selected option as shown.
Expanding each state shows the cities underneath. Clicking the city adds the city as the selected option as shown.
· Clicking OK populates the checkin page with the selected value.
· If the field is configured as a multi-select option list, multiple cities can be selected as shown below.
· The actual values are stored in a path analogy, i.e. “San Francisco” is stored as “CA/SFO”, so the entire value is actually stored as “CA/SFO, MN/MSP”, but San Francisco and Minneapolis are displayed.
· Any option displayed in the tree is a valid choice. For example, to add a STATE, simply click on the state name, instead of the city. This is very powerful in being able create flexible path analogies.
Hopefully, this example will let you see the forest of possibilities BECAUSE of the trees.
