Using SPFilterDropdown to Reorder Options in a Dropdown on a SharePoint Form

Many times when you have a dropdown column in your lists, you’d like to show the values sorted in a different order than alphabetically. Sure, you can use a Choice column and order the choices in any way you’d like. However, in the cases where you want the dopdown to be based on a Site Column which is a Lookup into a list, you can’t specify the sort order. I prefer using a Lookup column in almost all cases because it means that an admin (or any user with permission, really) can update the values in a list context rather than a column settings context. We also often end up storing other information about the values in the list, which we can’t do with a Choice column.

Here’s an example. I have a Site Column called Recommendation. It’s a pretty common idea: what’s our view on a particular stock or bond? We may want to recommend to our clients that the stock should be a Strong Buy, Buy, Hold, or Sell. If we add those values to a list as the source for a Lookup column, they will be ordered like this: [Buy, Hold, Sell, Strong Buy]. That’s not how we logically think of things, so it’s not great.

SPServices to the rescue! If we add a column to the source list which contains the sort order we want, we can make things look the way we need them to work. In my list below, I have a column called, logically enough, SortOrder. Note that it contains values which will sort the recommendation options the way we want.

Recommendations Datasheet View

Recommendations Datasheet View

Then, in the forms where I use the Recommendation column, I can add a call to the SPFilterDropdown function which takes care of things for me. No, the function name really doesn’t indicate that it could help with this – I built it to let you filter the options in a dropdown based on a column in the source list – but there’s a little trick you can use. If you specify a condition in your CAMLquery which always evaluates to true and specify a relationshipListSortColumn, the function will sort the values the way you want.

For my example above, I specify SortOrder as the relationshipListSortColumn, and set the CAMLQuery to give me all items where the Title does not equal an empty string. That will return all of the items, they will be sorted by SortOrder, and the dropdown will look just the way we want it to.

Recommendation Dropdown

Recommendation Dropdown

// If the Recommendation column exists, sort it as indicated in the source list
 relationshipWebURL: "/", // The source list for the Recommendation site Column is in the root site
 relationshipList: "Recommendations",
 relationshipListColumn: "Title",
 relationshipListSortColumn: "SortOrder",
 columnName: "Recommendation",
 CAMLQuery: "<Neq><FieldRef Name='Title' /><Value Type='Text'></Value></Neq>", // Get all values by specifying a non-blank Title
 debug: true // Debug mode on while we're developing

Filtering on a Value in a Multi-Select Lookup Column

A great way to manage the values for a Site Column in SharePoint is to put the values into a list and then use the Lookup column type to grab the values.  When you allow multiple selections in the lookup column, what is stored looks something like this: 


If you would like to then check in a DVWP to see if a value was selected, it’s not as simple as you’d like.  If your values are truly unique and cannot be nested (e.g., School and Schoolhouse both contain the string School), then you can use contains.  Otherwise, you’ll want to tighten things up a bit by doing some fancier matching.

The possible ways that we can have a match are:

  • The multi-select string matches the value exactly.  This is the case when there has been only one selection made, and it is the one that we want.
  • The multi-select string begins with our value followed by a semicolon (value1;)
  • The multi-select string has the target value in the middle, therefore surrounded by semicolons (;value2;)
  • The multi-select column contains the value at the end, preceded by a semi-colon (;value4)

To test for each of these conditions, you just need a little logic in your XSL.  Here’s an example that works when you want to see if MultiSelectColumn contains DesiredValue.

<xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row[
  @MultiSelectColumn= $DesiredValue or
  starts-with(@MultiSelectColumn, concat($DesiredValue, ';')) or
  contains(@MultiSelectColumn, concat(';', $DesiredValue, ';')) or
  substring(@MultiSelectColumn, string-length(@MultiSelectColumn) -
   string-length($DesiredValue), string-length($DesiredValue) + 1) =
   concat(';', $DesiredValue)

Depending how you will need to do the test, consider creating a template that you can pass the multi-select string and the desired value, passing back the results of the test.  You can store this template in a separate file and then use the template in many DVWPs by including it with xsl:import.

Technorati tags: , ,

Using the ID Value for a Lookup Column

Lookup columns in SharePoint can be very useful as a way to standardize input values.  One of the drawbacks of Lookup columns is that they violate the Rules of Data Normalization (see my previous post entitled “SharePoint Is Not a Database”).  Specifically, by storing the text value of the lookup rather than the ID, we violate Rule 1: Eliminate Repeating Groups – Make a separate table for each set of related attributes, and give each table a primary key.  While the key exists in the lookup location, the actual value is stored in the item and is generally what folks use in their Data View Web Parts (DVWPs).

There’s a useful post over at the Microsoft SharePoint Designer Team Blog by Greg Chan, Program Manager on the SharePoint Designer team, entitled SharePoint Conference – Building a SharePoint Designer Mashup (Part 1) that shows how to use the ID of the lookup value in DVWPs rather than the text so that you can at least try to play by the rules.  (The post is really about some demos that he did at a Seattle SharePoint Conference, but the trick is embedded in it.)

Lookup columns actually do store the ID of the lookup value (the stored value is of the form ID;#text, e.g., ‘4;#Supplier Name 4’ or ‘1;#Betty’s Golf Shack’), but the ID is normally not exposed.  By using the LookupId attribute in your CAML, you can get at the lookup ID.  You can read Greg’s post for the full details, but here are the key bits.

In your selectcommand (where the CAML is stored) in your DVWP, add the attribute/value pair “LookupId=’TRUE’”.  So, from Greg’s example, to get the Supplier’s ID rather than the text value, your selectcommand needs to change from this:

selectcommand="<View><Query><Where><Eq><FieldRef Name=&quot;Supplier&quot;/><Value Type=&quot;Text&quot;>{SupplierID}</Value></Eq></Where></Query></View>"

to this:

selectcommand="<View><Query><Where><Eq><FieldRef LookupId='TRUE' Name=&quot;Supplier&quot;/><Value Type=&quot;Text&quot;>{SupplierID}</Value></Eq></Where></Query></View>"