Tuesday, June 10, 2008

How to Creating a Custom Site Definition in Sharepoint

Site Definition project is a class library project.

All components that you want to be automatically provisioned within sites created from the site definition should be referenced from this ONET.xml file. The base structure of the ONET site definition schema is shown below.

NavBars
If you’d like to simply use the default navigation scheme in your site definition, copy the contents of this node from the STS site definition. If you are building custom navigation controls and want to bypass the SharePoint navigation user interface entirely, you can skip this node. Note that navigation bars included in this node also define the Quick Launch sidebar within the Team Site, which can also be accessed by code through the object model. To add a navigation element to the Quick Launch sidebar, add an additional NavBar element to the NavBars node. Following is an example QuickNav bar that you can add through CAML in the site definition. Note that the HTML within the Prefix, Body, and Suffix attributes is XML encoded. The name of the NavBar specifies the heading of the navigation section, and each NavBarLink node represents a hyperlink. NavBar Name="Site Pages"Prefix="<table border=0 cellpadding=4 cellspacing=0>"Body="<tr><td><table border=0 cellpadding=0 cellspacing=0><tr><td><img src='/_layouts/images/blank.gif' ID='100' alt='' border=0>&nbsp;</td><td valign=top><a ID=onetleftnavbar#LABEL_ID# href='#URL#'>#LABEL#</td></tr></table></td></tr>" Suffix="</table>"ID="1028" >NavBarLink Name="Web Page 1" Url="SitePages/Page01.aspx" />NavBarLink Name="Web Page 2" Url="SitePages/Page02.aspx" />NavBarLink Name="Web Page 4" Url="SitePages/Page04.aspx" />/NavBar>One more example

DocumentTemplates
The DocumentTemplates node documents are used as document library default documentswithin the site. If you do not provide document templates, the site is still created, but the user is not able to create new documents by using the New button in Document Libraries.
Configurations
The site definition can also have multiple configurations, but each configuration reuses the same modules,feature references, and lists. These named configurations must also be referenced in another configuration file, WEBTEMP.*.xml, to be available to Windows SharePoint Services.For example, the following List nodes specify that the Litware Customer Listand Litware Vendor List be created on site creation at the site-relative Lists/Vendors andLists/Customers URLs.

Within the configuration, you can also specify which features should be a part of this site collection or site. The SiteFeatures node lets you define features to be enabled for the site collection if the site is created as the site collection’s top-level site. For site features, you want to include common infrastructure such as the BasicWebParts feature, as well as any additional infrastructure such as a feature that installs your company’s custom .webpart Web Part entries in the Web Part gallery.SiteFeatures>Feature ID="00BFEA71-1C5E-4A24-B310-BA51C3EB7A57" />/SiteFeatures>WebFeatures>Feature ID="00BFEA71-4EA5-48D4-A4AD-7EA5C011ABE5" />/WebFeatures>
Modules
Module element is a defined file set with nested File elements that are used to provision pageinstances from page templates.

Web Template Files
The last component of the site definition is the WEBTEMP file. The WEBTEMP file referencesconfigurations in the site definition’s ONET.xml file. Each site definition solution youcreate should have its own WEBTEMP file, with the following naming convention:WEBTEMP.[solution].xml The WEBTEMP file has one Template node per site definitionand a Configuration node for each configuration.

Monday, June 9, 2008

Solutions and Deployment

“Where do SharePoint sites come from?”
In a WSS environment, each and every site is created from a site definition. Therefore, we must first explain what a site definition is and show you how to create and deploy one.
Site Definitions
A site definition is the top-level component in WSS that aggregates smaller, more modular definitions to create a complete site template that can be used to provision sites. For example,a site definition usually includes a custom page template for the site’s home page and can additionally reference external features to add support for other types of site-specific elements such as custom lists, secondary pages, and Web Parts.
In WSS, every site is provisioned from a specific site definition. This is true for all top-level sites as well as child sites nested within a site collection. Once a site is provisioned from a particular site definition, it picks up a dependency on that site definition that remains in effect for the lifetime of the site. A site’s dependency on its underlying site definition can never be removed or changed.
Let’s now move on to a discussion of how site definitions are structured and deployed. Similar
to a WSS feature, a site definition is defined with a set of Collaborative Application Markup Language (CAML)-based files that are deployed within a named directory on the file system of each front-end Web server in the farm. Site definitions are deployed within the 12\TEMPLATE\SiteTemplates directory and are referenced in the 12\TEMPLATE\\XML directory in WEBTEMP.XML files, where the folder is the locale identifier (12\TEMPLATE\1033\XML for US English).
A site definition named STS provides familiar site templates such as Team Site, Blank Site, and Document Workspace. You can always back up a site created from one of these site templates and restore it on another farm because the STS site definition is guaranteed to be pre-installed in any farm running WSS 3.0.
A site definition contains one or more configurations, and these configurations are what appear to users as creatable site templates. Therefore, the STS site definition contains three different configurations: Team Site, Blank Site, and Document Workspace.
Tip When creating a new site by using the STSADM.EXE command-line utility or through custom code, you are often required to reference a site definition and one of its configurations by name. This is done by specifying the name of the site definition followed by the pound sign and the integer identifier of the configuration. For example, you can use STS#0 to reference the site template titled Team Site and STS#1 to reference the site template titled Blank Site. The following example uses one of these site template references when creating a new
top-level site by using the STS command-line utility.
STSADM.EXE -o createsite -url http://litwareinc.com
-ownerlogin LITWAREINC\Administrator
-owneremail administrator@Litwareinc.com
-sitetemplate STS#1
A site definition named MPS contains five different configurations for the various Meeting Workspace site templates.Two site definitions are named Blog and Wiki, and each contains a single configuration for creating blog sites and wiki sites. Finally, a site definition named CENTRALADMIN provides the site template used to create the top-level site used in the WSS Central Administration Web application.
The Global Site Definition
WSS 3.0 introduces the Global site definition, which provides a common repository for site provision instructions required by every site definition. This new approach significantly improves the structuring of site definitions over the way things were previously structured in Microsoft Windows SharePoint Services 2.0, in which common provision instructions had to be included as redundant XML in each site definition. The Global site definition refactors more than 2,600 lines of required common components, such as Base Types and required Galleries, which were previously required in the ONET.XML file of every site definition.
The Global site definition is located at the 12\TEMPLATES\GLOBAL path. It contains the standard default.master page template along with instructions to provision an instance of default.master page into the Master Page gallery of every new site. The Global site definition also contains provisioning logic to create the following four site collection–scoped lists in every new top-level site:
■ Web Parts gallery
■ List Template gallery
■ Site Template gallery
■ User Information Profile list

Designing Site Pages by Using Controls

