Tuesday, 19 February 2008

Fix For Bug With CustomAction (with source code)

I recently overheard a colleague discussing an issue with using CustomAction elements to extend the UI in MOSS, details of his issue can be read here.


To sum up, if you define a CustomAction as part of a feature and use tokens in the URL e.g. <UrlAction Url="~site/Test.aspx?List={ListId}"/>, the custom action will work fine in a document library. However, if you add a web part representing the same document library to another page the tokens in the url do not get replaced. This is a very irratating bug.

The fix.
The only way I could see to fix this, was to replace the tokens using javascript. The menu options are available from the dom and the webpart also creates a context object in javascript to represent the displayed list.

The challenge.
To fix every occurance in a web app.

The idea.
Control Adapters. I simple idea but it presented a few difficulties to get this working in SharePoint.

The solution.
The SharePoint solution contains a WebApplication feature that when activated submits a JobDefinition to modify the compat.browser file already provisioned in the web app. The modification is a single control adapter entry to render all listviewwebparts using my control adapter.

The control adapter then allows the listviewwebpart to render as normal and then renders some javascript afterwards that fixes the rendered listviewwebpart.

Download the solution here seed.hf1.wsp. After installing and deploying the solution, run

stsadm -o activatefeature -name seed.hf1 -url <target url>

Download the source code here seed.hf1.zip

I am planning to blog in more detail about the techniques used in this solution, but I want to break them down into a small series of more detailed blogs. In the meantime, have a look through my source code and please leave any question or comments.