Site Definition in Microsoft SharePoint Server 2007

Following steps are included in creating a custom site definition:

• Create a folder named “mySiteDef” at C:Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Site Templates\ 
• Create a subfolder “XML” and create the onet.xml in it. The following kinds of tasks can be performed in a custom Onet.xml to create a custom site definition: 
• Specify an alternate cascading style sheet (CSS) file, JavaScript file, or ASPX header file for a site definition.
• Modify navigation areas for the home page and list pages
• Add a list definition as an option to the Create page
• Add a document template for creating document libraries
• Define one or more configurations for the site definition, specifying the lists, modules, files, and Web Parts that are included when a site definition configuration is instantiated
• It contains the following tags to define various items in a site definition. A sample onet.xml can be found at 12\TEMPLATE\SiteTemplates\SPS\XML folder in sharepoint farm (Same can be done through by copy existing site definition).
• Within the “C:/Program Files/Common Files/Microsoft Shared/web server extensions/12/Templates/1033/XML” directory create a new file called webtempSiteMinder.XML. At run time the compiler will merge the information contained in this file with the information contained in the original WEBTEMP.XML file to specify which site templates are available for creating new sites
• Enter the following XML into the webtempSiteMinder file as follows to create the new site definition.

<?xml version="1.0" encoding="utf-8"?>
<!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
<!-- _LocalBinding -->
<Templates xmlns:ows="Microsoft SharePoint">
<Template Name="MYSITEDEF" ID="325202">
<Configuration ID="1" Title="MYSITEDEF" Hidden="FALSE" ImageUrl="/_layouts/images/blogprev.png" Description="MYSITEDEF Subsite" DisplayCategory="Custom" > </Configuration>
</Template>
</Templates>

• Each WEBTEMP.XML file contains a collection of Template elements and Configuration sub-elements, which identify to the compiler all the site definitions that can be instantiated. The Configuration elements define a title, a description, and a URL for the image displayed in the user interface, properties common to each Web Site created using the site definition.
• It is important to make sure that each Template element defined in the WEBTEMP file contains the identical Name in all capital letters that is assigned to the new folder created above. Also, as a best practice when creating new templates to avoid conflicts with existing sites use a unique value that is greater than 10,000 for the ID attribute.
• Once created the various site elements can be edited using Microsoft office sharepoint designer.

Scoping Master Pages in SharePoint

Master pages provide the look and feel and standard behavior that you want for all of the pages in your site. Together with content pages, they produce output that combines the layout of the master page with content from the content page. 

Because Windows SharePoint Services is built on top of Microsoft ASP.NET 2.0, it supports master pages for defining elements that are common to all pages. You can specify all of the shared elements of your site in the master page or pages, and add content page-specific elements to content pages.

Master pages allow you to create a consistent layout for the pages in your application. A single master page defines the look and feel and standard behavior that you want for all of the pages (or a group of pages) in your application. You can then create individual content pages that contain the content you want to display. When users request the content pages, they merge with the master page to produce output that combines the layout of the master page with the content from the content page.
Windows SharePoint Services pages that end users can customize—list view pages, list form pages, and Web Part Pages—are content pages that contain the content to display. When a user requests a content page, it is merged with a master page to produce output that combines the layout of the master page with the content from the content page.
All content pages share the same page structure—the global breadcrumb, site title area, top navigation, page title area, and left navigation bar. In Windows SharePoint Services, this shared page structure is moved into a master page called default.master, which is used by all content pages, including the following:

1. default.aspx
2. AllItems.aspx, DispForm.aspx, NewForm.aspx, and EditForm.aspx: for all lists 
3. Upload.aspx and Webfldr.aspx: for all document libraries 
4. Any new content pages that are created in this site

 
There are three levels to attach content pages to a master page:

• At the page level: you can use a page directive in each content page to bind it to a master page, as in the following code example. 
• At the application level: By making a setting in the pages element of the application's configuration file (Web.config), you can specify that all ASP.NET pages (.aspx files) in the application automatically bind to a master page. The element might look like the following. If you use this strategy, all ASP.NET pages in the application that have Content controls are merged with the specified master page. (If an ASP.NET page does not contain Content controls, the master page is not applied.)
• At the folder level: This strategy is like binding at the application level, except that you make the setting in a Web.config file in one folder only. The master-page bindings then apply to the ASP.NET pages in that folder.

Important Considerations for SharePoint Master Pages

Consider the following when you are working with master pages in Windows SharePoint Services:

1. Compilation mode for master pages works like the compilation mode for any other .aspx page. You can change the compilation mode at any time, and you can combine compilation modes for master and content pages, for example, a compiled master page and a content page that is not compiled. Remember, however, that although compiled master pages can contain inline script, after that page is customized in Office SharePoint Designer, or a similar tool, the page is no longer compiled and script no longer runs. For that reason, it is recommended that you do not include inline script in your master pages.

2. By default, Windows SharePoint Services does not use nested master pages, but does not block users from using them. You can create master pages at any level, and have a master page that refers to another master page. For example, you can reference one master page from another master page using the following directive:

<%@ Master master=MyParent.master %>

Some page editors may not effectively support nested master pages.

3. You cannot add Web Parts in zones to a master page. You can add static Web Parts (parts outside of a zone) to a master page, but you cannot add dynamic Web Parts to master pages. You can add zones to master pages and later add Web Parts to the zone in the browser, but the Web Parts are associated with the content page.

Why Feature stapling in SharePoint

