Extending the Content Query web part

Something I've been meaning to put on Codeplex for a few weeks now is an extended version of the Content Query web part. This particular web part is one which many SharePoint developers will use quite often for displaying lists of links etc. However, anybody who's ever worked with it will probably tell you they spent a good hour (or more) on the first time, wondering how the hell to get the control to display either:

• custom columns on their list
• custom columns on the content type that the page layout uses (in WCM scenarios)

Since this doesn't happen automatically, it becomes apparent you have to tell the control the names of your custom fields. You might expect this to be exposed (like many other things are) by the control properties, but unfortunately it's not that simple. There is a property (CommonViewFields), but the tool part doesn't provide a UI to enter a value. This means that the value can only be supplied by digging a little deeper and changing the definition of the CQWP using it's .webpart file.

This involves exporting the web part from a page which uses it, amending the CommonViewFields element in the XML, then re-importing the .webpart file to the Web Part gallery. This new definition can then be added to your page, and you'll then get the right results.

Hmm. Why is it not a property on the control again?!

So this was the extension I was going to implement. As it goes, Ishai Sagi has beat me to it and is supplying additional functionality to boot. The shot below shows that now all you have to do is enter your field names into the tool part:

Ishai writes about this at http://www.sharepoint-tips.com/2007/06/adding-custom-fields-to-enhanced.html. His 'Extended Content Query web part' can be downloaded from http://www.codeplex.com/ECQWP.

Definitely worth a look if you use CQWP regularly.

UK SharePoint user group - Customizing SharePoint the supported way

The UK SharePoint user group is meeting this Thursday (28th June) at the Microsoft campus in Reading. There are two sessions, one of which I'm presenting:

Customizing MOSS the supported way – from end-user to admin interfaces

One of the key concepts SharePoint developers should be aware of is that modifications to core shipped files are typically unsupported. This session looks at ways in which you can implement the kind of customizations your users may ask for, but without modifying the original files. Aspects covered include custom site definitions, modifying the site administration/central administration areas, and changing the user controls SharePoint uses with the DelegateControl architecture. The session is packed with demos, and also contains some quick tips on the best way to make other common customizations not shown in the detailed examples.

Speaker: Chris O'Brien

..and also:

Groove: A powerful tool for collaboration, that is now part of Office 07.

In this session, we review the basic functionality and then show, using the latest Microsoft templates (including issue tracking and document review), how Groove is not just a tool but a platform for delivering functionality. We'll also look at how Groove and SharePoint can both effectively work together.

Speaker: TBA

If you're in the area and would like to register, simply leave your name on the following thread over at the UK user group site:

http://suguk.org/forums/thread/3534.aspx

I'll be posting my slides and sample code after the event. The content on customizing the site admin/central admin areas will probably make it's way into separate posts for clarity.

Using the Delegate Control

When starting to build MOSS sites, many developers will start the page template development process by analyzing the shipped master pages and/or using the 'How to create a minimal master page' MSDN article. Whilst very useful, for simplicity the example in the article unfortunately does not include some of the functionality the SharePoint team implemented in default.master, specifically the use of the Delegate Control for the page to load controls. I think this is a shame, since many developers who don't take the time to specifically look at it may therefore be unaware of how powerful the Delegate Control can be.

So what is it?

Essentially the Delegate Control provides an alternative to adding user controls and server controls to a .aspx page in the normal way. By this, I mean adding the control to the page by dragging from the toolbox in the development environment or by adding the appropriate markup manually. Instead, with a Delegate Control all we do is add the markup to instantiate a Delegate Control instance, and use a Feature to specify separately which control should actually be loaded. What this effectively gives us is the ability to control what controls are used on a page without having to directly modify and redeploy master pages/page layouts. This extra level of abstraction can be quite powerful, since any feature scope can be used with the Delegate Control. I'll come back to this, but enough theory for now. Here's how it's used:

First off, we need a Delegate Control declaration on our page. This will look something like:

<SharePoint:DelegateControl runat="server" ControlId="PageHeader">

</SharePoint:DelegateControl>

