Wednesday, June 25, 2008

How to build a Sharepoint Silverlight Beta 2 Webtart?

How to build a Sharepoint Silverlight Beta 2 Webtart?
If anyone is in need of the above topic pls add your comments.

Sunday, May 25, 2008

Create a minimal Master Page

One of the first tasks that you must complete when configuring a Microsoft Office SharePoint Server 2007 Web site is to create one or more master pages. A master page contains references to elements that you can share across multiple pages in an Office SharePoint Server 2007 site, such as navigation, search controls, logon controls, and banner images. A master page can also contain the cascading style sheet (CSS) and ECMAScript (JScript, JavaScript) references that define the overall look and feel of your site. Commonly, every site—and therefore every page—in your site collection uses the same master page to present a consistent user experience across the entire site collection. Depending on your needs, you can use a different master page for one or for all of the sites in your site hierarchy to distinguish the various areas of your portal.

To create a minimal master page
1. Open SharePoint Designer.
2. On the File menu, click New, point to SharePoint Content, and then click the Page tab.
3. Double-click Master Page to create a new master page.
4. Click Design to show the master page in design view. You should see header and left margin areas and several content placeholders in the master page.
5. Click Code to show the master page in code view.
6. Copy the following code into the master page.


<%-- Identifies this page as a .master page written in Microsoft Visual C# and registers tag prefixes, namespaces, assemblies, and controls. --%>
<%@ Master language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" ""&gt;
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Register Tagprefix="SPSWC" Namespace="Microsoft.SharePoint.Portal.WebControls" Assembly="Microsoft.SharePoint.Portal, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="PublishingWebControls" Namespace="Microsoft.SharePoint.Publishing.WebControls" Assembly="Microsoft.SharePoint.Publishing, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="PublishingNavigation" Namespace="Microsoft.SharePoint.Publishing.Navigation" Assembly="Microsoft.SharePoint.Publishing, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register TagPrefix="wssuc" TagName="Welcome" src="~/_controltemplates/Welcome.ascx" %>
<%@ Register TagPrefix="wssuc" TagName="DesignModeConsole" src="~/_controltemplates/DesignModeConsole.ascx" %>
<%@ Register TagPrefix="PublishingVariations" TagName="VariationsLabelMenu" src="~/_controltemplates/VariationsLabelMenu.ascx" %>
<%@ Register Tagprefix="PublishingConsole" TagName="Console" src="~/_controltemplates/PublishingConsole.ascx" %>
<%@ Register TagPrefix="PublishingSiteAction" TagName="SiteActionMenu" src="~/_controltemplates/PublishingActionMenu.ascx" %>
<%-- Uses the Microsoft Office namespace and schema. --%>
<WebPartPages:SPWebPartManager runat="server"/>
<SharePoint:RobotsMetaTag runat="server"/>

