SharePoint Developer Orientation – Part 4: Advanced Customization with Designer

Learn how to use SharePoint Designer to declaratively develop advanced customizations.
Page Content


2011-07-17-SPDevOrientation-Part01-01.jpgSharePoint Designer is your friend

Now that you are generally familiar with SharePoint from a user’s perspective, it’s time for advanced customizations with SharePoint Designer. This tool is for customizing specific SharePoint sites and adds a lot of functionality over the Web UI (workflows, form customizations, Business Connectivity Services, etc.). It is a powerful and useful tool, even if buggy, prone to crashes, and slow.

The goal of any SharePoint project is to leverage the use of the platform, deliver value rapidly, and enhance the user’s capabilities to serve their business needs. Depending on the type of project you are working on, Designer can be your destination or your vehicle. If this is a single-site customization project, for example, try to stop at the web UI and Designer. If this is a professional solution with complex implementation, deployment, or maintenance requirements, you will still use Designer regularly. Oftentimes, it is the only way to learn how something works, or at least the best way to get started. You will then import your customizations into a Visual Studio solution to package them up, and deploy them, and likely add code (web parts, workflow activities, event receivers, etc.).

Customizing list views and forms

One of the most common and likely customizations you will come across is customizing list views and forms. In the web UI, you can customize a view by showing or hiding columns, adding filters, sorting, grouping, and that sort of thing. You cannot, however, touch how the list data are rendered. Each field will display the same way every time depending on its type. The headers, the hover effects, and all the elements of that list are predetermined. SharePoint Designer gives you the tools to go deeper.

SharePoint uses an XSLT rendering method that applies the XSL Transformations to the results of a query to render a list view or form (display, edit, or new). The actual transformation happens early in the page lifecycle during page initialization, allowing the use of ASP.NET server control declarations in the XSL. You will see the <SharePoint:FormField … /> control in new and edit forms, for example, that renders the complex controls for editing data depending on the field type. Also, SharePoint provides added functionality by importing some xml namespaces for use in your XSL markup. So, when customizing a view or form, you have the power of XSLT to work with, plus the SharePoint ddwrt namespace, plus the use of ASP.NET and SharePoint server controls.

To get started, check out this great SharePoint Designer resource from Microsoft. The Data Views and Forms link has a wealth of information on how to use the tool to customize views and forms using Designer. Each article has a See Also section near the top of the right margin with related articles. Some notable examples:

    • Example 1: Create a custom list view Just to give you an idea, here is an example from a recent sample project I worked on. Here I used HTML (added div elements and the like to the XSL), jQueryUI and CSS to translate numeric or text values into meaningful visualizations:





    • Example 2: Create a custom list form Once again, example screenshots to spur the imagination. Here I formatted the fields as Text Boxes instead of SharePoint FormField using the Design view. I then switched to Source view and added jQueryUI sliders and synced them with the textbox. To add more sizzle, I swapped out CSS classes for the slider depending on ranges I chose. Green for 0 – 0.35, etc.





Before we move on, I have to mention Marc Anderson, one of the most active members of the SharePoint community serving “the middle tier”. Call it what you will, this advanced customization, declarative programming, or middle tier development that I described above is very powerful. Check out his blog, and the SPServices jQuery library.

Designer workflows

You can create workflows to help automate business processes using the many OOTB workflow actions and pre-canned workflows, like approval and signature collection. Workflows open the door to processing data that you don’t have in the web UI. A workflow is just code that runs on the server with inputs, outputs, access to variables, etc. This is Workflow Foundation under the covers. So using the existing workflow actions, you can process data in new ways. For example, since some fields aren’t accessible in a Calculated column (like ID or lookup fields), you can use a workflow as a replacement. The workflow is scheduled to run asynchronously in a timer job after the list item is created with no guarantee of when it will run, so it may not be ideal in all situations. Any workflow-modified fields will not be immediately available to the user and could take a few minutes to update.

You cannot create new actions or write new workflow code in Designer, but you can augment your toolbox. Here is a great opportunity to gradually scale up your project. If you find you cannot accomplish something with a Designer workflow, you can find open source components (check and third party products (from activities to advanced workflow design software). Failing that, as a developer, you will certainly be able to write your own as well. It goes against our instinct as developers, doesn’t it? If Designer workflows are too limited, we want to pull it into Visual Studio and use the full power of Workflow Foundation. We don’t want to use some contrived designer to perform actions that would take only a line or two of crisp, clean code. Remember… the point is to deliver low-cost, low-complexity solutions. Purchasing a workflow action is cheaper, more reusable, and easier than custom code. Of course, when warranted, there is nothing better than custom code, but think reusability. Write a custom action to get over a hump before writing a completely custom Visual Studio workflow.

What else?

A few other important capabilities to be aware of are:

  • InfoPath: If you are using SharePoint Server, you also have access to InfoPath forms for form customization. InfoPath includes a rules engine, validation, more form layouts, and controls, and the ability to write code within the form.
  • Business Connectivity Services: BCS allows you to integrate external data and functionality into your SharePoint 2010 environment. This great article by Kirk Evans describes what BCS is, how to use it, and even proper scenarios for custom development beyond Designer.
  • Honorable Mention: Well, as this post fizzles out, I’ll mention that Designer has other capabilities that you can explore on your own. Editing pages, editing master pages, and site/sub-site creation all get an honorable mention.

In conclusion, I hope you see that an awful lot can be done in SharePoint using the web UI and Designer. Even if you remain strictly a custom coder, there is a place for you in this ecosystem. Everything we have covered so far can be extended with custom components. It is important to understand how this all works, what the capabilities are, and where your hooks are to develop most efficiently. But for the developers who are interested in building complete business solutions on SharePoint, you have to have an open mind. Even if you are working in Visual Studio, you will author many of your customizations in the web and Designer before importing them into your project. You will play a sort of dual role as a power user and developer, but that comes with the greatest combination of capabilities.