Only thing to note here at this stage is the ControlId attribute - the Feature we create will use this to substitute the real user/server control.

Then we have the feature.xml file, where we specify the feature details (including scope):

<Feature xmlns="http://schemas.microsoft.com/sharepoint/" Id="373042ED-718D-46e2-9596-50379DA4D522"

Title="COB.Demos.DelegateControls"

Description="Specifies which user control should be used for the 'PageHeader' DelegateControl used on the site master page. The replacement user control is stored in the CONTROLTEMPLATES directory." Scope="Farm"

Hidden="FALSE"

Version="1.0.0.0">

<ElementManifests>

<ElementManifest Location="elements.xml"/>

</ElementManifests>

</Feature>

As always, the 'instructions' for the feature are in the element manifest:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

<!-- using a sequence number LOWER than default of 100 so our custom control gets loaded -->

<Control Id="PageHeader" Sequence="90" ControlSrc="~/_ControlTemplates/COBPageHeader.ascx" />

</Elements>

This is where we specify which control should actually be used. In addition to specifying the path, the key thing is that the 'Sequence' attribute contains a value lower than any other <Control> instructions for this control (i.e. ID of 'PageHeader'). This is especially important when we are overriding an existing Delegate Control created by Microsoft - here the default value is 100 so your sequence must be lower than this for your control to be loaded instead.

In addition to creating and activating this feature, the actual .ascx file must exist in the location specified. It can be copied to the CONTROLTEMPLATES directory manually, but a better idea is to wrap the feature up as a solution, since solution packages can also deploy files. To deploy the .ascx file along with the solution, your solution manifest file should look something like:

<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="E8694626-60F8-4d07-9140-8F9F634020DE">

<FeatureManifests>

<!-- note this is the location in the cab file! -->

<FeatureManifest Location="COB.Demos.DelegateControls\feature.xml" />

</FeatureManifests>

<TemplateFiles>

<TemplateFile Location="CONTROLTEMPLATES\COBPageHeader.ascx" />

</TemplateFiles>

</Solution>

These files would now all be packaged as a solution (.wsp) in the usual way with makecab.exe. When the solution is deployed, the file will be copied to the right place on all the web front-ends in your farm, and when the feature is activated SharePoint will know that it should henceforth load 'COBPageHeader.ascx' for any Delegate Control with an ID of 'PageHeader'.

So what's so great about that?

Well, a couple of things:-

• I can now override which control a page should load without having to go back, edit the template and redeploy
• By using a feature scoped at 'Web', I can effectively use a different page header for different areas of my site without requiring different templates or code. (Note I've not tested this extensively, but since the <Control> element can be used at scope Web, Site, WebApplication or Farm, this should be perfectly feasible.)
• I can use any standard .Net user control or server control, so for anybody familiar with Jan Tielen's SmartPart, this provides similar capability.

In terms of functionality, there's a couple of other things I want to highlight:

• Parameters can be passed to the control via the declaration on the page. To read these, the control's implementation should walk up the control tree to get the values. An example would be:
  

<SharePoint:DelegateControl runat="server"

ControlId="PageHeader" MyParam="MyValue">

</SharePoint:DelegateControl>

• By adding AllowMutiple="true" to the declaration, you can make the Delegate Control load more than one user/server control.
• As mentioned earlier, many of the controls used on default.master are loaded using the Delegate Control. These include global links such as My Site/My Links and the publishing console. So using this approach, customizing the publishing console is a simple matter of providing a replacement .ascx and creating a feature as described here!

Hopefully this has given some insight as to why you should consider using it on your templates. As a final thought, how about combining with a web part so that you can simply re-use existing ASP.Net user/server controls as web parts?

It's 6pm - where are your virtual machines?

I mentioned last time that I'd share a couple more of my SharePoint-related highlights from Tech Ed. On a general note, despite the fact this wasn't my first Tech Ed I'm still amazed at the scale - an estimated 14,000 people in total apparently. Incredible when you think the team can feed 14,000 people in one hour in one room! As my colleague remarked, even Jesus only managed 5,000 ;-)

Anyway, things I didn't mention last time:


Virtual Machine Manager

- Microsoft beefs up it's story on managing virtual machines with Virtual Machine Manager 2007 (part of System Center family). I know other products out there have much of this functionality, but let's face it, for many of us management of virtual machines currently extends to the Virtual Server 2005 admin website. Some of the things I liked were:

• 'library' of virtual machines including metadata - including the facility to have template machines which can be used as building blocks
• fast 'physical to virtual' conversions
• Intelligent Placement tool - analyzes all your physical hardware you have allocated to virtual machines and provides a recommendation as to where to put a new VM. This is based on information it has gathered (analysis of hardware etc.) but the parameters can be weighted, such as processor, memory, disk space etc.
• ability to delegate starting up (etc.) of the VM from the physical box, without granting them remote access to the physical machine or other VM management capability

SharePoint development thoughts

- On other matters, an interesting (and accurate I feel) angle on SharePoint development - whilst the current dev experience is often painful, this is an issue with the tools rather than the platform. Ted Pattison talked about the 'denial, anger, acceptance' cycle often seen in .Net developers starting SharePoint development. SharePoint 2003 developers on the other hand think everything is slick in comparison ;-) Remember that in the .Net world, the tool (Visual Studio) is developed and released in parallel with the platform (.Net). In the SharePoint 2007 world, for whatever reason (likely to be pressure to release at same time as Office client apps) this hasn't been the case, and so the tools are perhaps 18 months behind the client. So there may well be a time when you look back and chuckle at the idea of generating feature files/solution packages without an MS-developed tool.

