How to Customize SharePoint Forms - Part 2

In my previous post, I discussed various options available with developers/power-users to modify out-of-the-box SharePoint list forms, with a mix of client-side and server-side approaches. However, options available to end-users are limited very limited on UI.

In continuation of same series, I'd quickly introduce you to my preferred server-side approach which is not only a better implementation but is far usable by users of your SharePoint site, and is UI-based, without worrying about what's under the hood.

You can download provided release to readily use it against your SharePoint sites/lists. Here is an example of end result:

Form Customization Requirements

Some of the prime requirements are for custom Forms on UI are:

1. Modify out of the box Forms - New, Edit, and Display - to selectively choose fields that are available on each form.
2. On Edit form, from fields marked available, select some to be read-only. You want user to be able to see its value, but make it non-editable.
3. Do not unghost out-of-the-box forms for sake of form customization.
4. Be usable on both, Windows SharePoint Services v3.0 and SharePoint Server 2007.

Solution Approach - List Form Settings

Taking example of tips from my previous posts for using Rendering Templates to enhance default UI and controls, I've created new controls to intercept default Forms and set required form configuration on server-side before they are rendered to browser. I've also taken examples from some nice implementations on Codeplex by Bewise and DBedarf, and came up with something more usable to my preference and various enhancements.

Solution is to build a SharePoint Feature to provide a Application Page linked from List-Settings to edit the configuration of current list pertaining to various Form types. Save that configuration in RootFolder Property-Bag of current list. Override the Rendering Template for ListForm and CompositeField (FormSettings.ascx) to replace our custom controls so that we can intercept the rendering on the fly using the configuration we saved in property bag - selected by list administrator.

Following list types are enabled by Feature: Custom Lists, Announcements, Contacts, Issues, Events, Links, Tasks, and Project Tasks list.

Get Started with Form Settings

Download OfficeToolbox.SharePoint.Lists v1.0 from Codeplex or at SharePoint Toolbox at MSDN Code. Unzip the archive and run Setup.exe on your Server box where you want to install or try. Go to "Central Admin > Application Management > Manage Web Application Features" and activate the Feature.

Now go to your list settings of applicable lists on any site under the above web-application. Click "Form Settings".

From settings page, you can show/hide fields across New, Edit, and Display forms. For Edit form, you can also mark selected fields as read-only... should you want to stop your users from editing some information. You can also decide the location of field's description - next to field Label or next to control itself (default).

Having selected above, you get following Edit form... for example.

Above gives you significant control over specific fields on a form to better control the lifecycle of information of your lists, resulting in not on better quality of data (saving wrong edits) but better usability/adoption by being able to communicate that information isn't available for editing once created. (edit form: read only).

Advantages of server-side Form customizations

In my previous post in series, I suggested various approaches available to modify forms, either client-side or using SharePoint Designer. While the come with their limitations, server-side has various advantages.

1. Power to the users, no dependency on Developers - once implemented; better usability.
2. Server-side implementation comes with advantages of managed code, SharePoint feature (roll-back, scoping etc), central manageability etc.
3. No unghosting of forms, just in line with SharePoint APIs.

Speaking of disadvantages and future-scope, there are present limitations that there is no scope of forms/settings for individual SharePoint groups or audience. Flexibility of conditionally marking a field editable, while read-only by default. There can be various additional possibilities for enhancements, and I'm just hoping that we see far greater possibilities with forms in SharePoint 2009!!!

That's all for now, hope you find it useful. Do send in your suggestions for improvements.

source:weblogs.asp.net