<%-- The head section includes a content placeholder for the page title and links to CSS and ECMAScript (JScript, JavaScript) files that run on the server. --%>
<head runat="server">
<asp:ContentPlaceHolder runat="server" id="head">
<asp:ContentPlaceHolder id="PlaceHolderPageTitle" runat="server" />
<Sharepoint:CssLink runat="server"/>
<asp:ContentPlaceHolder id="PlaceHolderAdditionalPageHead" runat="server" />
<%-- When loading the body of the .master page, SharePoint Server 2007 also loads the SpBodyOnLoadWrapper class. This class handles .js calls for the master page. --%>
<body onload="javascript:_spBodyOnLoadWrapper();">
<%-- The SPWebPartManager manages all of the Web part controls, functionality, and events that occur on a Web page. --%>
<form runat="server" onsubmit="return _spFormOnSubmitWrapper();">
<wssuc:Welcome id="explitLogout" runat="server"/>
<PublishingSiteAction:SiteActionMenu runat="server"/>
<PublishingWebControls:AuthoringContainer id="authoringcontrols" runat="server">
<PublishingConsole:Console runat="server" /> </PublishingWebControls:AuthoringContainer>
<%-- The PlaceHolderMain content placeholder defines where to place the page content for all the content from the page layout. The page layout can overwrite any content placeholder from the master page. Example: The PlaceHolderLeftNavBar can overwrite the left navigation bar. --%>
<asp:ContentPlaceHolder id="PlaceHolderMain" runat="server" />
<asp:Panel visible="false" runat="server">
<%-- These ContentPlaceHolders ensure all default SharePoint Server pages render with this master page. If the system master page is set to any default master page, the only content placeholders required are those that are overridden by your page layouts. --%>
<asp:ContentPlaceHolder id="PlaceHolderSearchArea" runat="server"/>
<asp:ContentPlaceHolder id="PlaceHolderTitleBreadcrumb" runat="server"/>
<asp:ContentPlaceHolder id="PlaceHolderPageTitleInTitleArea" runat="server"/>
<asp:ContentPlaceHolder id="PlaceHolderLeftNavBar" runat="server"/>
<asp:ContentPlaceHolder ID="PlaceHolderPageImage" runat="server"/>
<asp:ContentPlaceHolder ID="PlaceHolderBodyLeftBorder" runat="server"/>
<asp:ContentPlaceHolder ID="PlaceHolderNavSpacer" runat="server"/>
<asp:ContentPlaceHolder ID="PlaceHolderTitleLeftBorder" runat="server"/>
<asp:ContentPlaceHolder ID="PlaceHolderTitleAreaSeparator" runat="server"/>
<asp:ContentPlaceHolder ID="PlaceHolderMiniConsole" runat="server"/>
<asp:ContentPlaceHolder id="PlaceHolderCalendarNavigator" runat ="server" />
<asp:ContentPlaceHolder id="PlaceHolderLeftActions" runat ="server"/>
<asp:ContentPlaceHolder id="PlaceHolderPageDescription" runat ="server"/>
<asp:ContentPlaceHolder id="PlaceHolderBodyAreaClass" runat ="server"/>
<asp:ContentPlaceHolder id="PlaceHolderTitleAreaClass" runat ="server"/>
<asp:ContentPlaceHolder id="PlaceHolderBodyRightMargin" runat="server" />

7. On the File menu, click Save As, provide a unique file name with the .master extension, and then save the file to the master page gallery (/_catalogs/masterpage) in your site collection.

Wednesday, May 14, 2008

Creating a site administration page that looks like a real SharePoint administration page

This page will have to run in the context of the site.

At the end of this article our administration page will look like this:

When a user submits the page, the page will also validate if the url that was entered is a valid SharePoint site.

Step 1 Add a link to the

Site Settings menu.

The first step is to create a link to the Site Settings menu. We will lock this down, so that it is only available for administrators. The easiest way to do this is by using a SharePoint Feature. How to install and activate can be found in the previous article. The feature xml for this feature looks like this

<Feature Id="06d77b33-76b2-4a14-bef4-3e4b4203d88e"
Title="Custom Navigation Site Menu items by Ton"
Description="My custom Site Menuitems for setting up navigation."
<ElementManifest Location="tstsitemenus.xml"/>

This is the XML for installing the feature. The file that is referenced in the ElementManifest node actually adds the menu item:

<Elements xmlns="">
Title="Setup Custom Navigation"> Location="Microsoft.SharePoint.SiteSettings" GroupId="Customization"
<UrlAction Url="~site/_layouts/CustomNavigation.aspx"/>

A number of attributes further explained:

· Title – the title of the link

· Location – The location of the new action. This can be the Site Actions menu, edit menus, toolbars etc. I have picked “Microsoft.SharePoint.SiteSettings” to make it appear in the site settings page.

· GroupId – The group in which the action will appear. I have picked “Customization”, because this makes our action appear in the “Look and Feel” section of the site settings. You can add these sections yourself using a “CustomActionGroup”. See the WSS SDK for more details.

· RequireSiteAdministrator – This makes the option only appear for Site Administrators.

· UrlAction – The url to navigate to when the user clicks the link. By using the “~site” in the url, we make our administration page run in the context of the site.

After installing and activating the feature, our site administration now has a new item:

Step 2 – Create the administration page

In the second step we will create the CustomNavigation.aspx page that is referenced from the menuoption in step 1. The first step in making your administration page look like real SharePoint administration pages, is inheriting it from “WebAdminPageBase”, which is available in the “Microsoft.SharePoint.ApplicationPages” namespace. I created a new class library project and added a new class called “CustomNavigation”.

Our aspx page should use this code behind, and also register the namespaces and controls that we will use to build the page. I will not copy all code, you can find that in the attached ZIP file.

<%@ Assembly Name="Microsoft.SharePoint.ApplicationPages, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>

