Archive

Posts Tagged ‘SPC09’

Branding SharePoint 2010 Collaboration Sites – Part 3 in a Series

February 23rd, 2010 4 comments

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:

Screenshot of AdditionalPageHead delegate control in v4.master

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!

Screen shot of HTML source of page containing a link to the branding 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…

Branding SharePoint 2010 Collaboration Sites: Part 1 in a Series

December 23rd, 2009 2 comments

Themes are dead! Long live themes!

The “awkward” themes system based on CSS and images in SharePoint 2007 is going the way of the dodo. No more deploying into the “12 hive” and having to modify the SPThemes.XML to register your theme.

As you may already know, in SharePoint 2010, themes are now just a set of colour and font values specified in an Office .thmx file. You upload a .thmx file into the Themes catalog and a site administrator can “theme” their site using the updated Themes web interface.

Unfortunately, if you want to brand any of the out-of-the-box SharePoint 2010 collaboration sites beyond colours and a couple of font choices, you will need to jump through a few hoops. All of which I’ll try to explain to you in this series of blog posts.

How does the SharePoint 2010 Theming Engine work?

So what happens behind the scenes when you select a 2010 theme to apply to your site? How do the new colours specified in the .thmx file and/or the colours you’ve chosen through the web interface get applied to your site?

There  are essentially two main locations where CSS files for SharePoint 2010 are stored:

Themable folder in 14 Hive

Themable folder in 14 Hive

  1. In the “14 hive” at %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\1033\STYLES;

    The exact location of the CSS files varies depending on whether you have a language pack installed and have another language as the default. I’m in North America and the Locale ID for the majority of our projects is 1033 for English (US).

    These CSS files are used by all webs located on the front-end web server.

  2. In each web’s Style Library. These CSS files only affect the specific web.
Themable folder in web's Style Library

Themable folder in web's Style Library

Oh, btw, when I say “web,” I mean SPWeb… if you’re a SP Dev, you’ll know what I’m talking about, otherwise think “site” but not “SPSite”…

So you must be thinking, “that’s exactly the same as in SharePoint 2007!” And you would be right, but if you look in the first location, you’ll notice a folder named “Themable”…

If you look in the Style Library of a team site, you won’t find anything… :-) BUT if you were to create a Publishing Portal and look inside the Style Library, you’ll find a “Themable” folder as well…

Taking a look at some of the CSS files, you’ll notice some things in the CSS comments like:

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

/*[RecolorImage(themeColor:"Accent6",method:"Tinting")]*/
background-image:url("/_layouts/images/selectednav.gif");

What this? Compile time directives?

Yup, when the user selects a theme for a web, SharePoint goes and recompiles the CSS and places the compiled CSS files into the web’s “_theme” folder.

UPDATE: There’s also a second location in the content DB where a compiled theme could live besides a web’s “_theme”. If you use the ThmxTheme.SetThemeUrlForWeb method to set the web’s theme and specify “true” for the shareGenerated parameter, the compiled CSS files will be located in “/_catalogs/theme/Themed/[1234567]” instead. [1234567] is some hex value based on the theme name or folder, not exactly sure ATM.

SharePoint will replace any colors defined in the rule following the comment with the matching colour that’s defined in the .thmx or the web interface. It can even re-render graphics based on pixel co-ordinates, tinting (as seen in the second example above) or even re-render gradients for you! This is going to be a great time saver for projects where requirement dictates multiple colour variations on a central design!

How the SharePoint 2010 Theming Engine Works

Slide shamelessly stolen from Elisabeth Olsen's presentation at SPC09.

What are all the directives? Dunno. There’s absolutely no documentation that I’ve found at the moment. There’s plenty of examples sprinkled throughout the CSS files found in the “Themable” folders though. I’m hoping someone out there compiles a list of all of them sooner rather than later.

In the next episode…

My next post will be on the new and improved CSSRegistration control which is how we can add our own custom CSS that can also take advantage of the new 2010 theming system!

UPDATE:

SPC09: Status Bar and Notification APIs

November 3rd, 2009 Comments

SharePoint 2010 Status Bar and Notification elementsExcuse the really bad screen cap to the right… the Status Bar and Notifications are two UI elements in SharePoint 2010 which allow us to give the user information in context without distracting them. The Status Bar and Notifications are both exposed as client-side JavaScript APIs.

Status Bar

The Status Bar lives below the Ribbon and displays persistent information such as page status or web site alerts. It already existed in SharePoint 2007 as an UI element but it’s functionality was not exposed as an API. It will display an HTML message, which can include links and/or images, on 1 of 4 pre-set background colours depending on the importance of the status defined.

There is a Server API to set statuses at page render time as well as a JavaScript API to dynamically add/remove messages.

The JavaScript API is in the SP.UI.Status namespace and is as follows:

SP.UI.Status.addStatus(strTitle, strHtml, atBeginning)
SP.UI.Status.updateStatus(sid, strHtml)
SP.UI.Status.removeStatus(sid)
SP.UI.Status.removeAllStatus(hide)
SP.UI.Status.setStatusPriColor(sid, strColor)

Notifications