Custom controls are more lightweight and must be compiled into an assembly DLL before being deployed to the front-end Web server.
Constructing Pages with Custom Controls
developers often choose to create custom controls by deriving from a richer class named WebControl, which inherits from the Control class.
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.SharePoint;
namespace CustomSitePages {
public class CustomControl1 : WebControl {
protected override void RenderContents(HtmlTextWriter output) {
SPWeb site = SPContext.Current.Web;
output.Write("Current Site: " + site.Title);
output.Write("
");
output.Write("Current Site ID: " + site.ID.ToString());
} } }
You have two choices as to where to deploy an assembly DLL that contains a custom control when you want to use it in a site page. First, you can compile the assembly DLL with a strong name and install it in the Global Assembly Cache. Alternatively, you can deploy the assembly DLL by placing it inside the root directory of the hosting Web application inside a nested directory named bin. Note that when you plan to deploy the assembly DLL with custom controls in the bin directory, you have the option of compiling it with or without a strong name.Once the assembly DLL with the custom control is properly deployed, you can then reference it within a page template by using the ASP.NET Register directive. The following code example
displays a page template that uses the custom control shown previously.
%@ Page MasterPageFile="~masterurl/default.master"
meta:progid="SharePoint.WebPartPage.Document" %>
%@ Register Assembly="CustomSitePages, ... "
Namespace="CustomSitePages" TagPrefix="CustomSitePages" %>
asp:Content ID="main"
ContentPlaceHolderId="PlaceHolderMain"
runat="server">
h3>A custom control example/h3>
CustomSitePages:CustomControl1 ID="cc1" runat="server" />
/asp:Content>
This TagPrefix value is then used to instantiate instances of the control within the page.
CustomSitePages:CustomControl1 ID="cc1" runat="server" />

When you navigate to .aspx, you should see that the page renders the output of the
control so that it is visible to the user. However, this works only while the hosting page remains in a ghosted state. Remember that customized pages allow only for controls that are registered as safe controls. If a user customizes Page02.aspx with the SharePoint Designer, the page begins to execute in safe mode, and the presence of a control that is not registered as a safe control results in the error message.
To fix this problem, you must add a custom SafeControl entry to the hosting Web
application’s web.config file. You can accomplish this by adding a SafeControl entry that looks like the following:
SafeControl
Assembly="CustomSitePages, ..."
Namespace="CustomSitePages"
TypeName="CustomControl1"
/>
Constructing Pages with User Controls
The ASP.NET runtime provides the functionality to parse these .ascx files at run time and compile them into assembly DLLs just as it does for .aspx files.
Let’s examine the source file for a simple user control. The following example of an .ascx file creates a simple user interface with a command button and a label and adds in an event handler to provide the classic “Hello World” functionality.
%@ Control Language="C#" %>
script runat="server">
protected void cmdButton1_Click(object sender, EventArgs e) {
lblStatus.Text = "Hello, World";
}
/script>
asp:Button ID="cmdAddCustomer" runat="server" Text="Add Customer"
OnClick="cmdAddCustomer_Click" />
br/>
asp:label id="lblStatus" runat="server" text="">
User controls are always loaded from the file system of the front-end Web server and
compiled into assembly DLLs. Furthermore, user controls can be copied to the front-end Web server only by someone with farm-level administrative privileges. For these reasons, you can assume that you can always write in-line code in an .ascx file.
In Chapter 2, you were introduced to the virtual _layouts directory and learned that this was the proper place to deploy application pages. WSS provides a similar virtual directory for deploying user controls. Inside the TEMPLATE directory resides a nested directory named CONTROLTEMPLATES.
Fortunately, you don’t have to worry about this if you deploy your custom user controls inside the virtual _controltemplates directory because the standard web.config file for a Web application already contains the following SafeControl entry:
SafeControl
Src="~/_controltemplates/*"
IncludeSubFolders="True"
Safe="True"
AllowRemoteDesigner="True"
/>
Now that you have seen how to create and properly deploy a user control, the final step is constructing a page template that references the .ascx file and creates an instance. However, the process is different with user controls because the Register
directive requires an src attribute that points to the virtual path of the target .ascx file.
%@ Page MasterPageFile="~masterurl/default.master"
meta:progid="SharePoint.WebPartPage.Document" %>
%@ Register TagPrefix="luc" TagName="UserControl1"
src="~/_controltemplates/Litware/UserControl1.ascx" %>
asp:content runat="server" contentplaceholderid="PlaceHolderMain">
luc:usercontrol1 id="id1" runat="server">
/asp:Content>
Designing Web Part Pages
Web Parts go even further to allow individual users to add personalization changes that are seen only by them.WSS provides the underlying mechanisms to track all of this customization and personalization inside the content database along with all of the other site-related data.
All of the data for tracking Web Part instances and their customization and personalization data are kept in separate tables inside the content database.This means that a Web Part page can remain in a ghosted state even though users are continually adding, customizing, and personalizing the Web Parts within its zone.
To create a Web Part page in an ASP.NET 2.0 application, you must create an .aspx page that contains exactly one instance of a control named WebPartManager and one or more WebPartZone controls. The WebPartManager is responsible for managing the lifetime of Web Part instances as well as serializing Web Part–related data so that they can be stored and retrieved from the tables in the ASP.NET services database.
WSS relies on a specialized control named SPWebPartManager that derives from the ASP.NET 2.0 WebPartManager control. The SPWebPartManager control overrides the standard behavior of the WebPartManager control to persist Web Part data inside the WSS content database instead of inside the ASP.NET services database.
Two things must be done when creating a page template for a Web Part page. The first is to inherit from the WebPartPage class that is defined inside the Microsoft.SharePoint.dll assembly. The second is to add one or more WebPartZone controls.To add WebPartZone controls to a page template, you must add a Register directive that imports all of the controls from the Microsoft.SharePoint.dll assembly defined in the Microsoft.SharePoint.WebPartPages namespace as shown in the following page template definition.
%@ Page Language="C#" MasterPageFile="~masterurl/default.master"
Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage,Microsoft.SharePoint,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c"
meta:progid="SharePoint.WebPartPage.Document" %>

%@ Register Tagprefix="WebPartPages"
Namespace="Microsoft.SharePoint.WebPartPages"
Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

asp:content id="main" runat="server" contentplaceholderid="PlaceHolderMain">

h3>Custom Web Part Page/h3>

table width="100%">
tr>
td valign="top" style="width:50%">

/td>
td valign="top" style="width:50%">
WebPartPages:WebPartZone ID="Right" runat="server"
FrameType="TitleBarOnly"
Title="Right Web Part Zone" />
/td>
/tr>
/table>
/asp:Content>


There are two common techniques for adding a Web Part instance to a Web Part zone. The first technique involves a declarative approach used inside a feature in which you define an AllUsersWebPart element inside a File element. The following example demonstrates the File element that is used in the CustomSitePages project to provision the Web Part page named WebPartPage02.aspx.
Elements xmlns="http://schemas.microsoft.com/sharepoint/">
Module Path="PageTemplates" Url="SitePages" >

File Url="WebPartPage.aspx" Name="WebPartPage03.aspx" Type="Ghostable" >

AllUsersWebPart WebPartZoneID="Left" WebPartOrder="0">

Assembly>Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
TypeName>Microsoft.SharePoint.WebPartPages.ContentEditorWebPart
Title>Yet Another Web Part is Born/Title>
FrameType>TitleBarOnly
cewp:Content>
This Web Part was added through declarative logic
/cewp:Content>
/WebPart>
]]>
/AllUsersWebPart>

AllUsersWebPart WebPartZoneID="Right" WebPartOrder="0">

Assembly>Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
TypeName>Microsoft.SharePoint.WebPartPages.ImageWebPart
FrameType>None
Title>Watch My Gears Run/Title>
iwp:ImageLink>/_layouts/images/GEARS_AN.GIF
/WebPart>
]]>
/AllUsersWebPart>
/File>
/Module>
/Elements>
The second technique for adding a Web Part instance to a Web Part page involves writing code against the WSS object model. An example of this type of code is supplied in the FeatureActivated event handler for the CustomSitePages project. The code obtains a reference to the SPFile object associated with WebPartPage03.aspx and uses an SPLimitedWebPart-Manager object to add a new Web Part instance to a particular target zone.
public override void FeatureActivated(
SPFeatureReceiverProperties properties) {
// acquire objects for site, page and limited Web Part Manager
SPWeb site = (SPWeb)properties.Feature.Parent;
SPFile page = site.GetFile("SitePages/WebPartPage03.aspx");
SPLimitedWebPartManager mgr;
mgr = page.GetLimitedWebPartManager(PersonalizationScope.Shared);
// add Web Part to Right Zone
ImageWebPart wp1 = new ImageWebPart();
wp1.ChromeType = PartChromeType.None;
wp1.ImageLink = @"/_layouts/images/IPVW.GIF";
mgr.AddWebPart(wp1, "RightZone", 0);
}
Master Pages
The pages that link to a master page are known as content pages. Standard master page is deployed during the standard WSS installation on the file system of the front-end Web server at the following path (there is a line break in the file path to make it more readable).
C:\Program Files\Common Files\Microsoft Shared
\web server extensions\12\TEMPLATE\GLOBAL\default.master
Whenever you create a new site, WSS provides provisioning instructions to create the Master Page gallery and provision an instance of default.master within the site by using a standard site-relative path.
/_catalogs/masterpage/default.master
The default.master page contains the basic layout for a site page including elements such as HTML, HEAD, BODY, and FORM. Within these standard HTML elements, you will find three important types of components:
■ Controls for links, menus, icons, and navigation components
■ Named placeholders
■ Delegate controls
The top link bar is defined by using a WSS-specific control of type AspMenu along with a SiteMapDataSource control that is configured to point to the standard SPNavigationProvider component. The Quick Launch menu is defined in the same way. The major difference between the two is that the SiteMapDataSource for the top link bar is configured with a StartingNodeUrl attribute with a value of sid:1002, whereas the Quick Launch menu is configured with a StartingNodeUrl attribute with a value of sid:1025.
The next question you should be asking is what the significance is between 1002 and 1025. It has to do with the data stored in the content database for tracking navigation nodes. The top node for the top link bar has an ID of 1002, and the top node to the Quick Launch menu has an ID of 1025.
The CustomSitePages feature provides code in the FeatureActivated event handler to add navigation nodes to construct a custom drop-down menu in a fashion that is not possible to replicate through the user interface. Examine the following code and observe how it creates SPNavigationNode objects and adds them to the collection of nodes that define the structure for the top link bar.
public override void FeatureActivated(SPFeatureReceiverProperties properties) {
// get a hold of current site in context of feature activation
SPWeb site = (SPWeb)properties.Feature.Parent;
SPNavigationNodeCollection topNav = site.Navigation.TopNavigationBar;
// create dropdown menu for custom site pages
SPNavigationNode DropDownMenu1;
DropDownMenu1 = new SPNavigationNode("Site Pages", "", false);
topNav[0].Children.AddAsLast(DropDownMenu1);
// add navigation nodes to create menu items
DropDownMenu1.Children.AddAsLast(
new SPNavigationNode( "Site Page 1",
"SitePages/Page01.aspx"));
DropDownMenu1.Children.AddAsLast(
new SPNavigationNode("Site Page 2",
"SitePages/Page02.aspx"));
}
Delegate Controls
Like a placeholder, a delegate control can optionally supply default content that is used until a substitution is performed.
One major difference when compared to placeholders is that the substitution mechanism for replacing the contents of a delegate control is driven through feature activation. Therefore, you can replace what’s defined inside a delegate control in default.master without requiring any changes to default.master or the site pages that link to it. All you need to do is define a Control element within a feature and then activate that feature.
SmallSearchInputBox delegate control by referencing a built-in user control with the standard WSS search area content.
control
Id="SmallSearchInputBox"
Sequence="100"
ControlSrc="~/_controltemplates/searcharea.ascx"
/>
Assume that you want to get rid of the standard search area content and replace it with your own custom content for a particular business solution. That’s what delegate controls were designed for.
If you want to replace a delegate control, such as the WSS search area, with your own customized version, you start by adding a Control element to a feature. The Control element should have an ID value of SmallSearchInputBox. The Control element should also have a Sequence number smaller than any other active Control element pointing to the same ID. The following code demonstrates how the Control element is defined inside the elements.xml file of the CustomBranding feature.