<%@ Page Language="C#" Inherits="Eog.OfficeServer.ApplicationPages.CustomNavigation, Eog.OfficeServer.ApplicationPages, Version=, Culture=neutral, PublicKeyToken=4765c72bbf274873" MasterPageFile="~/_layouts/application.master" %>

Step 3 – Add controls to the placeholders

Because our page inherits from WebAdminPageBase, we now have several placeholders that we need to populate. We don’t need to build the whole page, the masterpage does that for us, we just populate a few placeholder. The first placeholders are the title placeholders:






text="Custom Navigation"






Setup Custom Navigation


The main content are of the page (called PlaceHolderMain) will re-use some standard control templates that are available in the ControlTemplates folder.

These are registered at the top of the page as well:

<%@ Register TagPrefix="wssuc" TagName="InputFormSection" src="~/_controltemplates/InputFormSection.ascx" %>

We start off creating a new section on the page for our “Local Navigation” settings. This can be done by using the InputFormSection control. The InputFormSection can have one or multiple controls. These are added within a “<Template_InputFormControls>“.

This template can have multiple controls. These controls are InputFormControl controls, that are a combination of the label and the control. They look like this:


LabelText="Navigation Expand Depth"





Title="Navigation Expand Depth"




MaxLength="255" />



Step 4 – Add OK and Cancel button

After adding the control to edit the values, we add the OK and Cancel button to the page. These are added in a special ButtonSection, that will be added just below the InputFormSection. The code for the OK button (see the zip for the rest):











Step 5 – Add validation

The last part of the aspx page at this stage is the validation of the page. Most out of the box administration pages add a FormDigest control to the page. This is a SharePoint control that adds security validation to the page. This is specific for the user requesting the page and the time it is requested. After some time it expires, making it impossible to post the page. I have not added this yet to my page, will write a post on it after I sorted this out.

The validation that we will add is a validator for checking if the url entered in the Navigation Parent field is a valid SharePoint site. Just after the InputFormTextbox, we add a CustomValidator:




Display = "Dynamic"

ErrorMessage = "Please enter a url for a SharePoint site."



Step 6 – Implement code-behind

The code to actually make the page work is implemented in the CustomNavigation.cs. First we need to ensure that users who are not administrator cannot access the page by using the url directly. That is easy J; just add these lines :

protected override bool RequireSiteAdministrator




return true;



You can find all code to load and save the siteproperties in the attached zip file. Saving a property to the property bag can be done like this:

// Store NavigationExpand in the property bag.

if (web.Properties.ContainsKey("navigationexpand"))


if (web.Properties["navigationexpand"].ToLower() != navigationExpandTextBox.Text.ToLower())


web.Properties["navigationexpand"] = navigationExpandTextBox.Text;

modified = true;





web.Properties.Add("navigationexpand", navigationExpandTextBox.Text);

modified = true;


And don’t forget to call Update:


After saving the properties to the property bag, we will redirect the user back to the site settings page. The code to do that:








Step 7 – Deploy the administration page

The proper way to deploy our administration page in SharePoint 2007 is through a Solution Deployment package. I haven’t had the time to sort that out, but is a very nice way of deploying packages like this.

Monday, May 12, 2008

Customizing Default Pages in Sharepoint

This is the first post in a new series covering advanced design in Microsoft Office SharePoint Server 2007 (MOSS2007). As with previous Extreme SharePoint Design posts, much of the material will be undocumented, some posts will walk the line on supportability, and some will downright obliterate the line just to show what can be done; therefore, all techniques should be tried first in a test environment and a good backup is always a necessity. Now on to the good stuff!

MOSS2007 takes a radically different approach to rendering pages, due mostly to the integration of Content Management Server features into the product and an ongoing effort on Microsoft’s part to migrate towards a more structured, data-bound architecture (i.e. CAML and XML). Much of what we learned customizing SPS2003 will still be applicable but a great deal of the behind the scenes machinery has changed. A good place to begin learning how to modify MOSS2007 to meet your needs is with default page customizations; changing the structure, appearance, and layout of the default site welcome pages.

Since MOSS2007 is built on ASP.NET 2.0, a solid understanding of master pages is required in order to grasp how site pages are constructed and rendered. A master page (any ASPX page with a .master extension) is nothing more than a template with placeholders for content, much like a regular ASP.NET page that invokes user controls to render content. In .NET 2.0 syntax, these placeholders are implemented using the <ASP:ContentPlaceHolder> tag. Placeholders can be nested, so that a top-level placeholder may have multiple levels of child placeholders, much like a parent DIV can have many nested child DIV’s.