Notifications are brand new to SharePoint 2010 and they are used for transient or semi-transient messages such as action confirmations. Notifications appear on the right side of the page below the ribbon and default to a 5 second display period. Like the Status Bar, the message format is HTML with the ability of including links and/or images.

There is a JavaScript API to add/remove messages. You also have the option to make a Notification “sticky” which means it will continue to display until you manually remove it through the API.

Notifications are in the SP.UI.Notify namespace:

SP.UI.Notify.addNotification(strTitle, bSticky, tooltip, onclickHandler)
SP.UI.Notify.removeNotification(id)

SharePoint 2010 Developer Hands-on Labs

October 27th, 2009 Comments

Some of the modules from the Hands-on Labs at SPC are available at the SharePoint Developer Center.

Here’s the list of the modules:

  • Module 1: Getting Started Building Web Parts in SharePoint 2010
  • Module 2: What Developers Need to Know About SharePoint 2010
  • Module 3: Building Blocks for Web Part Development in SharePoint 2010
  • Module 4: Accessing SharePoint 2010 Data with Server-Side APIs
  • Module 5: Accessing SharePoint 2010 Data with Client-Side APIs
  • Module 6: Accessing External Data with Business Connectivity Services in SharePoint 2010
  • Module 7: Developing Business Processes with SharePoint 2010 Workflows
  • Module 8: Creating Silverlight User Interfaces for SharePoint 2010 Solutions
  • Module 9: Sandboxed Solutions for Web Parts in SharePoint 2010
  • Module 10: Creating Dialog Boxes and Ribbon Controls for SharePoint 2010
Categories: Development, SharePoint

SPC09: Master Pages

October 21st, 2009 Comments

A quickie: no more application.master!

In Microsoft SharePoint Foundation, application pages can now inherit a customized site master page through the DynamicMasterPageFile attribute.

In addition, there are a few pages which have been designated as Safeguarded Application Pages. These are the application pages that have safeguards against a broken master page. If these pages encounter an error when loading the dynamic master page, a safe master page in the _layouts folder is loaded instead.

  • AccessDenied.aspx
  • MngSiteAdmin.aspx
  • People.aspx
  • RecycleBin.aspx
  • ReGhost.aspx
  • ReqAcc.aspx
  • Settings.aspx
  • UserDisp.aspx
  • ViewLsts.aspx

Check out the documentation on MSDN regarding master pages in SharePoint 2010.

SPC09: SharePoint Designer 2010

October 20th, 2009 Comments
SharePoint Designer 2010

SharePoint Designer 2010

It will be interesting to see how SharePoint Designer (SPD) 2010 fits into our development work flow.

For SharePoint 2007, we had basically avoided SPD 2007 like the plague. It didn’t fit into our Visual Studio development work flow.  Almost everything you did from a client-side development perspective was not easily reproducible across sites as the artifacts were basically all unghosted/customized. The actual SharePoint functionality was limited just seemed to be tacked on top of the FrontPage. The HTML editing around customizing master pages and page layouts was slow, buggy and heavy handed as it would arbitrarily change our code.

The interface has been completely overhauled in SPD 2010. Instead of the HTML editing centric interface in SPD 2007, we now have an interface that instead focuses on exposing various SharePoint capabilities to users with less technical expertise. It’s still not something you would deploy to all your users. It really is for your SharePoint power user or site administrator to manage their sites and lists.

SharePoint 2010 sites now have settings to determine what SPD is allowed to do or not do. There are settings to enable SharePoint Designer, enable detaching pages from their site definition, enable customizing master pages and layout pages, and enable managing of the web site URL structure.

The other big thing about SPD 2010 is the ability for it to now create reusable work flows. You can create a work flow and then package it up as a WSP and import it into Visual Studio 2010 for further development. You can also design your work flow in Visio 2010 which is quite interesting.

Check out the SharePoint Designer Team Blog for detailed info on all the new SPD 2010 features.

SPC09: SharePoint 2010 Ribbon and Form Dialogs

October 20th, 2009 Comments
SharePoint 2010 Ribbon

SharePoint 2010 Ribbon

A busy first day at the SharePoint Conference so I’ll start off with a quickie.

As most of you know already, SharePoint 2010 will use the ribbon interface for editing. I personally like the ribbon from an UI perspective compared with the old editing UI for SharePoint 2007. Some might argue that it’s a bit cluttered and the context sensitive editing may be confusing to new users. I think it’s something that users can grasp in short fashion especially if they use Office 2007 or 2010 as well.

Something that’s new to me in 2010 are the AJAX form dialogs. Pretty much any new item creation is now done in a modal dialog now instead of taking the user to a different form page in 2007. This is great as it keeps everything in context for the user.

An added benefit of the ribbon and form dialogs is that in most cases we no longer have to design for or make design decisions regarding these edit mode elements anymore. They are pretty much separate from the rest of the page from a design perspective.

UPDATE:
I’ll be putting up another post regarding the dialog creation API which is exposed as a JavaScript library in a later post.

The ribbon is extensible as well, you’re able to create new button elements, replace existing elements with customized functionality or remove an element all together.