Note that this Control element has a sequence number of 10, which is smaller than the Control element defined in ContentLightup with a Sequence number of 100. Once the CustomBranding feature is activated within a site collection, all of the site pages that link to default.master replace the standard WSS search area with whatever content you have defined inside the custom user control named LitwareSearchArea.ascx. The following code defines a starting point for creating a custom user control that supplies custom search behavior.
%@ Control Language="C#" %>
script runat="server">
protected void cmdRunSearch_Click(object sender, EventArgs e) {
// add customer search here
txtSearchText.Text = "Hello";
}
/script>

table>
tr>
td>
td>
/tr>
/table>
Creating a Custom Master Page Template
Creating a custom master page template involves several steps. First, you must create the master page template itself. Second, you must create a custom feature that provisions an instance of this master page template inside the Master Page gallery for a specific site. Finally, you need to add some code to redirect site pages to use your custom master page instead of using default.master. The Visual Studio project named CustomBranding provides a working sample that demonstrates how all of the pieces fit together.
You can create a custom template by using two different approaches. First, you can make a copy of default.master and then modify it according to taste. A second approach involves starting from scratch so that you can design the exact HTML layout you’re looking for. The custom master page template used in the CustomBranding project is named Litware.master. The Litware.master template is a variation on the default.master template with changes to allow for fly-out menus on both the top link bar and Quick Launch menu. The CustomBranding feature includes a Module element that has been designed to provision an instance of the Litware.master page template into the Master Page gallery of the top-level site.
Module Name="MasterPages" List="116" Url="_catalogs/masterpage">
File Url="Litware.master" Type="GhostableInLibrary" />
/Module>
However, this Module targets the Master Page gallery, which is a special type of document library. Therefore, the Module is defined with a List attribute of 116, which is the list type identifier for the Master Page gallery. The Url attribute for this Module is defined with a value of _catalogs/masterpage,
which is the standard site-relative path to the Master Page gallery.
We have reviewed the steps involved in creating a master page template and provisioning an instance of it in the Master Page gallery of the top-level site. The next step involves redirecting all site pages within a site to link to this provisioned instance of our custom master page template. To understand the technique for accomplishing this, take a closer look at the MasterPageFile attribute defined within a Page directive. Examine the following page template, which is defined to link to a target master page by using a special syntax in the form of ~masterurl/default.master.
%@ Page MasterPageFile="~masterurl/default.master" %>
asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
Custom content goes here
/asp:Content>
You can redirect any site page that uses this token by acquiring an SPWeb reference to the current site and then updating the MasterUrl property.
SPWeb site = SPContext.Current.Web;
string MasterUrlPath = site.ServerRelativeUrl;
if (!MasterUrlPath.EndsWith(@"/"))
MasterUrlPath += @"/";
MasterUrlPath += @"_catalogs/masterpage/Litware.master";
site.MasterUrl = MasterUrlPath;
site.Update();
Once you
activate the CustomBranding feature, you can navigate to the application page named
CustomBrand.aspx by using a custom menu item that is added to the Site Settings menu. This application page provides a command button that allows the user to execute the following code.
protected void cmdApplyCustomBrand_Click(object sender, EventArgs e) {
SPWeb site = SPContext.Current.Site.RootWeb
string MasterUrlPath = site.ServerRelativeUrl;
if (!MasterUrlPath.EndsWith(@"/"))
MasterUrlPath += @"/";
MasterUrlPath += @"_catalogs/masterpage/Litware.master";
ApplyCustomBrand(MasterUrlPath, site);
}
protected void ApplyCustomBrand(string MasterUrlPath, SPWeb site) {
site.MasterUrl = MasterUrlPath;
site.Update();
// use recusion to update all child sites in site collection
foreach (SPWeb child in site.Webs) {
ApplyCustomBrand(MasterUrlPath, child);
}
}
The file that defines the majority of the standard CSS classes used by pages in WSS is named core.css.
SPWeb site = SPContext.Current.Web;
site.ApplyTheme("");
site.AlternateCssUrl = "/_layouts/1033/STYLES/Litware/LitwareBrand.css";
site.Update();

Working with Page Templates

When the CustomSitePages feature is activated, it contains declarative logic in elements.xml to provision site page instances from its page templates. The code in the FeatureActivated event extends the navigation components of a WSS site by adding two new drop-down menus to the top link bar with menu items to navigate to the newly provisioned site page instance.

Let’s start with a simple definition for a page template. Examine the following definition for the page template named Page01.aspx.
%@ Page MasterPageFile="~masterurl/default.master"
meta:progid="SharePoint.WebPartPage.Document" %>
asp:Content runat="server" ContentPlaceHolderID="PlaceHolderMain">
h3>Hello World
A simple page template used to create site pages
/asp:Content>
meta:progid attribute is included to make that page compatible with the SharePoint Designer, and is also available in the SPFile object’s ProgID property. Once site page instances have been provisioned by using this page template, users can open these pages with the SharePoint Designer and customize their content.
Keep in mind that a page template, such as Page01.aspx, serves no purpose until you begin using it to provision site page instances. This can be done by creating a feature that contains a special type of element known as a Module.
When you create a Module, you add one or more inner File elements. The key point is that each File element is used to provision an instance of a file from a file template. Remember that the file template exists on the file system of the front-end Web server.
elements xmlns="http://schemas.microsoft.com/sharepoint/">
/u>
file url="Page01.aspx" type="Ghostable">
/module>
/elements>
Note that the File element within this example is created with a Url attribute that points to the source file for the page template. When you activate a feature that contains this Module element, WSS provisions a site page instance within the target site at the following relative path.SitePages/Page01.aspx
Note that the File element in the previous example contains a Type attribute with a value of Ghostable. When a site page instance, such as Page01.aspx, is provisioned, it initially exists in an uncustomized state and benefits from the principles of page ghosting. This means that you can activate this feature in a thousand different sites within a Web application and that all sites use a single compiled version of the page. Page ghosting also makes it possible to make changes to the page template on the file system of the front-end Web server and have those changes affect all of the sites that have pages provisioned from this page template.
Only two possible settings exist for the Type attribute: Ghostable and GhostableInLibrary.These two settings are used to differentiate between files that are provisioned inside a document library and those that are not. In this case, the site page instance has a Type of Ghostable because it is not being provisioned inside a document library. Later in the chapter, you will encounter an example of a File element whose Type attribute value will be defined as GhostableInLibrary.
Safe Mode Processing
It’s important to understand that all customized site pages are parsed and processed in a
special mode known as safe mode. The primary motivation for safe mode involves the
fact that standard users can modify the contents of site pages. In other words, a user (such
as a site owner) possessing no administrator privileges within the farm can make any
modifications to a page within a site. Consider a scenario in a large farm in which a site
administrator attempts to mount an attack on the Web server by writing C# code within a
customized site page inside an in-line script block. Safe mode prevents this type of attack by
disallowing in-line script in any customized source.
Examine the code in the page template named Page02.aspx. It contains a simple in-line script
to write a message back to the browser.
%@ Page Language="C#" MasterPageFile="~masterurl/default.master"
meta:progid="SharePoint.WebPartPage.Document" %>
asp:Content ID="main" runat="server"
ContentPlaceHolderID="PlaceHolderMain">
h3>Page 2


