If you want to customise the default forms that come with SharePoint lists (DispForm.aspx, EditForm.aspx, NewForm.aspx) then you should deploy the list as a feature so you can modify the actual file in the 12 hive instead of the unghosted version in the database. This saves you reconfiguring the list in every environment you deploy to which is fantastic for a Dev –> UAT –> Production transition.

Preamble:

SharePoint features are great for many reasons I won’t go into here  but one that i will.

Most people are already using the SharePoint solution deployment approach but if you’re one of the unconverted, there’s plenty of information out there in google land on how Solutions + WSPBuilder + Powershell = Win.

Setting the Scene:

I recently had to develop a custom SharePoint list. The project structure consisted of:

• List template Feature
• Content Type Feature
• Content Type association feature (to join the dots). [Note 1 – if you’re already lost then see Andrew Connell’s blogs on feature deployment]

What i wanted to do then was to change the list ‘EditForm.aspx’ and ‘NewForm.aspx’ to be completely custom. So I fired up SharePoint designer and added a DataView webpart.

[Note 2 – there’s many ways to make a hash of this – the way that i find works is this one: http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/06873fe5-19a9-4b32-91a9-31164afdd4bb – i.e. don't delete the ListView webpart, just hide it]

So now i can implement my custom forms in any way i like and add in all kinds of extra functionality. That’s a blog post for another time though.

The issue:

As the form is now unghosted (i.e. it has been customised from the list definition [filesystem] so it exists in the database), all form changes need to be done in SharePoint Designer and will have to be repeated every time you redeploy the list.

There’s other reasons why you shouldn’t unghost pages – performance (not precompiled), potential upgrade problems, etc..

Is using SPD in each environment so bad?

It’s not terrible, it just takes a lot longer, is easier to make a mess of and I don’t like the SPD development environment either. i just find it slow and annoying. After all, it is doing round trips to the database every time you call or save a page. And it often attempts to nanny you by ‘cleaning up’ your HTML behind the scenes. The most obvious example of this is the removal of the ‘~’ character in relative URLs as it attempts to resolve these as absolute.

So I’d rather work in a proper code editor environment and have my changes directly applied.

The Solution:

As you’ve probably worked out by now, it’s by making sure your pages never get unghosted.

The key to this is to deploy your list feature as normal, but make changes to the EditForm.aspx directly in the list definition feature in the 12 hive.

How to do this is to use SPD on your dev environment, get the page exactly how you want it and then go deploy the feature.

As SharePoint feature GUIDs are non-deterministic (sigh) the instance of the list you create will have a random GUID which you won’t know at this point. It simple become a cut and paste exercise to get the new list GUID and insert it in your EditForm to replace the existing one.

The easiest way to get the list GUID is:

Site Actions –> Site Settings –> Audience Targetting Settings

The URL will now show you the list GUID in a non-html encoded format:

And voila! You can now deploy this list to any environment as many times as you like and the only manual work is to replace the GUID once the list instance has been created! 2 words – AweSome.