- Some interesting examples of using the DataView web part from Dustin Miller. This thing alone can get you a long way to building composite applications in SharePoint. Most SharePoint developers will already be switched on to this idea (using WSS as a development platform rather than building from scratch in ASP.Net), but it could be the future for a lot of reasonably simple apps. Some of the functionality includes:-

• Display data from SQL, XML or web service
• Join disparate datasources without code (need at least a string value [or other 'joinable' type] to join on)
• Implement in-line editing (a la DataGrid)
• Perform conditional formatting (if x == 1 show a, otherwise show b)
• Use in a connected way with other web parts

..all without code. Very cool indeed. Note that the control renders using XSLT which can also be customised to get the required output. Also impressive is that SPD actually provides help by allowing in-line editing of the rendering in the design view, and mini-wizards to help with conditional formatting. The underlying XSLT is then written by the tool.

So it's not all bad with SharePoint development ;-)

SharePoint content at TechEd

Some good SharePoint content this week here in Orlando, which is good as it's pretty much the reason I'm here ;-) Thought I'd call out a couple of the things I've heard which have grabbed my attention:-

• an update to VSeWSS which addresses some of the issues I and other people have had with it, specifically the fact that it's not flexible enough for some scenarios. The next version will allow editing of the files generated (manifest.xml, feature and element definitions) before being packaged into the .wsp file. This will allow you to add feature receiver definitions or otherwise modify the generated XML. A CTP should be available in July.
• hearing MS's experiences on their internal MOSS deployment, believed to be the biggest in the world. How d'ya fancy managing 134,000 site collections running on 130 web front-ends?
• an extremely interesting 'participation' session on SharePoint deployment (see my features vs. Content Deployment post) lead by Andrew Connell. This is an area of SharePoint close to my heart (though I'm by no means saying I have all the answers) so it was good to have a beer afterwards with Andrew and continue the discussion. I'll be writing about this more soon.

On a general note it's great to see many SharePoint experts speaking here. A full summary of information useful to SharePoint implementors to come soon :-)

Going to TechEd Orlando

I'm off to TechEd U.S. tomorrow, it looks like there'll be some interesting SharePoint content. I'm also going to the pre-conference session and had a tough time deciding between Bill English/Andrew Connell's session, and Patrick Tissegham/Ted Pattison's session. Decided to go for the latter after much debating, should be good.

I know I've left it late, but if any UK-based SharePoint people are going out, leave me a comment (even if you only read this once out there) if you're interested in hooking up.

Chris.