% Response.Write("Hello world from server-side script!"); %>
/asp:Content>
Note that this page and the in-line script run just fine as long as the page remains uncustomized in a ghosted state. Remember that WSS compiles a ghosted page into an assembly DLL for processing. However, as soon as a user modifies any aspect of this page with the SharePoint Designer and moves the site page into an unghosted state, WSS then begins to use safe mode to process it. Because the page contains in-line script, WSS refuses to process it in safe mode and generates the error message. For this reason, you should avoid adding in-line script to page templates.
For example, assume that you want to allow in-line scripts for site pages inside the SitePages folder in a site at the path of /sites/Sales. You can accomplish this by adding the following PageParserPath element
within the SharePoint section of the web.config file.
SharePoint>
SafeMode ... >
PageParserPaths>
PageParserPath
VirtualPath="/sites/Sales/SitePages/*"
IncludeSubFolders="true"
CompilationMode="Always"
AllowServerSideScript="true" />
/PageParserPaths>
/SafeMode>
/SharePoint>
If you examine the PageParserPath element, you see that the VirtualPath attribute has a Web application relative path followed by an asterisk, which includes every site page in that particular folder. Also note that the CompilationMode attribute has a value of Always and the AllowServerSideScript attribute has a value of true. This instructs the safe mode parser to compile all site pages into assembly DLLs and allow in-line script.
At the very least, you should prefer a Compilation-Mode setting of Auto instead of Always so that only pages that actually contain script are compiled into assembly DLLs, whereas those pages that do not contain script continue to be parsed and processed in no-compile mode.
Safe Controls
Tells what controls a user might place on a customized page. Safe mode allows the farm administrator to determine which controls can be used in pages that are processed in safe mode.
Customized pages can only contain server-side controls that are explicitly registered as safe controls. Registering a control as a safe control is accomplished by adding a SafeControl entry into the web.config file for the hosting Web application.
SafeControls>
SafeControl
Assembly="Microsoft.SharePoint, …"
Namespace="Microsoft.SharePoint.WebControls"
TypeName="*"
AllowRemoteDesigner="True" />
/SafeControls>

Pages and Design

Application pages have an advantage over site pages in that they perform better and provide a developer with the ability to add in-line code. You also learned that site pages have some key advantages over application pages because they can be created dynamically and can also be customized by users on a site-by-site basis.
Page ghosting is an optimization used with site pages in which a single page template can be used to process multiple page instances across many different sites. For example, the home page for every team site in a Microsoft Windows SharePoint Services (WSS) farm is based on an underlying page template named default.aspx that resides on the file system of the front-end Web server. A page template, such as default.aspx, is compiled into an assembly dynamic-link library (DLL) and loaded into memory just once per Web application. However, this page template and its efficient usage of memory can still be used to serve up pages for thousands of sites. This is an obvious advantage toward scalability.

When a user customizes a site page by using the SharePoint Designer and then saves those changes, a customized version of the page definition is stored in the content database. While this provides flexibility from a customization standpoint, it also can have a negative impact on performance and scalability. When the customized page is requested, its page definition must be retrieved from the Backend database server by the SPVirtualPathProvider component and then fed to the ASP.NET compiler, where it is parsed and loaded into memory. You can imagine that a Web application with thousands of customized pages requires more memory
because each customized page definition must be separately parsed and loaded into memory within the application pool that is hosting the current Web application. You should note that customized pages are not processed by using the standard ASP.NET model in which a page is compiled into an assembly DLL. Instead, customized pages are parsed by the ASP.NET page parser(parsing means reading once again…) and then processed using the no-compile mode feature that was introduced with ASP.NET 2.0.
No-compile pages can be loaded into memory and then unloaded in a manner that is not
possible for compiled pages because the .NET Framework doesn’t really support the concept of unloading an assembly DLL from memory. The closest equivalent would be to recycle the current Windows process or the current .NET AppDomain. However, this type of recycling involves unloading all assembly DLLs from memory, not just those assembly DLLs that haven’t been used recently. Furthermore, the .NET Framework places an upper limit on the number of assembly DLLs that can be loaded into a .NET AppDomain.
No-compile pages provide higher levels of scalability because they do not require loading new assembly DLLs or managed classes into memory. Instead, the processing of no-compile pages involves loading control trees into memory. WSS can manage the memory usage for the control trees associated with customized pages more efficiently because they are not compiled into assembly DLLs. For example, once WSS has finished processing a customized page, it can unload the page’s control tree to free up memory for other purposes. Furthermore, nocompile pages eliminate the need to go through the compilation process, which actually provides faster response times for pages upon first access.
In ASP.NET2.0 dynamic compilation means –asp.net parser take .aspx &.cs file then parse and compiled it.There is no dll files.

Programming with SPFile Objects
WSS tracks each site page as a file within the content database. You can access a site page through the WSS object model by using the SPFile object. For example, assume that you want to program against the home page for a site. You can obtain a reference to the required SPFile object by using the GetFile method of a SPWeb object.
SPWeb site = SPContext.Current.Web;
SPFile homePage = site.GetFile("default.aspx");
The SPFile class makes it possible to read and write to the contents of a site page. For example,the OpenBinary method of an SPFile object returns a binary array containing the page contents. The OpenBinaryStream method returns a System.IO.Stream object. Each of these methods provides an approach for reading the contents of a site page. An SPFile object also provides a SaveBinary method that allows you to update the contents of a site page as well.Note that updating the contents of a site page by using this method customizes the page and moves it into an customized or unghosted state.
Tip Ghosted and uncustomized are terms used to describe site pages served up using file system templates. Unghosted and customized both refer to pages that exist entirely in the database, which no longer depend on a file system template.
// write out new page in memory stream
MemoryStream stream = new MemoryStream();
StreamWriter writer = new StreamWriter(stream);
writer.WriteLine("");
writer.WriteLine("Hello, World");
writer.WriteLine("");
writer.Flush();
// add new page to site
SPWeb site = SPContext.Current.Web;
site.Files.Add("hello.htm", stream);
The SPFile class provides a CustomizedPageStatus property that makes it possible to determine whether a site page has been customized and placed in an unghosted state. The SPFile object also provides a method named RevertContentStream that removes any customizations and returns an unghosted page to its initial ghosted state.

SPFolder Objects
Each SPFolder object contains a Files property that allows you to enumerate through its files. If you want to enumerate through all of the files at the root folder of a site, you can access the RootFolder property of a SPWeb object and then use a foreach loop to enumerate through all of its files.
SPWeb site = SPContext.Current.Web;
SPFolder rootFolder = site.RootFolder;
foreach (SPFile file in rootFolder.Files){
// process each file
}
The following code displays an example of custom
code that starts at the root folder of a site and uses recursion to populate an ASP.NET
TreeView control.
const string SITE_IMG = @"\_layouts\images\FPWEB16.GIF";
const string FOLDER_IMG = @"\_layouts\images\FOLDER16.GIF";
const string GHOSTED_FILE_IMG = @"\_layouts\images\NEWDOC.GIF";
const string UNGHOSTED_FILE_IMG = @"\_layouts\images\RAT16.GIF";
protected override void OnLoad(EventArgs e) {
SPWeb site = SPContext.Current.Web;
SPFolder rootFolder = site.RootFolder;
TreeNode rootNode = new TreeNode(site.Url, site.Url, SITE_IMG);
LoadFolderNodes(rootFolder, rootNode);
treeSiteFiles.Nodes.Add(rootNode);
treeSiteFiles.ExpandDepth = 1;
}
protected void LoadFolderNodes(SPFolder folder, TreeNode folderNode) {
foreach (SPFolder childFolder in folder.SubFolders) {
TreeNode childFolderNode = new TreeNode(childFolder.Name,
childFolder.Name,
FOLDER_IMG);
LoadFolderNodes(childFolder, childFolderNode);
folderNode.ChildNodes.Add(childFolderNode);
}
foreach (SPFile file in folder.Files) {
TreeNode fileNode;
if (file.CustomizedPageStatus == SPCustomizedPageStatus.Uncustomized) {
fileNode = new TreeNode(file.Name, file.Name, GHOSTED_FILE_IMG);
}
else {
fileNode = new TreeNode(file.Name, file.Name, UNGHOSTED_FILE_IMG);
}
folderNode.ChildNodes.Add(fileNode);
}
}

Site Pages versus Application Pages

Pages that support user customization are known as site pages. Every one of these site pages would become unghosted. This would negatively impact scalability by forcing the front-end Web server to retrieve each page separately from the content database. Each page would also have to be individually parsed and loaded into memory.

