Tuesday, December 9, 2008

MOSS Cascading DropDownLists - The Sexy Approach - 1 of 2

Disclaimer: I recommend reviewing any/all code (including content that is linked to) and fully understanding what it does before deploying anything to your staging, test, and/or production environments. There is nothing worse than deploying code/solutions which cause critical errors that you don't know how to fix.

Link to next post: MOSS Cascading DropDownLists - The Sexy Approach - 2 of 2

I am really excited about this post for a number of reasons:
  • AJAX makes things look really slick
  • Cascading DropDownLists in SharePoint are a pain
  • I've finally finished this project!
The task at hand was to implement Cascading DropDownLists within a standard SharePoint list (no InfoPath). Some resources that were immensely helpful while constructing this are as follows.
Regarding Custom Field Controls and Cascading DropDownLists:
Regarding AJAX integration with SharePoint:
The project consists of two solutions, one which configures the web.config with modifications to allow ASP.NET AJAX, and one which deploys an AJAX Cascading DropDownList custom field control. This post will cover the integration with AJAX. My next post will cover the custom field control.

These are links to the four files (Feature.xml, manifest.xml, wsp_structure.ddf, AjaxControlToolkitSupportInstaller.cs) which are necessary for the solution which enables AJAX on your web application. I have decided to host the files within my GoogleDocs account because I like color coded files, there is too much code to paste it into this blog window, and I don't feel like creating a CodePlex project to upload, maintain, track bugs, and such.

If you are familiar at all with SharePoint Solution deployment, you will be right at home with manifest.xml and wsp_structure.ddf. I did not use any 3rd party tools for solution deployment. I used a simple C# class library with some custom batch files for processing the wsp_structure.ddf.

Please note:  You *must* create two GUIDS: one for the solution, and one for the feature. Also, be sure to create your assembly with a strong name, and insert your PublicKeyToken into the Feature.xml file.

I took bits and pieces from both Rich Finn's CodePlex project and Mike Ammerlaan's blog to create this feature. However, I really liked the way that Ted Pattison implemented a SPWebConfigModification feature in his post Using a Web Application Feature to Modify web.config, so instead of Ajaxify MOSS's command line approach, this is entirely browser based, and activated/deactivated within Central Administration on the "Web Application Features" page. Speaking from experience, be sure you have the correct web application selected before you activate the feature.

Part 2 to be coming shortly.


1 comment:

  1. Looks promising. ;-)
    What about a "happy new year post" with the second part?