The master page by itself usually contains very little actual content other than headers and navigation – it’s just a framework for one or more layout pages that comprise the body of the page. In MOSS2007, the master page DEFAULT.MASTER, located in WEB SERVER EXTENSIONS\12\TEMPLATE\GLOBAL, defines the standard top header and left navigation layout found throughout the basic site definitions. Unlike SPS2003, where the default page in each site definition contained all the code necessary to render the page, the new site definitions, located in 12\TEMPLATE\SITETEMPLATES, have a DEFAULT.ASPX page that references the master page but contains no actual content. Instead, the default page is built at runtime when the site is created by combining MASTER.DEFAULT with the layout page referenced in the PublishingPageLayout property of the Default.aspx File node of the Modules configuration in ONET.XML (~SiteCollection/_catalogs/masterpage/defaultlayout.aspx for the SPS site definition, which corresponds to 12\TEMPLATE\FEATURES\PORTALLAYOUTS\DEFAULTLAYOUT.ASPX in the server file structure). The combined file is then stored in the Pages list on the top-level site.


When you edit the default page using SharePoint Designer you are actually editing the combined code from two pages – the master page and the layout page. Fortunately, because the default page is stored in a list, the whole ghosting/unghosting issue no longer applies (hooray for that!); however, there is one major drawback – since the page doesn’t actually exist until the site is created, editing it only applies to the current site instance – new sites or subsites based on the same definition will have to edited manually each time they are created. To automate this process, the site definition must be modified in a similar manner to the methods used in SPS2003 but using the new master page methodology. Doing so requires making changes not just to a single default page but both the master and layout pages (we’ll cover creating new site definitions from scratch in a subsequent post).

The layout page works with the default page by specifying what content is to be placed in the placeholder zones using the <ASP:Content> tag and referencing the placeholder id. The page handler process then assigns the content in the layout page, which consists of the HTML markup we are used to seeing in SharePoint pages (server controls, web part zones, etc.), to the proper zone in the default page. The following illustration is a wireframe model of a combined DEFAULT.ASPX page with all the major placeholders, server controls, custom tags, content areas and publishing/web part zones placed in their proper context (click on the image to view it full size):

Blue areas in the model indicate placeholders, red is for server/user controls, purple represents new ASP-specific controls (in this case the breadcrumb navigation menu), green indicates the new PublishingWebControls objects, and grey is the standard web part zones. The yellow headers indicate the relationship between the default and layout pages. The final rendered page looks like this:

As you can see from the wireframe model, the page layout is not all that different from SPS2003, except that content is now separated from navigation by using two different file types. The beauty of this model is that changes to DEFAULT.MASTER are global; no more cutting and pasting code modifications into multiple site definitions. Likewise, the DEFAULTLAYOUT.ASPX page is also universal, making changes much easier to implement. If, for example, we wished to change the basic layout of the web part zones in the body of the page, we can modify the markup in DEFAULTLAYOUT.ASPX without touching the headers and navigation contained in the master page. We can also add content to the master page by using <ASP:Content> tags and specifying the placeholder with the ContentPlaceHolderId setting without actually modifying the master page itself.

In SPS2003 the customization process was cumbersome and inefficient; with the new master page model, Microsoft has given us far greater flexibility in customizing SharePoint sites to meet each organization’s unique requirements. In subsequent posts we will explore in greater depth the new MOSS2007 architecture, including the new list file structure, the long-overdue changes to the administration pages, and how to create new site definitions from scratch.

Custom Site Definitions

Did you know you can create your own tab for organizing your custom site definitions? The tabs I am referring to are located on the new web/site page ( _layouts/newsbweb.aspx).

To add your own tab you will want to add your own unique DisplayCategory attribute to the configuration section of the WEBTEMP*.XML file for your new site definition.

Example Code:

<Configuration ID=”2″ Title=”Sample Document Workspace” Hidden=”FALSE” ImageUrl=”/_layouts/images/dwsprev.png” Description=”This sample template creates a site for colleagues to work together on documents. It provides a document library for storing the primary document and supporting files, a Task list for assigning to-do items, and a Links list for resources related to the document.” DisplayCategory=”Shane’s Site Definitions” >