There is only one version of an application page scoped at the farm level, it can be
compiled into a single DLL and loaded into memory once for each Web application. You
never have to worry about the existence of different versions of an application page for different sites. Furthermore, application pages are not subject to attack from users who have permissions to customize site pages. Therefore, WSS does not prohibit them from containing in-line code.
There is only one version of an application page scoped at the farm level, it can be
compiled into a single DLL and loaded into memory once for each Web application.
Let us now summarize the difference between site pages and application pages. Site pages support page customization. Examples of site pages include the home page (default.aspx) for a site as well as the pages associated with lists and document libraries, such as AllItems.aspx, NewForm.aspx, and EditForm.aspx. The fact that site pages support customization provides flexibility but can also impact performance and scalability.Application pages do not support customization, which gives them two distinct advantages over site pages. First, each application page is always compiled into a single DLL so that it performs and scales better than a site page. Second, application pages are allowed to have in-line code.
Creating Custom Application Pages
As a rule, application pages should derive from a base class in the Microsoft.SharePoint assembly named LayoutsPageBase.

ApplicationPage1.aspx
%@ Assembly Name="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" % >
%@ Assembly Name="CustomApplicationPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d4e5777b16a5749f" % >

%@ Page Language="C#" MasterPageFile="~/_layouts/application.master"
Inherits="CustomApplicationPages.ApplicationPage1"
EnableViewState="false" EnableViewStateMac="false" %>

asp:content id="Main" contentplaceholderid="PlaceHolderMain" runat="server">
table border="1" cellpadding="4" cellspacing="0" style="font-size:12">
tr>
td>Site Title:
td>
/tr>
tr>
td>Site ID:
td>
/tr>
/table>
/asp:Content>
asp:Content ID="PageTitle" runat="server"
contentplaceholderid="PlaceHolderPageTitle" >
Hello World
/asp:Content>
asp:Content ID="PageTitleInTitleArea" runat="server"
contentplaceholderid="PlaceHolderPageTitleInTitleArea" >
Application Page 1: 'Hello World' with code behind
/asp:Content>
ApplicationPage1.cs
using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;

namespace CustomApplicationPages {

public class ApplicationPage1 : LayoutsPageBase {

// add control fields to match controls tags on .aspx page
protected Label lblSiteTitle;
protected Label lblSiteID;

protected override void OnLoad(EventArgs e) {

// get current site and web
SPSite siteCollection = this.Site;
SPWeb site = this.Web;

// program against controls on .aspx page
lblSiteTitle.Text = site.Title;
lblSiteID.Text = site.ID.ToString().ToUpper();
}

}
}
Creating an Application Page with the SPGridView Control
You can see that the class named ApplicationPage2 works together with a custom helper class named PropertyCollectionBinder to create an ADO.NET DataTable object filled with information about the current site and site collection. The DataTable object is being used in this example because its contents can be used to populate SPGridView by using standard ASP.NET data binding techniques.
protected override void OnLoad(EventArgs e)
{
SPSite siteCollection = this.Site;
SPWeb site = this.Web;
// PropertyCollectionBinder pcb = new PropertyCollectionBinder();
PropertyCollectionBinder pcb = new PropertyCollectionBinder();
pcb.AddProperty("Site Title", site.Title);
pcb.AddProperty("Site ID", site.ID.ToString().ToUpper());
pcb.AddProperty("Site Master Page Url", site.MasterUrl);
pcb.AddProperty("Site URL", site.Url);
pcb.AddProperty("Site Collection URL", siteCollection.Url);
pcb.AddProperty("Site Collection ID", siteCollection.ID.ToString().ToUpper());
pcb.AddProperty("Current User Name", site.CurrentUser.Name);
pcb.AddProperty("Is User Site Collection Admin", site.UserIsSiteAdmin.ToString());
pcb.AddProperty("Is User Site Admin", site.UserIsWebAdmin.ToString());
pcb.AddProperty("Site User Count", site.SiteUsers.Count.ToString());
pcb.AddProperty("Host Name", siteCollection.HostName);
pcb.AddProperty("Zone", siteCollection.Zone.ToString());
pcb.AddProperty("Site Collection System Account", siteCollection.SystemAccount.Name);
pcb.BindGrid(grdPropertyValues);
}
%@ Assembly Name="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
%@ Assembly Name="CustomApplicationPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d4e5777b16a5749f" %>

%@ Page Language="C#" MasterPageFile="~/_layouts/application.master"
Inherits="CustomApplicationPages.ApplicationPage2"
EnableViewState="false" EnableViewStateMac="false" %>

%@ Register Tagprefix="SharePoint"
Namespace="Microsoft.SharePoint.WebControls"
Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

asp:content id="Main" contentplaceholderid="PlaceHolderMain" runat="server">

SharePoint:SPGridView runat="server"
ID="grdPropertyValues"
AutoGenerateColumns="false"
RowStyle-BackColor="#DDDDDD"
AlternatingRowStyle-BackColor="#EEEEEE" />

/asp:Content>
PropertyCollectionBinder.cs
{

protected DataTable PropertyCollection = new DataTable();

public PropertyCollectionBinder() {
PropertyCollection.Columns.Add("PropertyName", typeof(string));
PropertyCollection.Columns.Add("PropertyValue", typeof(string));
}

public void AddProperty(string PropertyName, string PropertyValue) {
DataRow newRow = PropertyCollection.Rows.Add();
newRow["PropertyName"] = PropertyName;
newRow["PropertyValue"] = PropertyValue;
}

public void BindGrid(SPGridView grid) {

SPBoundField fldPropertyName = new SPBoundField();
fldPropertyName.HeaderText = "Property Name";
fldPropertyName.DataField = "PropertyName";
grid.Columns.Add(fldPropertyName);

SPBoundField fldPropertyValue = new SPBoundField();
fldPropertyValue.HeaderText = "Value";
fldPropertyValue.DataField = "PropertyValue";
grid.Columns.Add(fldPropertyValue);

grid.Width = new Unit(400);

grid.AutoGenerateColumns = false;
grid.DataSource = PropertyCollection.DefaultView;
grid.DataBind();


}
}
Restricting Application Pages to Site Administrators
Application pages are often designed to provide information and functionality
that should only be accessible to site administrators.
Let’s start by revisiting the creation of a CustomAction element within a feature. You can add an attribute named RequireSiteAdministrator and assign it a value of true so that the menu item only displays to those users who are also site administrators.
RequireSiteAdministrator="True"
While this provides a good start by hiding the menu item from users who are not site
administrators, it doesn’t provide a truly secure solution. The application page itself will still be accessible to any user who knows the URL. When you want to lock down an application page in a secure manner, you can accomplish this by overriding the RequireSiteAdministrator property of the LayoutsPageBase base class as shown in the following code.
public class ApplicationPage3 : LayoutsPageBase {
protected override bool RequireSiteAdministrator {
get { return true; }
}
protected override void OnLoad(EventArgs e) {
// your code goes here
} }
{
// get current site and web
SPSite siteCollection = this.Site;
SPWeb site = this.Web;

lblSiteTitle.Text = site.Title;
lblSiteUrl.Text = site.Url.ToLower();
lblSiteCollectionUrl.Text = siteCollection.Url.ToLower();
lstLists.Items.Clear();
foreach (SPList list in site.Lists) {
lstLists.Items.Add(list.Title);
}
lstLists.Rows = lstLists.Items.Count;
lstSiteUsers.Items.Clear();
foreach (SPUser user in site.SiteUsers) {
lstSiteUsers.Items.Add(user.Name);
}
lstSiteUsers.Rows = lstSiteUsers.Items.Count;

}
Adding a Custom Menu Item to the ECB (EditControlBlock)Menu

