Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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.
share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

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.

share|improve this answer
    
I didn't mentioned Infopath because it's a bit of pain of packaging. Even if I agree it's very easy to customize forms with it. A question about the OOB webparts like XsltWP and/or DFWP: does it allows to defines complex rules, like membership of group? In fact, some parts will have to be shows only for some users... –  Steve B Jun 12 '12 at 15:10
    
Steve, if you need security, I'd recommend you to use native SharePoint permissions. Just limit some lists or list items for people with correct permissions. Both DFWP and XsltListViewWebPart respect native permissions, of course, so the data shown will be trimmed appropriately. Any other option will be insecure: i.e. I can easily retrieve items from any list using JavaScript Object Model. –  Andrey Markeev Jun 12 '12 at 15:15
    
Also, both DFWP and XsltListViewWebPart definitely allow you query lists. So you can use CAML <Membership> tag (msdn.microsoft.com/en-us/library/aa544234.aspx) in conjunction with <UserID /> tag and any other combinations. –  Andrey Markeev Jun 12 '12 at 15:20
    
The security does not concern the content of the item, but the possible actions on the item. And for obscure business requirements, I cannot use custom actions, but only custom ui. Actually, I have some basic C# rules in a visual web part that publish some boolean properties, and markup like <% if(MyBool) { %> <sharepoint:button /> <% } %> –  Steve B Jun 12 '12 at 15:23
    
Place your custom actions in custom webparts, as I proposed in the answer. In this case you'll be able define any rules you wish. XLV and DFWP are only for bringing related information (#3 in your requirement list) –  Andrey Markeev Jun 12 '12 at 15:27
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.