In this blog post I am going to show how to use an alternate rendering mechanism to render Managed Metadata Fields which allows them to behave like standard Choice Fields.
A Brief Background
Managed Metadata fields are a really cool feature of SharePoint 2010. They allow an administrator to configure a field in SharePoint to source its values from one or more terms within a term set. Terms can be used in a number of ways such as tagging and in fields within lists and libraries. I have had several of my customers want to move away from using Choice based fields for some of their content types to Man
aged Metadata fields however the editing experience changes. Choice fields usually render as either a dropdown list or in the case of where multi values are a set of checkboxes for each potential choice value. Managed Metadata Field editing is done with a single textbox which leverages AJAX to implement type ahead auto population. As a result a user can start typing part of the name of a term and a list will pop within the UI to help filter the choice of terms. There is also a button next to the textbox which allows the user to popup a modal dialog that displays the choice of terms. As you can probably tell by this description the user experience can be quite different when moving from a SharePoint Choice Field to a Managed Metadata Field and users will most likely find this move at least a little confusing.
So out of the box why can’t we render Managed Metadata fields the same way we render Choice fields? Rendering 
Managed Metadata Fields as a set of checkboxes or as a drop down list does have its limits such as:
Terms can have sub-Terms which do not render easily with Drop Down or checkbox controls.
A Term Set can contain a great number of Terms to choose from and the Managed Metadata Select dialog is going to better handle this large set of choices than a drop down list. In addition this dialog will better handle the case when multi values are allowed vs. a large number of checkbox controls.
The default rendering of Manage Metadata Fields allows for new Terms to be added in the case where the field is exposing an open Term Set for which the user has permissions to add Terms.
With the Office 2010 Client there is parity for editing Managed Metadata fields with the out of the box rendering on the server.
So given all these limits I think you can see why the decision was made to go with the implementation we have today. That said, there are still use cases where a Choice Field type of rendering mechanism will work and in this blog I will show you one way to accomplish this and as I go through the scenario I will point out advantages of this approach.
The Scenario
Lets suppose we have a retailer which uses SharePoint to host a list of shirts where each shirt has a single Primary Color and zero or more Secondary Colors.
Today the list has two independent choice fields for the color fields and when a change needs to occur such as adding a new color or removing a color from the list of choices this requires changes to the content type which must be pushed down to ever list which may leverage the color scheme. Moving forward we may want to use a Term Set with Terms for each color so we have a single source for where we can manage, add, remove, and deprecate colors without having to edit and redeploy the content type.
To start I created a Term Set named “Colors” and loaded a number of Terms, each representing a color I want as a choice for the fields for which the Term Set will be used. Now at this point I can choose to create two Managed Metadata Fields and hook them up to the “Color” Term Set and offer my users a relatively compelling experience. However in my scenario my Term Set is fairly small and it’s a closed Term Set, that is, I will own adding, updating, and deleting of Terms from my Term Set and not allowing users to contribute their own colors. The image on the left shows my Term Set and notice I have marked one term “Teal” as deprecated which in my custom field type which I will detail later is ignored as a valid choice. The image below shows what my list’s edit dialog may look like when using the out of the box Managed Metadata rendering.
The Project
Before digging into Visual Studio we need to understand what we are about to create. A Field in SharePoint has really 4 main components, a Field Type, Field Value, Field Control, and finally a Field Definition. In chapter 10 of Andrew Connell’s book SharePoint 2007 Web Content Management Development on page 158 he has a really nice image which puts these elements together which I will attempt to explain here:
Field Type - This is the main entry point class which implements the custom field. Your custom Field Type will typically derive from one of the out of the box Field Types such as SPFieldLookup, SPFieldUrl, etc which all each derive from the base SPField. The primary job of the Field Type is to expose the Field Value and Field Control to callers.
Field Value - This class wraps the actual value or values being stored. There is no SharePoint inheritance base class structure which you need to follow or any interface which you need to implement. Its all up to you on what you want to store here.
Field Control – This class needs to derive from BaseFieldControl and is responsible for the rendering of the control when being edited by the user.
Field Definition – Unlike the previous items this is an XML file that describes to SharePoint the field type and its properties and default rendering.
So now that we understand the components lets talk about how we are going to implement each. As mentioned the Field Control handles the edit time rendering and therefore the main bulk of our effort will be spent here changing what is to be exposed to users. The class will derive from BaseFieldControl and will handle the case when the field handles single or multi-value selections. Next is Field Type, the Managed Metadata column uses a class named TaxonomyField and for the most part does everything we need from this type minus one small detail. Since it’s the class which exposes the Field Control we need to create a new Field Type which derives from TaxonomyField but exposes our custom Field Control. Since we are not changing what is stored for the Managed Metadata Field we do not need to change the Field Type implementation which is implemented for a single choice field as TaxonomyFieldValue and for a mutli-choice as TaxonomyFieldValueCollection.
To get started we need to create a Field Definition which I named “Managed Metadata Choice”. I sourced this definition from the Managed Metadata Field Definition stored in fldtypes_taxonomy.xml which is located under the 14 hive under TEMPLATE\XML\. The XML needs to be modified to point to the assembly and class which is to represent our new custom Field Type, in this case TaxonomyChoiceFieldType.
The project, which is available for download below, is a relatively simple SharePoint project in that is only contains a few classes, one XML definition file and does not have any Features. One thing to be aware of is that after you deploy this solution you will need to do an IIS Reset before SharePoint will pick up the new custom Field.
This solution has a couple of limitations, first it does not allow the user to add additional terms when using an open term set. It also does not allow a user to choose sub-Terms. For example, if you had a Term Set named “Shapes” and sub-Terms “Square” and “Triangle” and chose to use the root of the Term Set as the anchor the only Term rendered would be “Shapes” and the sub-Terms would not be exposed.
The Result
The dialog below shows what this looks like after the custom field has been deployed and new columns instantiated with the custom field. The Primary Color field is a single select so its rendered as a drop down much in line with how Choice Fields are rendered. The Secondary Colors Field is build off our custom Field type and the option to allow multi-select was chosen therefore its rendered as a set of checkbox controls. What is not clear from this image is the fact that if you choose to localized your Term Set these two fields would be localized too which is a clear advantage over standard Choice Field types.
Conclusion
While normally the default Taxonomy Field rendering will work for most scenarios there are cases where it may make since to offer an alternative editing experience for Managed Metadata fields which closely resembles that of the Choice Field type especially when replacing a Choice Field with a Managed Metadata Field.
Microsoft.SP.Taxonomy.zip (83 kb)