CustomAction Id="CustomApplicationPage4"
RegistrationType="List"
RegistrationId="101"
ImageUrl="/_layouts/images/GORTL.GIF"
Location="EditControlBlock"
Sequence="240"
Title="Application Page 4" >
urlaction url="~site/_layouts/CustomApplicationPages/ApplicationPage4.aspx?ItemId={ItemId}&ListId={ListId}">
/customaction>
Note that 101 is a list type identifier that applies to all document libraries. WSS dynamically replaces the {ListId} token with the identifying GUID for the current list or document library.
WSS dynamically replaces the {ItemId} token with the integer identifier for the current list item or document.
You can assume that you are dealing with a document library and not simply a standard list type. In these situations, you can add code that converts the SPList object into a SPDocumentLibrary object. You can also access the document in question directly by creating an SPFile object as shown in the following sample.
{

// get current site and web
SPSite siteCollection = this.Site;
SPWeb site = this.Web;

lblSiteTitle.Text = site.Title;
lblSiteUrl.Text = site.Url.ToLower();
string ListId = Request.QueryString["ListId"];
lblListID.Text = ListId;
SPList list = site.Lists[new Guid(ListId)];
lblListTile.Text = list.Title;
lblRootFolderUrl.Text = list.RootFolder.Url;
string ItemId = Request.QueryString["ItemId"];
lblDocumentID.Text = ItemId;
SPListItem item = list.Items.GetItemById(Convert.ToInt32(ItemId));
lblDocumentName.Text = item.Name;
lblDocumentUrl.Text = item.Url;

if (list is SPDocumentLibrary) {
SPDocumentLibrary documentLibrary = (SPDocumentLibrary)list;
lblDocumentTemplateUrl.Text = documentLibrary.DocumentTemplateUrl;

SPFile file = site.GetFile(item.Url);
lblFileAuthor.Text = file.Author.Name;
lblFileSize.Text = file.TotalLength.ToString("0,###") + " bits";
lblFileLastModified.Text = "By " + file.ModifiedBy.Name +
" on " + file.TimeLastModified.ToLocalTime().ToString();
lblFileCheckOutStatus.Text = file.CheckOutStatus.ToString();
}
}
Imp Points
1-If in IIS website has 10 ASP.NET app u have to create explicitly 10 virtual directories.But in WebApp u no need to go Mgr to create Virtual Dir.It is a single process for creaing n no of SiteCollections.
2-For each Asp.net APP u have to maintain 1 web.config.But in MOSS only one web.config for a WEB APP.In this u can maintain n no of site collections.

Sunday, June 8, 2008

SharePoint Architecture

Both ASP.NET and WSS rely on IIS 6.0 to supply the underlying listening mechanism to process incoming HTTP requests and supply a management infrastructure for launching and running worker processes on the Web server.
An IIS Web site provides an entry point into the IIS Web server infrastructure. Each IIS Web site is configured to listen for and process incoming HTTP requests that meet certain criteria.For example, an IIS Web site can be configured to handle requests coming in over a specific IP address or port number or can be routed to the Web server by using a specific host header,such as http://Extranet.Litwareinc.com.
IIS automatically creates and configures an IIS Web site named Default Web Site that listens for HTTP requests coming in over port 80 on any of the IP addresses supported on the local Web server.
Each IIS Web site is configured to map to a root directory, which is a physical directory on the file system of the hosting Web server. For example, standard configuration for IIS maps the Default Web Site to a root directory located at C:\Inetpub\wwwroot. In the most straightforward routing scenarios, IIS maps incoming HTTP requests to physical files inside the root directory.For example, IIS will respond to a request for http://www.Litwareinc.com/page1.htm by simply loading the contents of the file located at c:\Inetpub\wwwroot\page1.htm into memory and streaming it back to the client.
A virtual directory is an entity that defines a child URL space nested within the URL space of its parent IIS Web site. Like an IIS Web site, a virtual directory is configured with a root directory on the file system of the hosting Web server.
Note that IIS tracks configuration information about its IIS Web sites and virtual directories in a repository known as the IIS metabase. The IIS metabase lives on the file system of each front-end Web server running IIS. For example, when you create and configure an IIS Web site using the IIS administration utility, IIS tracks these changes by writing entries to the local IIS metabase.
ISAPI Extensions and ISAPI Filters
In the most straightforward routing scenarios, IIS simply maps an incoming request to a physical file within the root directory of an IIS Web site or virtual directory. However, IIS also supports the Internet Server Application Programming Interface (ISAPI) programming model, which provides the opportunity for more sophisticated routing scenarios. In particular, the ISAPI programming model allows you to configure an IIS Web site or virtual directory so that incoming requests trigger the execution of custom code on the Web server.The ISAPI programming model consists of two primary component types: ISAPI extensions and ISAPI filters.
An ISAPI extension is a component DLL that plays the role of an endpoint for an incoming request. The fundamental concept is that IIS can map incoming requests to a set of endpoints that trigger the execution of code within an ISAPI extension DLL. An ISAPI extension DLL must be installed on the Web server and configured at the level of either an IIS Web site or virtual directory. Configuration commonly involves associating specific file extensions with the ISAPI extensions by using an IIS application map.
While an ISAPI extension serves as an endpoint, an ISAPI filter plays the role of an interceptor(interrupt/stop).An ISAPI filter is installed and configured at the level of the IIS Web site. Once installed, an ISAPI filter intercepts all incoming requests targeting that IIS Web site. The fundamental concept is that an ISAPI filter can provide pre-processing and post-processing for each and every incoming request. ISAPI filters are typically created to provide low-level functionality for an IIS Web site, such as custom authentication and request logging.
Application Pools and the IIS Worker Process
IIS provides a flexible infrastructure for managing worker processes by using application pools. An application pool is a configurable entity that allows you to control how IIS maps IIS Web sites and virtual directories to instances of the IIS worker process. Note that instances of the IIS worker process are launched using an executable named w3wp.exe, as shown in Figure 2-2.

The routing architecture of IIS is controlled by a kernel-level device driver named http.sys.This device driver listens for incoming HTTP requests and uses information in the IIS metabase to route them to whatever instance of w3wp.exe is associated with the target application pool. If http.sys determines that the target application pool doesn’t have a running instance of w3wp.exe, it launches a new instance on demand to process the request.
Every application pool has an important setting known as the application pool identity. The application pool identity is configured with a specific Windows user account that is either a local account on the Web server or a domain account within an Active Directory directory service domain. When http.sys launches a new instance of w3wp.exe for a specific application pool,it uses the application pool identity to initialize a Windows security token that serves as the process token.
ASP.NET 2.0 Framework
The ASP.NET Framework is implemented as an ISAPI extension named aspnet_isapi.dll. The basic configuration for ASP.NET involves registering application maps for common ASP.NET file extensions including .aspx, .ascx, .ashx, and .asmx at the level of an IIS Web site or virtual directory. When IIS sees an incoming request targeting a file with one of these extensions, it forwards the request to aspnet_isapi.dll, which effectively passes control over to the ASP.NET Framework.
Once the ASP.NET page parser builds the source file for an .aspx page, it can then compile it into a DLL. This compilation occurs automatically the first time the .aspx file is requested.Once the ASP.NET runtime has compiled an .aspx file into a DLL, that copy of the DLL can be used for all subsequent requests that target the same .aspx file. However, the ASP.NET runtime monitors the datetime stamp on the .aspx file and retriggers the compilation process to rebuild the DLL if it sees that the associated .aspx file has been updated.A page that links to a master page is known as a content page.
HTTP Request Pipeline
Figure 2-4 displays a picture of the HTTP Request Pipeline and its three replaceable component types: HttpHandler, HttpApplication, and HttpModule. As requests come in, they are queued up and assigned to a worker thread that then processes the request by interacting with each of these component types.

The ultimate destination of any request is the endpoint, which is modeled in the HTTP
Request Pipeline by using an HttpHandler class, which implements the IHttpHandler
interface. As a developer, you can create a custom HttpHandler component and plug it into the HTTP Request Pipeline by adding configuration elements to the web.config file.The HTTP Request Pipeline places an HttpApplication component in front of the HttpHandler.
On an application-wide basis, incoming requests are always routed through the HttpApplication before they reach the target HttpHandler, thus giving the HttpApplication the ability to preprocess any request no matter which HttpHandler it is being routed to. This preprocessing stage is handled through a series of events that are defined inside the HttpApplication class
such as BeginRequest, AuthenticateRequest, and AuthorizeRequest.
However, you can replace this standard component by creating a file named global.asax and placing it in the root directory of the hosting ASP.NET application. For example, you can create a global.asax that looks like the following:

