Of course all our web parts always work, but just in case your web part comes in the situation that it has problems, you don’t want it to break down your complete page. It should handle those  problems gracefully.

Barry has some nice tips on writing well behaving web parts: http://www.barracuda.net/barrysblog.aspx?Date=10/22/2004

When you dive into web part development for SharePoint 2003 and need some reading on the topic, have at least a look at the following articles:

• 60 minute lab on web part development: http://www.sharepointcustomization.com/resources/tutorials/LAB%20DEV-2%20Creating%20Web%20Parts%20for%20SharePoint.doc
• Thomas Rizzo on web part development: http://www.sharepointcustomization.com/resources/whitepapers/Web%20Parts2003.pdf
• Best practices: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_sp2003_ta/html/ODC_WSSWebPartTips.asp
• Checklist for testing web parts: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_SP2003_ta/html/Office_SharePointWebPartsTestingChecklist.asp

And if you don’t wan’t to go the hard way… have a look at Smart Part, a generic web part that allows hosting of user controls. Have a look at Jan’s blog for more info: http://weblogs.asp.net/jan/

You never know which web parts end up in a SharePoint page. That is the power of web parts: combine them the way you see fit. But what if one web part accesses a web service that takes 3 seconds to complete, and another web part renders content from a database that takes 4 seconds…. If the web parts are not programmed with asynchronity in mind, you will end up with a rendering time of 7 seconds for your page, instead of just over 4 seconds as could be achieved when you follow “the rules”…

The SharePoint web part framework has great support for asynchronous actions in SharePoint, including support for timeouts on asynchronous actions.

For more information on this topic see:

• The SharePoint SDK documentation (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/smpxAsynchDataFetch_SV01031354.asp)
• An interesting article “Web Parts living together in Asynchronous City” on this topic at barracuda: http://barracuda.net/members/AsyncWebParts.doc. It is a pity that you have to logon to access the article at Barracuda, but you can create an account very easily. It is worth it, they have a lot of other interesting information.
• A supplemental chapter by Thomas Rizzo on web part development: http://www.sharepointcustomization.com/resources/whitepapers/Web%20Parts2003.pdf

We are doing extensive development for SharePoint Portal Server for one of our large customers. Besides producing a lot of interesting code, we are also settings up a kind of software factory for SharePoint development. More on this in later posts.

We now have the continuous integration builds and automatic deployments up and running. Units tests against the business code can be executed, and FxCop checks are done on the code.

The next step is automatically testing the deployment against a set of pages, where each page represents (part of) a use case. Are web parts functioning? Do they give the output you expect? Are skinning actions done by the MacawSharePointSkinner successful?

I’m currently looking into IeUnit. This looks like a very powerful web page testing framework, you run javascript tests that can directly talk against the DOM in IE, these tests can be executed from the command line, and the results can be output in an XML format that can be interpreted and merged by CruiseControl.Net (our Continuous Integration platform).

The test framework is extensible, so it would be great to extend it with the knowledge of zones, web parts, and other SharePoint specific functionality.

Did someone already go in this direction, or do you have other tips on testing the resulting web pages of SharePoint Portal Server? Please enlighten me!

