Buta no Ie

When Sid the Kid scored in OT to bring home the gold?

I would think most things people (and by people I really mean me) say about Translink tend to be on the negative side. Not in this post though!

First off, I think it’s great that Translink has added 3 extra late night runnings of the West Coast Express (WCE) for us people in the boon docks so that we can stay in downtown Vancouver late to cheer on our olympians. It gets cars, and more importantly one or two drunk drivers behind those cars, off the road! I wish they would run some late night train busses, but I suppose they don’t get enough capacity to make it sustainable.

Yesterday night I had taken one of the extra late trains to get back home. The bus that takes me home normally stops service sometime around 11:00pm and I was expecting to trudge back up the hill at 1:00 in the morning. To my surprise, there were buses waiting WCE passengers! And even more surprising, they weren’t following their normal routes! Instead they just served the general areas surrounding their routes and the driver would ask where each passenger where they needed to go and then zipped around town dropping everyone off as if all the passengers where sharing one big taxi!

So thank-you Translink for getting me home quickly and efficiently and for saving me a 20 minute minute trek in the rain!

I find this is somewhat funny as this blog post has been sitting in my drafts list for over 3 years now, when I first started trying to blog in 2006. I started out with a flurry of posts and then only had a single post up in the next 3 years!

Here is the post as is seeing that the two points that were typed out still apply today. I must have had some other points to make that have been long forgotten which I suppose demonstrates the importance of timeliness!

Cang and I had an abbreviated conversation about blogging the other night. I figure I’d finish the conversation here.

He thought I was posting way too frequently. Cang‘s posts are much more deliberate and are fewer and far between. I also think the content has somewhat of a greater value when compared to mine.

I agree with Cang the frequency of my posts (almost 1 per day) are ultimately not sustainable but there is a method to my madness.

First off, I’m trying to get in the habit of posting things in a timely fashion. If you wait too long, whatever you were planning to write about may no longer be relevant or as news breaking. You’ll also start to lose details of your experience or the thoughts in your head, even if you originally took notes.

I’m also throwing stuff up on the wall and seeing what sticks. Sure, one of the goals is to blog about client-side development, something that I still need to get to, but what other things from my daily happenings are people interested in reading about?

Now these things apply specifically to my blog and my goals for it. If your blog is your diary, by all means, keep posting anything you want. If you want your blog to be a specific knowledge resource, yes, keep the posts limited but high in content value.

In part two, we posted about how to register our custom style sheets in a way that we could still take advantage of the new SharePoint 2010 colour switching theming engine. In this post we’ll go through how to do this without having to modify the out-of-the-box master pages or having to use custom master pages for your sites.

Delegate Controls

As I mentioned at the end of part two, the way we’re going to get our CSS added to our sites and pages is through the use of a delegate control. For those of you who aren’t familiar with delegate controls, they are essentially placeholders for you to inject your own controls via a feature. Your feature can be scoped to either Web, Site, WebApplication or Farm. I’m going to keep the explanation on delegate controls short as there’s plenty of information out there about them:

• Chris O’Brien: Using the Delegate Control
• SharePoint’s Delegate Control Power
• MSDN 2010 SDK: DelegateControl Class

AdditionalPageHead Delegate Control

The AdditionalPageHead Delegate

Delegate controls have a AllowMultipleControls property which when set to true, all controls keyed to that delegate are added to the page; when set to false, only the control registered with the lowest sequence value is added to the page.

All of the delegate controls in the OOTB master pages have AllowMultipleControls set to false, with the exception of one, AdditionalPageHead, which does allow multiple controls. And guess what? AdditionalPageHead is actually located in the page head, where you would normally add CSS elements! This is the perfect place for us to inject any CSS registration controls.

Putting it all together…

Let’s put together a simple solution using the Visual Studio 2010 SharePoint Tools which will:

1. deploy our CSS file in the Themable folder in the /Layouts/1033/Styles
2. deploy a user control into the ControlTemplates folder which uses the CSSRegistration control to register our CSS
3. install a feature which inserts our user control onto our pages via the AdditionalPageHead delegate

The CSS

Keeping it simple, all our CSS does is set the background color of the <body>. We’ll use #FFF (white) as our default background color and also decorate the rule with one of the SharePoint 2010 compile time directives to whatever we might set the “Light1” color value as through the Theme UI.

body {
/*[ReplaceColor(themeColor:"Light1")]*/
background-color: #fff;
}

The Delegate Control

Again, nice and simple, we’re going to use the CSSRegistration control to register our branding CSS after corev4.css:

<%@ Assembly Name="$SharePoint.Project.AssemblyFullName$" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<sharepoint :CSSRegistration Name="<% $SPUrl:~sitecollection/_layouts/1033/Styles/Themable/SingChan.SP2010.Branding/branding.css %>" After="corev4.css" runat="server" />
</sharepoint>

Element Manifest

And finally we’ll define our element manifest for our delegate feature:

<?xml version="1.0" encoding="utf-8"?>
<elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <control Id="AdditionalPageHead" Sequence="80" ControlSrc="~/_ControlTemplates/SingChan.SP2010.Branding/CSSRegistrationControl.ascx" />
</elements>

You’ll most likely scope your delegate feature to either Web or Site for branding purposes. I tend to scope my feature at the site collection level to achieve a consistent brand across all the webs in the site collection. If there’s a requirement to have different branding for one or two specific sites, then we can always have a second feature which deploys those overrides at a web-level scope. If you have vastly different brands across webs in your site collection, then you may want to scope only at the web level so that your brands don’t conflict or end up with any style inheritance issues.

That’s it!

If all went well, we should see the link to our style sheet emitted after the link to corev4.css!

Our branding CSS being emitted in HTML

If all is not well, here’s the ZIP file containing the branding VS2010 solution for reference:
SingChan.SP2010.Branding.zip

Previously…

• You can find Part One here!
• You can find Part Two here!

Sam, one of our QA guys at Habanero, brought to the office the torch his grandfather carried during his leg of the Olympic Torch Relay. Really cool to be able to take a few shots with a torch that’s been “kissed” by the olympic flame!

A quick tip…

Because the sp.ui.dialog.js library is lazy-loaded, it may not be available when the page is ready/loaded. I’ve seen some early examples where if you wanted to do something on page load, you use:

_spBodyOnLoadFunctionNames.push("YourInitFunction()");

This will not work if you want to open a SharePoint dialog on page load. Instead use:

ExecuteOrDelayUntilScriptLoaded(YourInitFunction, "sp.ui.dialog.js");

A word to the wise, if you’re planning on upgrading your solutions developed on the public beta to the new SharePoint 2010 Release Candidate, double check your code!

This is especially true if you have custom master pages, page layouts, or site templates which are derived from the OOTB ones.

Here’s a simple screen grab of a diff between the Public Beta v4.master and the version in the RC:

v4.master differences

Notice one of the Site Actions menu items has been removed in the RC and permissions are slightly different in another. There are other small differences in the v4.master like some of the sprite co-ordinates have changed for the help and recycle bin icons which might leave you scratching your head as to why the wrong image is showing up.

The v4.master is just a short example. I found quite a few differences in the Blog site template and spent quite a bit of time doing diffs and merging my customizations back into the updated RC versions.

If you’re using TFS for your source control, I found it helpful to just copy and paste the contents of original version of whatever file you customized into your versioned control file and then doing a difference/merge between that and the last version checked-in.