protected void Application_AuthenticateRequest(object sender, EventArgs e) {
// your code goes here for request authentication
}
protected void Application_AuthorizeRequest(object sender, EventArgs e) {
// your code goes here for request authorization
}
The third replaceable component type in the HTTP Request Pipeline is the HttpModule. The HttpModule is similar to the HttpApplication component in that it is designed to handle events defined by the HttpApplication class and is processed before control is passed to any HttpHandler classes. For example, you can create a custom HttpModule component to handle request-level events such as BeginRequest, AuthenticateRequest, and AuthorizeRequest. As with the HttpHandler, an HttpModule class is defined with an interface. You can create a class that implements the IHttpModule interface and plug it into the HTTP Request Pipeline by adding configuration elements to the web.config file.
Whereas custom HttpApplication components can be defined as simple text files with an
.asax extension, custom HttpModule components are always compiled as classes within
assembly DLLs. To add a custom HttpModule component into the HTTP Request Pipeline,
you then add entries into a web.config file.
HttpModule components can be configured at the machine level. In fact, the ASP.NET
Framework ships with several different HttpModule components that are automatically
configured at the machine level to provide ASP.NET functionality for things such as Windows authentication, Forms authentication, and output caching.
The final component that we want to discuss with respect to the HTTP Request Pipeline is HttpContext. As ASP.NET initializes a request to send to the HTTP Request Pipeline, it creates an object from the HttpContext class and initializes it with important contextual information.The Object contains such as Request, User, and Response.
HttpContext currentContext = HttpContext.Current;
string incomingUrl = currentContext.Request.Url;
string currentUser = currentContext.User.Identity.Name;
currentContext.Response.Write("Hello world");
WSS Integration with ASP.NET
WSS integrates with ASP.NET at the level of the IIS Web site. Each IIS Web site in which you intend to host WSS sites must go through a one-time transformation process in which it is configured to become what WSS terminology refers to as a Web application. This transformation process involves adding IIS metabase entries and a WSS-specific web.config file to the root directory of the hosting IIS Web site. Once the transformation is completed, WSS extends the routing architecture of IIS and ASP.NET to properly route all incoming requests through the WSS runtime.
Creating a Web application requires a significant number of changes to the file system and the IIS metabase on each front-end Web server. In a Web farm environment, these changes are automatically mirrored across each front-end Web server in the farm by the WSS runtime.
Once a Web application is created, it is no longer necessary to touch the file system or IIS metabase of the front-end Web server when creating, updating, and deleting sites or site collections. The WSS architecture makes it possible to provision new sites and site collections simply by adding entries to the configuration database and a content database. It is this aspect of the WSS architecture that gives it significant management and provisioning advantages
over ASP.NET
.
Web Applications
Two primary ways exist to create a Web application by using either the WSS Central Administration Application or the stsadm.exe command-line utility. First, you can create a Web application by converting an existing IIS Web site. Alternatively, you can create a new Web application from scratch and let WSS create the new IIS Web site for you behind the scenes. In either case, WSS configures the resulting IIS Web site by adding an IIS application map and creating several virtual directories. WSS also copies a global.asax file and web.config file to the root directory of the hosting IIS Web site.
WSS must add an IIS application map to each Web application to ensure that each and every incoming request is initially routed to the ASP.NET runtime. Remember that the default configuration for ASP.NET only registers application maps for requests with well-known ASP.NET file extensions such as .aspx, ascx, .ashx, and .asmx. Therefore, WSS configures the hosting IIS Web site with a wildcard application map to route all incoming requests to aspnet_isapi.dll, including those requests with non-ASP.NET extensions such as .doc, .docx, and .pdf.
Because every request targeting a Web application is routed through aspnet_isapi.dll, the request gets fully initialized with ASP.NET context. Furthermore, its processing behavior can be controlled by using a custom HttpApplication object and adding configuration elements to the web.config file. The WSS team uses standard ASP.NET techniques to extend the HTTP Request Pipeline by using several custom components, as shown in Figure 2-5.
First, you can see that WSS configures each Web application with a custom HttpApplication object by using the SPHttpApplication class. Note that this class is deployed in the WSS system assembly Microsoft.SharePoint.dll. WSS integrates this custom application class by creating a custom global.asax file at the root of the Web application that inherits from SPHttpApplication.

You can see that the standard WSS web.config file configures SPRequestModule so that it is the first HttpModule to respond to application-level events in the HTTP Request Pipeline of ASP.NET. If you examine the web.config file for a WSS Web application, you will see that WSS adds back in several of the standard HttpModule components from the ASP.NET Framework that deal with things such as output caching and various types of authentication.
SPVirtualPathProvider
One of the strengths of WSS over ASP.NET is its ability to provision and customize pages
within a site without having to make any changes to the local file system of the front-end Web
server. This capability of WSS to provision and customize pages is made possible by storing
customized versions of .aspx files and .master files inside the content database and retrieving
them on demand when they are needed to process an incoming page request.
when the same page is requested, WSS must retrieve the contents of this customized page definition from the content database and pass it along to the ASP.NET runtime for parsing. We will now explain the architectural details that make this possible.
ASP.NET 2.0 introduced a new pluggable component type known as a virtual path provider. The idea behind a virtual path provider is that it abstracts the details of where page files are stored away from the ASP.NET runtime. By creating a custom virtual path provider, a developer can write a custom component that retrieves ASP.NET file types, such as .aspx and .master files, from a remote location, such as a Microsoft SQL Server database. Once a virtual path provider retrieves the contents of an .aspx page, it can pass it along to the ASP.NET runtime for parsing.
SPVirtualPathProvider is able to retrieve an ASP.NET page file from the content database, such as default.aspx, and then pass it along to the ASP.NET page parser. The SPVirtualPathProvider class works together with another class named the SPPageParserFilter to supply processing instructions to the ASP.NET page parser. For example, the SPPageParserFilter component controls whether the ASP.NET page parser compiles the ASP.NET page into an assembly DLL or whether it processes the page in a no-compile mode that is introduced with ASP.NET 2.0.

Imagine that you have just created 100 new WSS sites from the Blank Site template. If none of these sites requires a customized version of its home page (default.aspx), would it still make sense to copy the exact same page definition file into the content database 100 times? The answer to this question is obviously no. Fortunately, pages within a WSS site such as default.aspx are based on page templates that live on the file system of the front-end Web server. Page templates are used to provision page instances within the context of a site, such as the page that is accessible through a specific URL like http://litwareinc.com/default.aspx.
When a page instance is initially provisioned from a page template, WSS doesn’t need to store a copy of it in the content database because WSS can load the page template from the file system of the Web server and use it to process any request for an uncustomized page instance.
Therefore, you can say that page ghosting describes the act of processing a request for an uncustomized page instance by using a page template loaded into memory from the file system of the front-end Web server.
Page ghosting is valuable because it eliminates the need to transfer the contents of a page definition file from the SQL Server computer with the content database to the front-end Web server computer. Page ghosting also makes it possible to process the home pages for thousands of different sites by using a single page template that is compiled into an assembly DLL and loaded into memory in the IIS worker process just once per Web application. Both of these optimizations are key factors in the scalability of WSS in high-traffic environments running thousands or tens of thousands of sites.
Customized pages are sometimes referred to as unghosted pages.
SPVirtualPathProvider that determines whether the page being requested has been
customized. The SPVirtualPathProvider makes the decision whether to process a page as a ghosted or an unghosted page.
The new architecture introduced in WSS 3.0, which includes the SPVirtualPathProvider and the ASP.Net page parser, should be seen as one of the more significant architectural enhancements over WSS 2.0.
When WSS converts an IIS Web site into a Web application, it creates several virtual directories. These virtual directories, including the _controltemplates directory, the _layouts directory, the _vti_bin directory, and the _wpresources directory, are used by various aspects of the WSS runtime. The _wpresources virtual directory provides a repository for resource files that are deployed along with Web Parts.
Application pages are served up from the _layouts directory.

Thursday, June 5, 2008

Introduction to Features in Sharepoint-Part2-Chapter1

Features provide a mechanism for defining site elements and adding them
to a target site or site collection through a process known as feature activation. The element types that can be defined by a feature include menu commands, link commands, page templates, page instances, list definitions, list instances, event handlers, and workflows.
At a physical level, a feature consists of a directory created within a special WSS system directory located within the file system of each front-end Web server. The directory for a feature contains one or more XML-based files that contain Collaborative Application Markup Language (CAML). By convention, each feature directory contains a manifest file named feature.xml that defines the high-level attributes of the feature, such as its ID and its userfriendly Title.
Programming Against the WSS Object Model
static void Main() {
string sitePath = "http://litwareinc.com";
// enter object model through site collection.
SPSite siteCollection = new SPSite(sitePath);
// obtain reference to top-level site.
SPWeb site = siteCollection.RootWeb;
// enumerate through lists of site
foreach (SPList list in site.Lists) {
if(!list.Hidden)
Console.WriteLine(list.Title);
}
// clean up by calling Dispose.
site.Dispose();
siteCollection.Dispose();
}

Future.xml
feature id="B2CB42E2-4F0A-4380-AABA-1EF9CD526F20" title="A Sample Feature: Hello World" xmlns="http://schemas.microsoft.com/sharepoint/" description="This demoware was created by NaveedShare-LicenseToPlay " scope="Web" hidden="FALSE" imageurl="TPG\WhitePithHelmet.gif" receiverassembly="HelloWorld, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b38a04419cc857d9" receiverclass="HelloWorld.FeatureReceiver">

elementmanifests>
elementmanifest location="elements.xml">
/elementmanifests>

/feature>
elements.xml
elements xmlns="http://schemas.microsoft.com/sharepoint/">

