Heavy customization of DispForm.aspx

Question

I'm building a quite complex application that have a lot of custom UI requirement, especially when displaying one item. The item show parts of it only when specific rules are met (mostly related to the user's group membership), related items (some lookups), etC.

What are the options for such customization? What are pro and cons of each methods ?

By now, I can see this options :

• create a custom application page with an ID in the query string, and build the UI using traditional ASP.Net techniques
  • Pros: easy to create and deploy
  • cons: quite static, not customizable by the users
• create a bunch of web parts, and add them to the OOB dispform.Aspx
  • Pros: not so hard to deploy
  • Cons: same as an application page, but within the webpart (still have to build the UI manually)
• create control templates for the list form
  • Pros: looks like the blessed way to do such things
  • cons: hard to construct, as it require a lot of nested controls
• use xsl (I'm a newbie in this way)
  • pros: can be build with SPD before importing into VS
  • cons: xsl can be a bit of pain

I'd appreciate your feedback about your own experience.

To be more precise about my requirement, here is a list of things my page must show :

• the details of my item (main fields)
• one tab for each kind of action possible on the item. each tab have its own set of controls, and buttons (jQueryUI is my friend)
• several "related" information, that are stored in other lists, with lookups. This views have custom formatting when some rules applied.

Answer 1

From the approaches you mentioned, I'd prefer webparts approach.

WebParts can be connected with each other using SharePoint Connections.

Using OOTB XsltListFormWebPart-s or DataFormWebPart-s for bringing related lists to the form, you can connect them to your ListFormWebPart which displays fields. You can do it using SPD or browser. No coding at all.

With XsltListViewWebPart or DFWP you can customize the appearance of the pulled data using XSLT (if it is necessary). DFWP can use not only data stored in lists as a datasource, but also web services, xml files, etc. Also it can aggregate data from different datasources. Finally, DFWP allows fully custom datasources...

After configuration is done, copy the page markup and deploy it (or also you can deploy all the webpart and connections programmatically) - and half of your requirements are fulfilled.

What about actions, I'd recommend at least to consider creating Ribbon tabs. Ribbon has some limitations, but this is the most "SharePoint" way, so it will settle into a SharePoint form in the most smooth way.

If it is not acceptable, then create custom webpart, implement support for connections, and arrange deployment the same way you've done it for other webparts. You even can create several similar webparts and use something like EasyTabs by Christophe (active member here) to organize webparts into tabs.

Webparts can be configured and rearranged on the page by a business user, which is very convenient. Several years ago I've created a solution based on the same idea, and it worked perfectly well.

And yes, this approach generally will work in Sandbox and Office365.

Please, don't hesitate to ask any additional questions: I'm ready to elaborate my answer with links to appropriate samples, etc.

Btw, you haven't mentioned at least two popular approaches of list form customization:

1. InfoPath forms
2. Content Editor WebPart with some JavaScript

InfoPath

Using InfoPath forms is the most rightful approach in this case. I believe it is intended for any complex form customizations by MS.

It is possible to divide fields in tabs, and many-many other things, with InfoPath. InfoPath produces pretty Ajax forms. Also, InfoPath is an Office application and so it could be used by business users, which is very convenient in some cases.

However, there are some cons too: there are some inconveniences, and sometimes InfoPath renders incorrect markup. And also consider your license, of course.

Pure JS/jQuery

Pure JavaScript approach is fragile and slow. Most often you have to bind your customizations to a field title, so if field title changes - your solution is broken. It is possible to retrieve current field title by it's InternalName, but it will require some time to perform the query, and you have to do it every time the customized page loads. Also, some problems with on-fly localization are to be apprehended.

However, JS approach works in Sandbox (i.e. in Office365 too, including the most cheap plans), and it is easy to implement.

There are several libraries which can simplify customizations of SharePoint forms using JS. For example, SPServices by Marc D Anderson and SPUtility.js by Kit Menke - both active members here.