Data View Web Part: Add an Edit Properties Link which Returns to the Link Source

The Data View Web Part is a great component to use to create user interface elements in SharePoint as an alternative to the Document Library / List UI. But you still want to give users access to the relevant List Forms; Add, Edit, Display.  

This is easy enough to do by creating a link to the form required, for example the edit properties form as shown:

      <a href='http://server/site/Document Library/forms/EditFom.aspx?ID=1'>Edit Properties</a>

However when clicking OK or Cancel on the List Form, by default you are redirected to the parent list or document library. In order to be redirected to another location after clicking OK or Cancel you can make use of the “source” query string parameter. Essentially you provide the redirect location URL as the source query string parameter in the URL of the List Form. This is well documented and many SharePoint forms accept this parameter. 

Now, back to our Data View Web Part, to create our link to the edit properties form for an item and have it return to the page with the DVWP instance on it we need to create an image link to the correct form URL and append to it the URL of the current page. 

The snippet below will do just that;

   <span style="cursor:pointer; padding-right:8px;"
              onclick="javascript:window.location='/{@FileDirRef}/Forms/EditForm.aspx?ID={@ID}&amp;source='+window.location">
   <img src="/_layouts/images/edititem.gif" alt="edit properties" align="absmiddle" /></span>

The snippet creates a span with an OnClick handler and embedded image. The OnClick handler navigates to the URL created from;

1. @FileDirRef - the server relative path to the (document library in this case) item
2. The edit properties form (/forms/EditForm.aspx)
3. The ID query parameter supplying the ID of the item using the @ID field
4. The source query parameter using the current location supplied by window.location.

DVWP with Link to Edit Properties

Maxime Bombardier – SharePoint Architecture & Development : Deployment lifecycle when using Site Definitions and Features (including post production day)

Maxime Bombardier – SharePoint Architecture & Development : Deployment lifecycle when using Site Definitions and Features (including post production day).

Marco André Silva : SharePoint Associating a Workflow to a list

Programmatically associating a Workflow with a given configuration (Workflow association data) with a List or Document Library.

Marco André Silva : SharePoint Associating a Workflow to a list.

Todd Baginski’s SharePoint 2003 and MOSS 2007 Blog » Adding a Document Library Feature to a Site Definition in WSS V3 / MOSS 2007

Todd Baginski’s SharePoint 2003 and MOSS 2007 Blog » Adding a Document Library Feature to a Site Definition in WSS V3 / MOSS 2007.

SharePoint: Content Query Web Part Customizing the Query

Recently I’ve been customizing Content Query Web Parts (CQWP) whereby I override the query and supply my own CAML query. The basic steps involved in doing this are;

1. Author the Web Part using the UI
2. Export the Web Part using the UI
3. Customize the Web Part .webpart file
4. Import the customized Web Part back into SharePoint

Some of these Web Parts were configured to query by Content Type, such that the Web Part property “ContentTypeName” is given a specific value as shown below;

    <property name="ContentTypeName" type="string">Period View Item</property>

Prior to customizing the CQWP query with CAML, such a Web Part worked fine. So having exported the Web Part I provided a custom CAML query using the “QueryOverride” property;

  <property name="QueryOverride" type="string"><![CDATA[<Where>...</Where>]]></property>

After importing the Web Part back into SharePoint I noticed that it would return results for other Content Types also. To work around the problem I modified the CAML query to restrict the results to the Content Type in question, like so;

  <Where><And><And><Eq><FieldRef Name="ContentType" /><Value Type="Choice">Period View Item</Value></Eq>......</And></And></Where>

I suspect this is by design rather than a bug, however the CQWP documentation indicates that the query by Content Type feature is a filter rather than part of the query, as this article aludes to.