customaction id="SiteActionsToolbar" title="Hello World" description="A custom menu item added using a feature" imageurl="_layouts/images/crtsite.gif" location="Microsoft.SharePoint.StandardMenu" groupid="SiteActions" sequence="100">
urlaction url="http://msdn.microsoft.com">
/customaction>

/elements>
FeatureReceiver.cs
using System;
using Microsoft.SharePoint;

namespace HelloWorld {

public class FeatureReceiver : SPFeatureReceiver {

// no functionality required for install/uninstall events
public override void FeatureInstalled(SPFeatureReceiverProperties properties) { }
public override void FeatureUninstalling(SPFeatureReceiverProperties properties) { }

public override void FeatureActivated(SPFeatureReceiverProperties properties) {
SPWeb site = (SPWeb)properties.Feature.Parent;
// track original site Title using SPWeb property bag
site.Properties["OriginalTitle"] = site.Title;
site.Properties.Update();
// update site title
site.Title = "Hello World";
site.Update();
}

public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {
// reset site Title back to its original value
SPWeb site = (SPWeb)properties.Feature.Parent;
site.Title = site.Properties["OriginalTitle"];
site.Update();
}
}
}
Install.bat
@SET TEMPLATEDIR="c:\program files\common files\microsoft shared\web server extensions\12\Template"
@SET STSADM="c:\program files\common files\microsoft shared\web server extensions\12\bin\stsadm"
@SET GACUTIL="c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe"

Echo Installing HelloWorld.dll in GAC
%GACUTIL% -if bin\debug\HelloWorld.dll

Echo Copying files to TEMPLATE directory
xcopy /e /y TEMPLATE\* %TEMPLATEDIR%

Echo Installing feature
%STSADM% -o installfeature -filename HelloWorld\feature.xml -force

IISRESET

REM cscript c:\windows\system32\iisapp.vbs /a "SharePointDefaultAppPool" /r
Once you have added the install.bat file, you can configure Visual Studio to run it each time you rebuild the HelloWorld project by going to the Build Events tab within the Project Properties and adding the following post-build event command line instructions.
cd $(ProjectDir)
Install.bat
The properties parameter is based on the SPFeatureReceiverProperties class that exposes a Feature property that, in turn, exposes a Parent property that holds a reference to the current site.

Introduction to Sharepoint 2007-part1

After a long time i come back to my home site.While this around last one year lot of things happend.
k...mum...
from now onwords i have been blogging...
From this blog on words i posted my learning MOSS stuff step -by-step.This is Categerized Chapters N Parts.
I hope MOSS hunters will Enjoy through my posts and my Chapters will stop digging MOSS...
Start Machiiiiii...start
Chapter 1
Getting Started
SharePoint technologies provide an effective solution for creating team sites to facilitate collaboration in a LAN-based environment and make it easier to manage content in an Internet-facing site that can scale to accommodate thousands of users in a Web farm environment.
Windows SharePoint Services as a development platform.
Our goal is to teach you how to create, debug, and deploy the fundamental building blocks such as Features, Site Definitions, Page Templates,Web Parts, List Schemas, Content Types, Event Handlers, and Workflow Templates.
Site Provisioning
WSS is a site provisioning engine.
The act of provisioning (a fancy word for creating) a site in WSS can be accomplished by any member of the IT department in less than a minute by filling in the required information in a browser-based form and clicking the OK button. There’s no need for a database administrator to create a new database or any new tables. There’s no need
for an ASP.NET developer to create a new ASP.NET Web site. There’s no need for a system administrator to copy any files or configure any IIS settings on the front-end Web server.

Microsoft Office SharePoint Server 2007
WSS is included as a part of the Windows Server 2003 operating system while MOSS is a separate product . You should think of WSS as the underlying platform and think of MOSS as a value-added set of components and services that has been built on top of this platform.
WSS does not have its own licensing model. Instead, the use of WSS is controlled through Windows Server 2003 licenses. MOSS, on the other hand, has its own licensing model.

farm is a set of one or more server computers working together to provide WSS functionality to clients. Each WSS farm runs a single SQL Server database known as the configuration database. The configuration database tracks important farm-wide information. For example, the configuration database tracks which front-end Web servers are associated with the farm as well as which users have been assigned administrative permissions within WSS at the farm level.
WSS is built on top of Internet Information Services 6.0 (IIS). In particular, WSS relies on IIS Web sites to handle incoming HTTP requests. Therefore, you need to understand exactly what an IIS Web site really is. An IIS Web site provides an entry point into the IIS Web server infrastructure. For example, the Default Web Site created automatically by IIS listens for incoming HTTP requests on port 80. You can create additional IIS Web sites to provide additional entry points using different port numbers, different IP addresses, or different host headers.
An IIS Web site must be specially configured when it is used to serve up WSS sites.
An IIS Web site that has been specially configured to run WSS sites is known as a Web application.Every WSS site runs in the context of a specific Web application.
The installation of WSS creates and configures a Web application named the WSS 3.0 Central Administration application. The WSS 3.0 Central Administration application provides pages that allow you to perform administrative chores such as converting a standard IIS Web site into a WSS Web application. The WSS Central Administration application also provides the option to create a new IIS Web site and automatically configure it to be a WSS Web application as well, all without having to use any of the IIS administration tools directly.

Default Web Site can be configured as a WSS Web application to make WSS sites available through the standard HTTP port 80. You might decide to create additional Web applications within the farm such as an intranet Web application on port 1000. WSS configuration data is stored on a farm-wide basis in the configuration database, and the data associated with WSS sites is tracked in another type of database known as a content database. When you create a new Web application with the WSS 3.0 Central Administration application, WSS creates a new content database. If you stick with a simple deployment model, your farm will include one content database for each Web application,as shown in Figure 1-2.

Sites and Site Collections
What is a WSS site? First, a WSS site is a storage container for content. Site content is primarily stored in the form of lists, document libraries, and child sites. Second, a site is a securable entity whose content is accessible to a configurable set of users.
Note that WSS doesn’t actually perform user authentication. Instead, WSS relies on the underlying layers within IIS and the ASP.NET authentication provider infrastructure to accomplish that. However, WSS does take charge when it comes to authorization. WSS provides user interface elements and supporting code that allows privileged users to configure authorization to various elements within their sites.
Every WSS site must be provisioned within the scope of an existing Web application. Instead, every WSS site must also be created inside the scope of a site collection. A site collection is a container of WSS sites. Each site collection requires a top-level site. In addition to the required top-level site, a site collection can contain a hierarchy of child sites. Figure 1-3 shows several possible site collections.

WSS architecture sees each site collection as an island with respect to security configuration.
The STSADM.EXE Command Line Utility
Here’s an example of a command line instruction to create a new site collection at a specific URL.
STSADM.EXE –o CreateSite –url http://localhost/sites/Sales
-ownerlogin LitwareServer\BrianC
-owneremail brianc@litwareinc.com
-sitetemplate STS#0
c:\program files\common files\microsoft shared\web server extensions\12 called as system directory.
Users can also create several types of custom site elements for reuse across all the sites within a site collection. For example, if you create a site column within a top-level site, then this site column is reusable in all the child sites down below. This allows you to define the column characteristics such as formatting, validation, or a choice list one time and then to use this reusable column type across many lists within the site collection.
The standard Site Settings page for a top-level site is shown in Figure 1-8.

The Site Actions menu also provides the Create menu command, which takes you to the Create Page, as shown in Figure 1-9.

Customization changes are seen by all users. Personalization changes are seen by only the user who made them.
A site customization never requires touching the front-end Web server. WSS development, on the other hand, involves working with files that must be deployed to the file system of the front-end Web server. WSS development includes creating page templates and list definitions, as well as creating components deployed in compiled assemblies such as custom Web Parts, event handlers, and workflow templates. WSS development at this level is also referred to as developing provisioning components.
A site column is a reusable column definition that can be used across multiple lists. A site column defines the name for a column, its underlying field type, and other characteristics such as the default value, formatting, and validation.
A content type is a flexible and reusable WSS type definition that defines the columns
and behavior for an item in a list or a document in a document library
. For example, you can create a content type for a customer presentation document with a unique set of columns, an event handler, and its own document template. You can create a second content type for a customer proposal document with a different set of columns, a workflow, and a different document template. A content type deal with heterogeneous types of content in lists and document libraries.
WSS is built on top of Microsoft’s new Windows Workflow Foundation that is part of the .NET Framework 3.0.WSS adds an extra dimension on top of the Windows Workflow Foundation to provide a foundation for attaching business logic to list items and documents in a WSS site.
Both WSS and MOSS ship with workflows that are installed and ready to use. WSS includes a simple routing workflow for things such as moderation and approval.