If you find a text field has the same set of options used several times, you may want to change it from an unmanaged text field to a field based on a managed list of elements.
When making this change, you have two options:
- Schema defines the list: if you want control of the order of the field options and the options do not need translation, consider placing the options in the Schema directly. Optionally use an Embedded Field to manage the same list everywhere its needed.
- Category defines the list. if you want editors to have the ability to bulk apply and search for items tagged with the option as well as for dynamic website functionality along with translation of the options, use a Category and its Keywords instead instead.
Building Blocks setup:
- Schema: Test Text Change with one text field called "options" (it really should have been singular as in "option")
- Components:
- 1.xml, with options = 1
- 2.xml, with options = 2
- 3.xml, with options = 2
- Category: Numbers (not used yet), with Keywords:
- 1
- 2
- 3
Scenarios to confirm:
- Change the plain text field to a list, as defined in the Schema
- Change the plain text field to a list, as defined in a Category
Before with Plain Text
Schema Before
 |
| The XML Name really should be "option." |
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="uuid:72d5b86c-e376-4fbe-b860-7b57a9caadd9" xmlns:tcmi="http://www.tridion.com/ContentManager/5.0/Instance" xmlns:xlink="http://www.w3.org/1999/xlink" elementFormDefault="qualified" targetNamespace="uuid:72d5b86c-e376-4fbe-b860-7b57a9caadd9">
<xsd:import namespace="http://www.tridion.com/ContentManager/5.0/Instance" schemaLocation="cm_xml_inst.xsd"></xsd:import>
<xsd:annotation>
<xsd:appinfo>
<tcm:Labels xmlns:tcm="http://www.tridion.com/ContentManager/5.0">
<tcm:Label ElementName="options" Metadata="false">options (text)</tcm:Label>
</tcm:Labels>
</xsd:appinfo>
</xsd:annotation>
<xsd:element name="Content">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="options" minOccurs="0" maxOccurs="1" type="xsd:normalizedString">
<xsd:annotation>
<xsd:appinfo>
<ExtensionXml xmlns="http://www.tridion.com/ContentManager/5.0"></ExtensionXml>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Example Component Before
 |