The rumour circuit already mentioned support for SharePoint in SP2 (http://sqljunkies.com/WebLog/sqlbi/archive/2004/11/09/5018.aspx).

Found a presentation with some more details: http://202.181.238.4:5588/hk/technet/macau/06__WHAT_S_NEW_IN_SQL_SERVE.PPT

In te mean time we go with the Bryant Likes web parts!(http://blogs.sqlxml.org/bryantlikes)

In a project we are working with multiple developers AND a build server on a large set of Visual Studio solutions. Problem is that when we have references to a folder with shared assemblies, the relative path to those assemblies specified by a hintpath directive in the .csproj file ends up wrong. The solution file opens up on one system. but fails on another system (reference not found). We also have problems in our automated builds (using the NAnt solution task).

A fix to this is setting a registry entry to the folders with shared assemblies, if the assembly can't be found, this path is checked.

Add a key with any name to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\AssemblyFolders, and set its (Default) value of type REG_SZ to the path with your assemblies.

Sometimes SharePoint drives you mad. Case of today:

When you add a QuickLink to a person in SharePoint portal server you get a link to the /mysite/public.aspx page with on the URL in most cases an accountname parameter, so for example http://server/mysite/public.aspx?accountname=DOMAIN%5cusername. There are also situations where instead of an accountname parameter we got the parameter sid. No problem: convert the SID to accountname, done! Not. This SID is not a standard Windows SID. But the public.aspx page knows how to find the profile for this person... If you disassemble the (obfuscated) code that converts a sid to a usable profile object you see that a LOT of shit happens... to much to reproduce in your own code. But there is a dirty solution to retrieve any property from a user it's profile, while providing any of the following options on the URL:

accountname=....
guid=...
sid=...
preferredname=...

Make a page: GetProfileProperty.aspx

Call it like GetProfileProperty.aspx?accountname=domain\user

In the sample code the AccountName is returned, but you can use any property name, or even make the property itself a parameter.

In your code you have to execute a call to the page using the WebRequest class. The result is the property value in plain text.It is an extra roundtrip, but sometimes you don't have many alternatives...

THIS BLOG POST TURNED INTO AN MSDN ARTICLE. SEE http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_SP2003_ta/html/OfficeSharePointDDWRT.asp FOR THIS ARTICLE. BUT… ALSO CHECK THIS BLOG POST, IT CONTAINS SOME INFO CENSORED IN THE ARTICLE;-)

Summary

Topic: Data View web part, XSLT, XSLT Extension Object, ddwrt namespace, Windows SharePoint Services, SharePoint Portal Server 2003, FrontPage 2003

SharePoint has a powerful type of web parts: Data View web part (DVWP) that has the ability to provide an XSLT transformation on XML data retrieved from a data source. FrontPage 2003 has great support for defining the data source to retrieve XML data from, for WYSIWYG creating of XSLT views on this data, and for converting CAML list views (WSS list views) to XSLT.

In the XSLT generated by FrontPage an XSLT Extension Object is used to provide functions in the ddwrt namespace to perform often needed functionality like accessing properties of a list or firing events to connected web parts. This article tries to shed some light on these undocumented but much used functions.

Introduction

This is an article I started exactly one year ago, but never finished. I was using one of the most powerful features you get when using FrontPage in combination with Windows SharePoint Services (WSS) and Microsoft Office SharePoint Portal Server 2003 (SPS): the ability to create Data View web parts (DVWP). It is one year later, Christmas again, and in the meantime not much information appeared on the subject of this article: the functions available in the ddwrt namespace as used in the FrontPage generated Data View XSLT code.

Many introductory articles have already been written on the topic of DVWPs, so I will not repeat all this useful information. I consider those articles as prerequisite reading and will try to go from there by showing the available functions, and what they do.

Disclaimer: I’m on vacation and only have access to Reflector, the Microsoft.SharePoint.dll and Word, so no possibility to check out things. I have to rely on my notes taken in the past, and the disassembled code using Reflector. If you find any untruthful information or if you have any additional information: let me know and I will correct/include it in this article.

 FrontPage and DVWPs

One of the first things to mention is that although FrontPage is a great tool to create a DVWP, all the logic is already available in SharePoint (WSS) itself (see also http://weblogs.asp.net/soever/archive/2004/05/14/131698.aspx). This logic consists of the following parts:

• Microsoft.SharePoint.WebPartPages.DataViewWebPart, a class available in the Microsoft.SharePoint.dll assembly that implements the DVWP functionality.
• Microsoft.SharePoint.WebPartPages.DdwRuntime, an internal class available in the Microsoft.SharePoint.dll assembly that is made available as a XSLT Extension Object that provides a set of functions in the ddwrt namespace. The set of functions this article is about!!
• Data view web part definition, a .dwp file describing the assembly implementing the web part and the configuration parameters for the web part.

It is possible to create data DVWPs without using FrontPage. It is difficult, but it is possible. A DVWP is just a .dwp file which is an XML file that contains information for the data query and the XSLT transformation.

One thing FrontPage does really good is the conversion of a SharePoint list view (defined in Collaborative Aplication Markup Language, or CAML for short) to an XSLT transformation that transforms the data retrieved using the list web service to the same view as defined in CAML. In the past I wrote a weblog entry (http://weblogs.asp.net/soever/archive/2004/03/10/87295.aspx) about how FrontPage accomplishes this wizardry using an XSLT transformation that is available in your office directory.

Besides the CAML transformation, FrontPage provides WYSIWYG functionality to create a nice view on data. It does this by interactively defining an XSLT transformation on XML data retrieved from multiple types of data sources.

DataViewWebPart, Vars and the ddwrt namespace

It is the Data View web part implemented in the class Microsoft.SharePoint.WebPartPages.DataViewWebPart that utilizes the internal class Microsoft.SharePoint.WebPartPages.DdwRuntime to provide utility functions. John Janssen stated in a usenet discussion: “They were created to maintain parity between data views and list views (so that in the convert case the data view behaves just the same as the list view).” But the problem is that we want to give our own twist to how the result works, otherwise we didn’t have to convert them in the first place! The utility functions are made available by creating an XSLT Extension Object. To take a peek in the kitchen have a look at the obfuscated function Microsoft.SharePoint.WebPartPages.DataViewWebPart.q(). In this functions three important things happen:

1. The DdwRuntime class is added as an Extension Object
2. The Vars name-value collection as available in the XSLT transformation through ddwrt:Vars[“name”], filled with all kind of interesting information
3. A large set of XSLT parameters is defined.

The powerful thing of the Vars collection is that this collection is persisted over page request in the ASP.NET viewstate, so it can be used to persist information from the XSLT transformation of the current page request to the XSLT transformation of the next page request.

The Vars name-value pairs that I could find:

XSLT parameters I could find (no namespace):

If you look at the XSLT code generated by FrontPage you will find a large set of additional XSLT parameters. To have a look at the values of a lot of these parameters you could include the following XSLT code that writes out their values to the HTML code generated for the DVWP:

<!-- Dump parameters -->

PageUrl: <xsl:value-of select="$PageUrl"/><br/>

HttpHost: <xsl:value-of select="$HttpHost"/><br/>

List: <xsl:value-of select="$List"/><br/>

URL_Display: <xsl:value-of select="$URL_Display"/><br/>

HttpVDir: <xsl:value-of select="$HttpVDir"/><br/>

View: <xsl:value-of select="$View"/><br/>

FilterLink: <xsl:value-of select="$FilterLink"/><br/>

Language: <xsl:value-of select="$Language"/><br/>

dvt_adhocmode: <xsl:value-of select="$dvt_adhocmode"/><br/>

dvt_adhocfiltermode: <xsl:value-of select="$dvt_adhocfiltermode"/><br/>

dvt_fieldsort: <xsl:value-of select="$dvt_fieldsort"/><br/>

dvt_sortfield: <xsl:value-of select="$dvt_sortfield"/><br/>

dvt_groupfield: <xsl:value-of select="$dvt_groupfield"/><br/>

dvt_groupdisplay: <xsl:value-of select="$dvt_groupdisplay"/><br/>

dvt_sortdir: <xsl:value-of select="$dvt_sortdir"/><br/>

dvt_groupdir: <xsl:value-of select="$dvt_groupdir"/><br/>

dvt_filterfield: <xsl:value-of select="$dvt_filterfield"/><br/>

dvt_filterval: <xsl:value-of select="$dvt_filterval"/><br/>

dvt_filtertype: <xsl:value-of select="$dvt_filtertype"/><br/>

dvt_firstrow: <xsl:value-of select="$dvt_firstrow"/><br/>

dvt_p2plinkfields: <xsl:value-of select="$dvt_p2plinkfields"/><br/>

dvt_nextpagedata: <xsl:value-of select="$dvt_nextpagedata"/><br/>

dvt_grouptype: <xsl:value-of select="$dvt_grouptype"/><br/>

dvt_sorttype: <xsl:value-of select="$dvt_sorttype"/><br/>

dvt_groupsorttype: <xsl:value-of select="$dvt_groupsorttype"/><br/>

dvt_apos: <xsl:value-of select="$dvt_apos"/><br/>

filterParam: <xsl:value-of select="$filterParam"/><br/>

ImagesPath: <xsl:value-of select="$ImagesPath"/><br/>

ListUrlDir: <xsl:value-of select="$ListUrlDir"/><br/>

EMail: <xsl:value-of select="$EMail"/><br/>

ListUrlDir_TRUE: <xsl:value-of select="$ListUrlDir_TRUE"/><br/>

URL_DISPLAY: <xsl:value-of select="$URL_DISPLAY"/><br/>

URL_EDIT: <xsl:value-of select="$URL_EDIT"/><br/>

URL_New: <xsl:value-of select="$URL_New"/><br/>

WebQueryInfo: <xsl:value-of select="$WebQueryInfo"/><br/>

URL_Edit: <xsl:value-of select="$URL_Edit"/><br/>

URL_Lookup: <xsl:value-of select="$URL_Lookup"/><br/>

<!-- Dump parameters -->

The ddwrt namespace, a reference

And now we come to the meat of this article. A reference guide to the set of functions implemented in the ddwrt namespace. Have a look at the XSLT code generated by FrontPage, and you know what I’m talking about: those functions starting with ddwrt:.

What follows is an overview of all public functions in the internal class DdwRuntime that is automatically available in the XSLT code in a DVWP.

Nothing really interesting is happening here, and you don’t call the constructor yourself. This function is automatically called on instantiating the DdwRuntime class as an XSLT Extesion Object. Don’t bother about it.

This function returns the passed szStr string parameter. The preserveWhiteSpace parameter is ignored.

This function goes through the string szStr and does the following replacements:

So the function converts a plain text string containing special characters (in the HTML sense) and newlines to a string that can be inserted into HTML and remains formatted in the same way.

This function goes through the string szData and does the following replacements:

So the function converts a string to a format that can be passed as a parameter in the URL string. If you look at the name of the function, this function is used to encode the connection information that is communicated between connected web parts. Web part connection information is probably encoded because connection information between web parts on separate web part pages are passed on the URL. Creating web part connections between web parts on different web part pages is not available through the web interface for defining web part connections, but FrontPage 2003 does provide functionality to make web part connections between web parts on different pages.

The Counter() function returns an incremental number. The number even increases over pages refreshes so you are ensured of a new number on each call, even over page requests.

If the parameter szFieldName equals the name of the currently selected filter field (assumable the internal name of the field), this function returns the text /_layouts/images/filter.gif , otherwise it returns the text /_layouts/images/blank.gif.

public string FieldFilterOptions(string szName);
This function always returns an empty string.

This function always returns the text urn:schemas-microsoft-com:office:office#, this is the namespace used for all fields defined in for example a SharePoint list.

If the parameter szName equals Desc,  the text /_layouts/images/rsort.gif is returned, otherwise the text /_layouts/images/sort.gif is returned,

This function always returns an empty string.

This function always returns an empty string.

The parameter szDate is converted to a DateTime. Based on the formatFlag parameter which can have a value from 0..15, a new DateTime string is constructed in the given locale lcid. This result is returned by the function.