SharePoint Admin Tip: starting the Windows Services Web Application Service

I reconnected a disconnected server to a SharePoint farm, and after the Configuration Wizard finished running, I checked the Services on Server page to verify that everything was OK and start up the Search and Excel services. Much to my consternation, the “Window SharePoint Services Web Application” service was stuck on “Starting” and none of my web applications had appeared in IIS. Argh.

Fortunately, Joel Oleson’s blog came to the rescue. The correct stsadm command to use to force this sucker to start is:

stsadm -o provisionservice -action start -servicetype SPWebService

It took a while for the command to complete, but that seemed to fix everything up nicely.

Bookmarked for Future Reading: Content Deployment Deep Dive

I know I’m going to need to read this shortly:

Deep Dive into the SharePoint Content Deployment and Migration API – Part 1

Using WSE in SharePoint Context

I am currently working on integrating some existing ASP.NET forms into the /_layouts/ folder in SharePoint as they will need to run in SharePoint context. These forms call web services using Microsoft’s Web Services Enhancements add-on. The add-on creates a config file with the WSE settings for your project, but it needs to be stored in the root of the web application, so you need to make sure to put a copy of this config file in the web root of the SharePoint site (e.g. c:\Inetpub\wwwroot\wss\VirtualDirectories\<site>).

Creating ASP.NET pages that run in a SharePoint site context

Because I keep losing this link & keep needing to perform 800 searches to find it again, I am bookmarking it here:

SharePoint 2007 – /_layouts and how to create pages that run in site context – Serge van den Oever

It is also a very useful link if you are doing any kind of custom development that requires a custom “settings” type page (for instance, if you are writing a custom workflow without InfoPath to handle the forms).

I also found that you may need to install a hotfix on your Windows 2003 VPC in order to install SP1 for Visual Studio in order to get the web application project type mentioned in that blog post. The hard way. After wasting many valuable hours.

Workflow Tip

Mick Badran reckons that you should always be developing workflows based on WF that are state machine based instead of sequential workflows. Since I’ve never done a state machine workflow, I’ll need to investigate them more and find out what the major advantages are; I think the main thing would be flexibility & extensibility of the workflow. Google is indicating I might want to start here and here.

Feature Stapling – the Best Thing Since Sliced Bread

OK, that may be a mild exaggeration, but the best thing I learned today was in a session co-presented by SharePoint genius, and my co-worker, Ishai Sagi.

If you don’t know how SharePoint Features work, take a quick look at the SDK as it can explain it far better than I can. Essentially what feature stapling allows you to do is piggyback features into a specific existing site definition without actually altering that site definition. Since you can implement just about any type of SharePoint functionality as a feature, including creating lists, content types, content, changing site settings, adding UI elements, and so on, that means you can easily customise out of the box site definitions.

SHEESH! I wish I had payed more attention to this six months ago– it would have saved me so many headaches.

I did a quick search and found this very thorough blog post by Chris Johnson from November last year that covers how to do it. A big thank you to Ishai and Milan Gross for introducing this concept to me.

Templating field controls in MOSS page layouts

The very first MOSS 2007 project I worked on started last year, during the second beta release. There wasn’t a lot of information available yet on how to use the product, so I had to make a few discoveries on my own. Of them, this has turned out to be the most useful, and I still haven’t seen a lot written about it (although I haven’t had much time to keep up on blog reading lately, so I’m not claiming to be the only person who has discovered this technique).

The project had a requirement for a summary links field control with a heading over it, something like:

Useful Links

• Link 1
• Link 2
• Link 3

Here was the stickler requirement: the heading needed to be hidden if there were no links in the field control. One approach was to hard code the heading in the page layout and use JavaScript to dynamically hide the heading element if the field control was empty. Not very elegant, and wouldn’t work if someone happened to have JavaScript functionality turned off in their web browser. Another recommended approach was to create a page layout for each possible combination of hidden and displayed fields– an option that quickly becomes unmanageable the more optional fields you have.

I was really interested in the DisplayTemplate property available on all the out of box field controls, but at first I had no idea how to use it. Experimentation with the property showed that populating the DisplayTemplate for a simple text field worked like a charm, but for things like Summary Links & Rich HTML Content, it looked like the field controls just completely ignored the DisplayTemplate contents.

How annoying!

A couple of new articles cropped up in the SDK around the same time that gave me a big clue and I was able to work out the rest even though the documentation is still a little… incomplete.

I started with the vaguely useful “How to: Create a Custom Field Control“. Obviously if I wanted a field control that both displayed summary links data and used the DisplayTemplate property, I was going to have to write my own. That article got me started on writing a custom field control, but I still wasn’t 100% sure how I could implement the DisplayTemplate itself. However, one clue was that you could create an .ascx file that would allow you to template a field control.

Since we were dealing with .ascx files, I had a look in the 12\TEMPLATE\CONTROLTEMPLATES folder and examined DefaultTemplates.ascx file for more information. This had a lot of markup in it that went something like:


<SharePoint:RenderingTemplate ID="*unique identifier*" runat="server">
<Template>
*Markup stuff here*
</Template>
</SharePoint:RenderingTemplate>


So I set up a new .ascx file with the above and my own markup & copied that to CONTROLTEMPLATES. It looked more or less like this:


<SharePoint:RenderingTemplate ID="CustomLabelField" runat="server">
<Template>
<div class="field_section" id="field_wrapper" runat="server">
<h1><SharePoint:FieldProperty ID="FieldProperty1" PropertyName="Title" runat="server"/></h1>
</div>
</Template>
</SharePoint:RenderingTemplate>


I then created an appropriate feature.xml and elements.xml and installed my new control as a feature by following the documentation here:
http://msdn2.microsoft.com/en-us/library/ms470880.aspx

Creating the feature centralised my DisplayTemplate so if I ever needed to modify the markup, I wouldn’t have to modify every single field control in every single page layout.

The next step was to create my own custom field control that worked out what type of field control it should be displaying and dynamically adding it into my field_wrapper div element before rendering, and then checking the ItemFieldValue for whether my field_wrapper div should be visible or not. For that I used the new How to: Create a Custom Field Control article for ideas. The key was using the TemplateContainer property to find the server side controls in my template that I needed to populate, e.g.

protected override void CreateChildControls() {
base.CreateChildControls();
// Check in the template for a div that wraps around all
// the content. The visibility on this div will be switched
// off if the field is empty of content.
this._divWrapper = this.TemplateContainer.FindControl("field_wrapper") as HtmlGenericControl;
// add in the field's display label, determine visibility for the wrapper div
...
}

After adding my new field control as a SafeControl to the web application, I can add the following into my page layout file:

<%@ Register Tagprefix="Custom" Namespace="Andrea.SharePoint.CustomControls" Assembly="Andrea.SharePoint.Custom" %>
...
<Custom:FieldWrapperFieldControl runat="server" FieldName="Useful_x0020_Links" DisplayTemplateName="CustomLabelField" />

Et voila! I had a custom field control that would “switch off” in published mode when empty, was editable and behaved exactly as the original field control for the type of field being displayed, and would display nicely formatted output with the field’s label as a heading tag above the field.

Hope you found this article useful.