Wednesday, 15 February 2012

Its true Sharepoint DataForm Webparts are incredibly easy to develop if you need to query lists or data without the need to create fully grown webparts from scratch in SharePoint they are definitely the way to go. However there is a but and that is that most of the SharePoint Universe appears to believe that everyone creates DW webparts on their production environment using SharePoint Designer. In many production environments SharePoint Designer is disabled as default. If you have stand alone webparts this may not be an issue, but if you have a set of DataForm webparts that need to be linked to each other you're going to face all kinds of problems when you try to link them to each other on a target environment.

So for example lets say I have developed some webparts on my development SharePoint box. I access a list from my webparts, I have also had the sense to take the list from the production environment as a template so I won't have any conflicts with field names. All works fine my webparts talk to each other but then when I deploy them and try to get them to talk to each other they just refresh the page. Even if I've created connections between the webparts, what happened?

Enter what I feel is the Achilles heal of the DataForm Webpart. If you created those webparts in SharePoint Designer and created the webpart connection between them in there you probably didn't realise that it places a bit of code in there which looks something like this.

 

<xsl:value-of select="ddwrt:GenFireConnection(concat('g_cb4fe2eb_738d_4bbb_8ec7_ce81633092a5*',$fields),string(''))"></xsl:value-of>
 

The problem in the above bit of code, is that when you make a webpart connection in SharePoint Designer with DataForm Webparts it hard codes the GUID of the target webpart. When you deploy your webparts the target environment will give them different GUID's. Even if you try to re-establish the connections in SharePoint's Web Interface this won't make a difference at all.

If you are wondering what GenFireConnection does and I appreciate there is precious little documentation about it, most of it being on previous versions of SharePoint. Its creates an ASP.NET post back link which contains the consumer webpart  GUID (highlighted above) and the data we are sending to our consumer webpart such as the value of a field.

Work Around
The only work arounds I have found to this little problem, unless anyone else has a better method, is to.

  1. Create the link in the SharePoint web interface on the target environment after the webparts are deployed and placed on the page.
  2. Select "Edit Webpart" and use the XSL Editor to change the GUID on the "GenFireConnection" on the calling webpart  to the new GUID of the target webpart.

The other option is to just use query strings in your lists. SharePoint Designer will quite happily accommodate this using parameters you can then pass this around in links around fields.

The above seems to always work for me, although I would love to know if there is a more elegant solution to this.