| The "1" is in the original plain text field, not managed by a list. |
<Content xmlns="uuid:72d5b86c-e376-4fbe-b860-7b57a9caadd9" xmlns:xlink="http://www.w3.org/1999/xlink"> <options>1</options> </Content>
After
Change #1: Schema Defines List
Schema field based on enumerated options, with the list defined in the Schema:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="uuid:72d5b86c-e376-4fbe-b860-7b57a9caadd9" xmlns:tcmi="http://www.tridion.com/ContentManager/5.0/Instance" xmlns:xlink="http://www.w3.org/1999/xlink" elementFormDefault="qualified" targetNamespace="uuid:72d5b86c-e376-4fbe-b860-7b57a9caadd9"> <xsd:import namespace="http://www.tridion.com/ContentManager/5.0/Instance" schemaLocation="cm_xml_inst.xsd"></xsd:import> <xsd:annotation> <xsd:appinfo> <tcm:Labels xmlns:tcm="http://www.tridion.com/ContentManager/5.0"> <tcm:Label ElementName="options" Metadata="false">options (text)</tcm:Label> </tcm:Labels> </xsd:appinfo> </xsd:annotation> <xsd:element name="Content"> <xsd:complexType> <xsd:sequence> <xsd:element name="options" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:appinfo> <ExtensionXml xmlns="http://www.tridion.com/ContentManager/5.0"></ExtensionXml> <tcm:Size xmlns:tcm="http://www.tridion.com/ContentManager/5.0">1</tcm:Size> <tcm:listtype xmlns:tcm="http://www.tridion.com/ContentManager/5.0">select</tcm:listtype> </xsd:appinfo> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:normalizedString"> <xsd:enumeration value="1"></xsd:enumeration> <xsd:enumeration value="2"></xsd:enumeration> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>Change #2: Category Defines List
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="uuid:72d5b86c-e376-4fbe-b860-7b57a9caadd9" xmlns:tcmi="http://www.tridion.com/ContentManager/5.0/Instance" xmlns:category="tcm:0-4-1/Categories.xsd" xmlns:xlink="http://www.w3.org/1999/xlink" elementFormDefault="qualified" targetNamespace="uuid:72d5b86c-e376-4fbe-b860-7b57a9caadd9"> <xsd:import namespace="http://www.tridion.com/ContentManager/5.0/Instance" schemaLocation="cm_xml_inst.xsd"></xsd:import> <xsd:import namespace="tcm:0-4-1/Categories.xsd" schemaLocation="tcm:0-4-1/Categories.xsd"></xsd:import> <xsd:annotation> <xsd:appinfo> <tcm:Labels xmlns:tcm="http://www.tridion.com/ContentManager/5.0"> <tcm:Label ElementName="options" Metadata="false">options (text)</tcm:Label> </tcm:Labels> </xsd:appinfo> </xsd:annotation> <xsd:element name="Content"> <xsd:complexType> <xsd:sequence> <xsd:element name="options" minOccurs="0" maxOccurs="1" type="category:Numbers"> <xsd:annotation> <xsd:appinfo> <ExtensionXml xmlns="http://www.tridion.com/ContentManager/5.0"></ExtensionXml> <tcm:Size xmlns:tcm="http://www.tridion.com/ContentManager/5.0">1</tcm:Size> <tcm:listtype xmlns:tcm="http://www.tridion.com/ContentManager/5.0">select</tcm:listtype> </xsd:appinfo> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>
Example Component After
Changing to a managed list (either in the schema field or with a Category) has nearly the same results to CMS editors. The Component form looks the same for either change.
<Content xmlns="uuid:72d5b86c-e376-4fbe-b860-7b57a9caadd9" xmlns:xlink="http://www.w3.org/1999/xlink"> <options>1</options> </Content>
However, there's a slight difference for Schemas that manage the list of options. For Components like 3.xml in the example, which have values outside of the defined list options, you may get a notification:
The Component's source will lose the value for <options>. Component 3's source had:
<Content xmlns="uuid:72d5b86c-e376-4fbe-b860-7b57a9caadd9" xmlns:xlink="http://www.w3.org/1999/xlink"></Content>However, for a Component with an invalid option (e.g. "3" when the Numbers Category lack a Keyword for "3") for a field that uses a Category, the invalid option does not appear in the Component Form, but can be seen in the source:
<Content xmlns="uuid:72d5b86c-e376-4fbe-b860-7b57a9caadd9" xmlns:xlink="http://www.w3.org/1999/xlink"> <options>3</options> </Content>
This invalid option could cause issues with templating or any Web application-side logic that relies on the Categories. I did not confirm if there's a difference between the stored and presented value, you may want to further test your scenario and confirm any impact to Core Service functionality.
Recommended Approach for Changing a Schema Field from Plain Text to a "Managed List"
In summary, the content structure does not change when changing the options. You'll want to match all the existing text values with a new managed list, otherwise you risk data lose (more so when the list of options is managed in the Schema). Regardless, you'll want to synchronize your changes.When changing a field from unmanaged to managed, be sure to:
- Make a Content Porter and/or database backup before signification changes (of both the content and the Schema)
- Include all the current options for a given environment and the others. For example, the Production CMS may have a different set of text settings than Development or Test.
- Consider the BluePrint -- are there options in lower Publications in local Keywords?
- Synchronize Components, using the GUI, API, or Content Porter
- Let the editors know!
Finally, be aware of what the options imply. Adding a mandatory field means you now need mandatory fields. Changing from checkboxes to a radio button means you can only have one (mandatory) value for the field.
No comments:
Post a Comment
Feel free to share your thoughts below.
Some HTML allowed including links such as: <a href="link">link text</a>.