sometimes you may want to attach your feature with site definition i.e. whenever someone create a site using particular site definition you might want to activate the feature by default, and in same scenario it may be possible that you do not own the site definition hence cannot modify the existing site definition to attach feature (like SharePoint default site def e.g. team site\publishing\collaboration).

In these cases you can write a feature and can attach the feature itself with the site definition.

From MSDN :
"Causes the attachment of a Feature to all new instances of sites that use a given site definition, without modifying the site definition or creating code routines to activate the Feature on each site. Also known as a feature site template association"

Following is an example of feature stapling that associates the Feature with only the STS site definition template

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<FeatureSiteTemplateAssociation Id="00BFE171-1B17-4F72-28CB-1171C0140130" TemplateName="STS#0" />
</Elements>

http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/5e27a15b-5ceb-4706-b660-aadad03e0f3c

WSS3.0\MOSS2007 and "Integrated managed pipeline mode" of IIS7

Problem Description:
SharePoint site is on WIN2k8\IIS7\WSS3.0-SP2 and you have created a sample web app (blank site) which is running well with IIS7 "Classic managed pipeline mode" but when you change it to "Integrated managed pipeline mode", It does not work and throws an error message "500 internal server Error".
Discussion ,Action taken and Results:
As discussed, MOSS 2007 use “Classic application pool mode” in IIS 7 for the SharePoint site since MOSS 2007 use IIS 6.0/ISAPI functionality through an ISAPI module and that is part of “Classic application pool mode” .
If we will use the “ Integrated Request Pipeline” for the SharePoint 2007 site you will not be able to browse to the site.
Following is the TechNet article which talk about that SharePoint use “Classic application pool mode” for the Application pool.
1: http://msdn.microsoft.com/en-us/library/bb909693.aspx (How to: Verify or Correct the IIS Configuration for an Application Pool)
Details are:
1. On the Application Pools page, review all application pools for Team Foundation.
• Under .NET Framework Version, verify that v2.0 appears.
• Under Managed Pipeline Mode, verify that Classic appears.
2: http://technet.microsoft.com/en-us/library/cc262485.aspx (Determine hardware and software requirements (Office SharePoint Server))
Details are:
Windows components
After you have installed the operating system and applied all critical updates, you must configure the computer to be a Web server by enabling Internet Information Services (IIS) 6.0, including:
• Common files
• WWW
• Simple Mail Transfer Protocol (SMTP)
You must configure the server to use IIS 6.0 worker process isolation mode. This is the default setting in new installations. However, if you have upgraded from IIS 5.0 on Windows Server 2000, Run WWW in IIS 5.0 isolation mode is enabled, and you must change this setting to use IIS 6.0 worker process isolation mode.
To enable e-mail notifications, you need to configure incoming and outgoing e-mail settings. To configure sending e-mail alerts and notifications, you must specify an SMTP e-mail server. To configure your installation so that your SharePoint sites can accept and archive incoming e-mail, you must install the IIS SMTP service

Additional info:
Integrated Request Pipeline:
Think of the integrated request pipeline as the essential set of linear steps that must occur every time a page is served up (as seen in Figure 2). Typically, some sort of authentication must take place, followed by authorization to retrieve content, determination and execution of the handler needed for that content, performance of any necessary logging, and finally sending a response. The integrated request pipeline provides IIS 7.0 the flexibility to run different application frameworks at the same time. For example, you can run Forms authentication on top of PHP content with a custom logging module, all together in the same pipeline.

Each Web site on the server has an integrated request pipeline and can be run in one of two modes, Integrated and Classic. Integrated, the default, allows particular pieces of functionality to be plugged into the pipeline, giving you granular control over the request process. For compatibility, Classic mode reproduces IIS 6.0/ISAPI functionality through an ISAPI module into the pipeline. This is very helpful when migrating your applications to IIS 7.0.
More info : http://technet.microsoft.com/en-us/magazine/2008.03.iis7.aspx
Classic application pool mode:
When an application pool is in Classic mode, IIS 7 handles requests as in IIS 6.0 worker process isolation mode. ASP.NET requests first go through native processing steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the managed runtime. Finally, the request is routed back through IIS to send the response.
This separation of the IIS and ASP.NET request-processing models results in duplication of some processing steps, such as authentication and authorization. Additionally, managed code features, such as forms authentication, are only available to ASP.NET applications or applications for which you have script mapped all requests to be handled by aspnet_isapi.dll.

Context sensitive help in SharePoint

Context sensitive help is key part of any product now Days. Product companies don’t want their customers to search for a particular help in entire help system and it becomes really difficult in case of online help where you may want to redirect your customer to some online help article

You must have seen such scenarios in many Microsoft products. The one I can remind now is code analysis tool or FxCop
Below is the sample steps of context sensitive help implemented in a SharePoint product, which can be implemented in ASP.NET or any other technology

Step 1: define a content placeholder in master page of the application (as top right corner the default location in SharePoint)

Step 2: now from each page add an image button on which you will attach a javascript function to call help page. Add any standard help image on this button

Step 3: prepare an xml file on which define key value pair for each page.where key will be the page context and value will be the respective URL

Step 4: onload of each page attach a java script function to help image button onclick event which will find the URL from defined xml file

Step 5: prepare a separate help system such as .chm file and publish help content as per the associated links

Step 6: host all the pages in the web server incase of SharePoint I posted all these files which include .htm\.jpg\.css etc in a form library

Step 7: run the application and you will be able to access your help system in context of the current page

I will post the respective code for this soon
Reach me for more detail explanation.