One of the clients I work with has a policy of not allowing any custom code. This is because the SharePoint environment is shared by 40,000 users and poorly designed code could cause serious performance issues - understandable, but no less inconvenient. Working within this environment I have had to come up with some workarounds to create the functionality users are asking for.

One of these workarounds is in making use of the dataview webpart. Most documentation tells you to create these using SharePoint Designer. I don't like that approach due to the fact that it is quite easy to break your site with SPD. Central IT is comfortable with that risk, since you can only break one site at a time - 99% of their users are unaffected, but I don't want to break the site that supports 100% of my users.

Fortunately, you can do quite a lot with the dataview web part using just the browser interface. You do need designer to create your first dataview, but you only need to do that once - you can change almost

anything later through the browser.

Creating the initial dataview can be done on a virtual machine, so there is no risk of breaking anything (and development is easier when you don't have to deal with the VPN). In SharePoint Designer, create a dataview on any list and convert it to xsl. Don't make any changes before the conversion, as the conversion doesn't always work that well.

To make the dataview configurable you will need to make some minor changes to the parameters it takes. By default the dataview is associated with a list using a guid which will not work on another site.

<SelectParameters><asp:Parameter DefaultValue="{9B7A603A-466F-474B-9509-BB8423823525}" Name="ListID"></asp:Parameter>

</SelectParameters>

This needs to be changed to

<SelectParameters><WebPartPages:DataFormParameter Name="ListName" ParameterKey="ListName" PropertyName="ParameterValues" />

</SelectParameters>

In the browser, use export from the web part menu to produce a web part file that can be added to the web part gallery of the real site. You now have a dataview web part that can be added to a page without

having to use SharePoint Designer.

Although the web part definition does have a list of included columns that will only match the list it was originally created for, they appear to be ignored when you connect it to another list. That means you have complete control of the dataview using the parameters and xsl available on the tool pane.

First the parameters. This is where you point the web part to a specific list by changing the default value to match the list name. You can also add additional parameters such as the username. However, it is worth noting that only the parameters included in SelectParameters will affect the query - additional parameters will simply be available in the XSL. The ServerVariable location setting can be quite useful here.

Next is the XSL. This is fairly standard. The default XSL from designer gives you a loop over all items in the list, and within that you can display the values of whichever columns you want by using <xsl:value-of

select="@ColumnName" /> or <element attribute="{@ColumnName}" /> if you need to set an attribute of an html element. Note that whatever html you include has to be well formed XHTML to prevent errors.

The column name used in the xsl is the internal name of the column. The easiest way to find this when it is not obvious (such as for names containing spaces or columns that have been renamed) is to edit the

column in list settings and look at the end of the query string. Parameter values are declared at the top of the xsl using xsl:param and can be displayed using {$ParameterName}.

Although just displaying the content is usually enough, you can also make use of any of the more advanced features available in standard xsl such as sorting.

When setting up the XSL, I usually use the XSL property on the tool pane, copying and pasting to visual studio so I get syntax highlighting etc when editing.

If you want to be able to reuse the web part in multiple places, you will want to use XSL Link instead. Save the xsl file in a library somewhere (I usually use the style library of the parent site) and set the XSL Link property to the url of that file. That way you can change the xsl in just one place and not need to update the individual web parts.

The parameters (and the xsl link url) do need to be set for individual web parts though - if you are creating a lot of similar web parts you should get those settings right first and export/import the web part so that those settings are used when it is added to the page.