Site Templates

A site template provides the basic components and layout of a new site created under SharePoint. It contains specific design information about a site, including the lists that are part of that site, Web Part Pages used in the site, the site’s themes and borders, changes to the Quick Launch bar, as well as some site content (such as document libraries).

Site templates are used to allow the rapid creation of web sites and basic content in a SharePoint system. Any number of new sites can be generated based on a site template, which is a set of basic content pages and schemas (which are themselves stored on the Web server as a set of HTML and XML files). There can be an unlimited number of site templates, although typically there are basic types and a few templates customized to an organization’s specific requirements.
Site templates are stored in the SharePoint database and can be accessed through template galleries. Once a site template has been created, other users can use that template (or create copies of it for further modification). User-created site templates can be imported to the site collection level, adding them to the site template gallery. Site template files have an “.stp” extension.

Site templates provide several important benefits for site administrators:
They enable you to have a consistent, professional look throughout your portal site.
They provide an efficient way to create subsites and site collections. Individual groups within your organization don't need to set up their sites from scratch, which can be costly and time consuming.

Their use results in a uniform, professional look throughout your portal site that reflects your organization's standards.
Site administrators and designers can create a site template by customizing a site and then saving it as a site template. The site template can be used by others to create sites with the same look and feel. Site collection administrators can also import a site template that was created by another administrator or designer and add the new template to the available site templates in the site collection.

Site templates, compared to site definitions, are easy to create and deploy. You can make all customizations through the user interface or FrontPage 2003. In addition, you do not need to be a server administrator on the Web server to create and deploy site templates. You can modify a site template without affecting existing sites created by the template. Deployment is simple because template data is stored centrally in the configuration database.

Because it is slow to store templates in and retrieve them from the database, site templates can result in slower performance. Templates in the database are compiled and executed every time a page is rendered. Windows SharePoint Services does some performance optimization whereby it stores templates on the local Web server and a copy (or “ghost”) of the page in the configuration database. However, you can easily prevent Windows SharePoint Services from using a copy of the page by using Web Folders or FrontPage to open, modify, and save it. From this point forward, the database is used to render the page. Preventing Windows SharePoint Services from using a copy of a site page will cause the page to stop picking up changes from the site definition files, so if you want to keep a consistent look across the entire portal and only want to modify the site definition files, then don’t prevent this optimization. Rendering pages from the database will result in an initial performance penalty.

Site templates only work on SharePoint sites that are not portal sites (not based on the SPS templates). Furthermore, site templates are not ideally suited for a development environment. In effect, they are still customizations of a site definition. If the site definition does not exist on the server, the site template fails.
Typically, because of these issues, site templates are not as efficient as site definitions in a large-scale environment”

But you should notice that, when you create site out of site template or site definition, and make changes to either of them, will that effect the sites already created out of them? I am still having this confusion

Site Definition

Site Definition contains a server-side collection of files that defines the structure of one or more site templates.

A site definition is composed of the following:
A webtemp.xml file that defines the numbering and creation details for the various site templates that are contained in the site definition.
A separate directory that contains all of the core files used by the site definition, excluding any items that are provided through Features.

The webtemp.xml file is stored in

%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML

The directory that contains the site definition files is named according to the site definition’s name and is stored in

%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions \12\TEMPLATE\SiteTemplates

Customizing portal sites and other SharePoint sites using site definitions is most appropriate for third-party developers and server administrators. Because site definitions require access to the file systems of the Web server, server administrators must always be involved in the deployment of site definitions. If you are modifying areas of a portal site, then you will need to use site definitions.

Although deploying a site definition requires more work, site definitions typically perform better when cached on the file system instead of in the database. In addition, you can achieve a finer level of customization by directly editing all the schema files and not depending on the existing site definition as a site template does. Also, if you want to introduce new file types, view styles, and drop-down edit menus, you need to edit the schema files that make up the site definition.
Custom site definitions are version and upgrade independent. Subsequent upgrades to SharePoint Products and Technologies may overwrite existing default site definitions. Using custom site definitions excludes your sites from potential upgrade issues.
However, there is no easy way to modify site definitions once they are deployed. There is always the possibility of breaking existing deployed sites derived from the site definition once you modify an existing site definition. You can only add to the site definition once it is deployed.

SharePoint Solutions

Solution packages are the preferred mechanism for deploying WSS components. The solution package itself is a compressed CAB file with a .wsp extension, and it contains one or more WSS components along with any dependent files that need to be deployed on each front-end Web server.

A simple solution package might contain just the files needed to deploy a single feature. A more complex package could contain the files for multiple features, applications pages, Web Parts, list definitions, event handlers, and a site definition.

The WSS runtime provides a built-in installer component that runs on each front-end Web server and is responsible for uncompressing the files inside a solution package and properly installing its components. The WSS installer requires each solution package to carry additional metadata inside a file named manifest.xml. When the installer is called upon to deploy a solution package, it reads the metadata in manifest.xml to determine exactly which components and files from inside the CAB file need to be extracted and deployed.

Manifest.xml contains metadata to instruct the installer which files need to be extracted from the solution packages and copied into various WSS system directories. But beyond that, manifest.xml also carries metadata that tells the installer to perform other important deployment procedures, such as registering features with the WSS runtime, adding assembly DLLs to the Global Assembly Cache (GAC), and updating the web.config file with SafeControl entries required in Web Part deployment.

Branding in SharePoint

Branding is the successful attempt to symbolicly embodiment of all the information connected to a company, product or service. Branding helps you identify a company, product or service through the use of consistent logo, colors and text.SharePoint 2007, allows for many forms of customization to transform the presentation of the content to meet the needs of those that require it.

Starting with the third generation of SharePoint Products and Technologies, the SharePoint platform is built natively on top of the Microsoft .NET Framework. The SharePoint product team has developed a custom HTTP application and custom HTTP handlers and modules to create SharePoint Products and Technologies and change how Microsoft ASP.NET 2.0 works

SharePoint Object Model Hierarchy

Microsoft Office System Architecture

Tips for WebPart Development

• Unless you intend to use your WebPart on SharePoint 2003 site inherit your WebPart class from System.Web.UI.WebControls.WebParts.WebPart
  
• Deploy WebPart dll to bin folder instead of GAC [full trust] if possible
  Remember to add [assembly: AllowPartiallyTrustedCallers()] to allow the strong named assembly to run from the bin
  
• Remember to change trust level in web.config from "WSS_Minimal" to "WSS_Medium" or create your own policy if your WebPart uses Object Model

Introduction to Web Parts

Web Parts are server-side controls that run inside the context of special pages (that is, Web Part Pages) within an ASP.NET application or a Windows SharePoint Services site. They are the "building blocks" of pages in Windows SharePoint Services.
There are now two different Web Part styles in Windows SharePoint Services 3.0. Both are supported, but the ASP.NET 2.0 Web Part is the recommended style for your new projects.
SharePoint-based Web Parts — The older style Web Parts have a dependency on Microsoft.SharePoint.dll and must inherit from the WebPart base class in the Microsoft.SharePoint.WebPartPages namespace. These Web Parts can only be used in SharePoint Web sites. Yet in Windows SharePoint Services 3.0, the Microsoft.SharePoint.dll was changed so that Web Parts written in the older style would be compatible with the Windows SharePoint Services 3.0 runtime.
ASP.NET 2.0 Web Parts — These Web Parts are built on top of the ASP.NET Web Part infrastructure. The newer ASP.NET-style Web Parts have a dependency on System.Web.dll and must inherit from a different base class named WebPart in the System.Web.UI.WebControls.WebParts namespace. These Web Parts can be used in Windows SharePoint Services applications whether Windows SharePoint Services is involved or not, making them highly reusable. If you are creating your Web Part specifically for a SharePoint site, and it will consume the Windows SharePoint Services object model, you can derive from the ASP.NET System.Web.UI.WebControls.WebParts.WebPart base class and add a reference to the SharePoint object model in your project.
The Windows SharePoint Services 3.0 Web Part infrastructure is built on top of a control named SPWebPartManager that is derived 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 Windows SharePoint Services content database instead of in the ASP.NET services database. In most cases, you don not have to worry about dealing directly with the SPWebPartManager control because the one and only required instance is already defined in default.master. When you create a content page that links to default.master, the SPWebPartManager control is already there.
When you create a Web Part Page for a standard ASP.NET 2.0 application, you need to add logic that interacts with the WebPartManager control to manage the Web Part display mode, and generally you also need to explicitly add editor parts and catalog parts to the page along with the HTML layout to accommodate them. Fortunately, you do not have to perform these changes when creating content pages for a Windows SharePoint Services 3.0 site. Instead, you inherit from the WebPartPage class that is defined inside the Microsoft.SharePoint.WebPartPages namespace and it does all the work behind the scenes for you.
Custom Web Parts provide developers with a method to create user interface elements that support both customization and personalization. The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them.

Developing First Three Web Parts for SharePoint

Note : In order to follow these steps we need Visual Studio 2005 (.NET 2.0) or later. we will also need network access to a Windows 2003/8 server with SharePoint 2007 (WSS or MOSS). Also we need to have administration rights on our SharePoint server and also administration rights in our target SharePoint web application.

The steps to create a simple Web Part that prints "Hello World!" to the screen.
1. In Visual Studio, create a new class library
2. Add a reference to System.Web.
3. Create a class that inherits from the WebPart class in System.Web.UI.WebControls.WebParts. 4. In order to control the rendering of the Web Part one overrides the Render method. An HtmlTextWriter instance is passed into the Render method and can then be used to write markup to the page output.

using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
namespace ExampleWebPartLibrary
{
public class MyWebPart : WebPart
{
protected override void Render(HtmlTextWriter writer)
{
writer.Write("Hello World!");
}
}
}

5. OPTIONAL Add the code statements using System.Security; and [assembly: AllowPartiallyTrustedCallers] to our AssemblyInfo.cs file.
6. Specify proper Assembly Name and Namespace properties for the class library project by opening the project property page
7. OPTIONAL Specify the Signing parameters in the project property page
8. Build the assembly frequent
9. Copy the newly created assembly from bin\Release or bin\Debug folder and paste it in the bin directory of the sharepoint web application OR In our class library properties, set the build output path to the bin directory of our SharePoint development web application.
10. OPTIONAL copy the assembly into C:\Windows\Assembly (GAC), REight click select properies to find its public key
11. In the web.config file of the sharepoint web application, add the assembly as a safe control.

Assembly="ExampleWebPartLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=db485f68ad2dc0c5"
Namespace="ExampleWebPartLibrary"
TypeName="*" Safe="True" AllowRemoteDesigner="True" />

12. We can now add the web part library to your SharePoint site. To do this, log in as an administrator and go to the settings page. Click on "Web Part Gallery" under the "Galleries" section. Click "New" and we should see our web part in a list. Select our web part and click "populate gallery".
13. We can give your web part a friendly title and control its permissions using the edit button in the web part gallery. I have chosen to call the Web Part "My Web Part".
14. Finally we can add the web part to a web part page and we should see the web part's hard coded "Hello World!" message.
Adding ASP.NET controls in our web part
1. Repeat the steps 1-3 of first example.
2. Controls should be declared as member variables and then initialised and configured within an override of the CreateChildControls method. I usually create a separate method to setup each control and then invoke that method from CreateChildControls. It is important to add the created controls to the list of Web Part controls. If a control is not added to this list then it's events won't be raised on post back.
private Button btnDemo;
private void createBtnDemo()
{
btnDemo = new Button();
btnDemo.Text = "Click me";
btnDemo.Click += new EventHandler(btnDemo_Click);
// This line of code is required to trigger the click eventControls.Add(btnDemo);
}
protected override void CreateChildControls()
{
base.CreateChildControls();
createBtnDemo();
createLblHelloWorld();
}
3. The controls are rendered inside the Render method override. This method can be used to layout the web part it's controls. The HtmlTextWriter has many useful methods to help out, including WriteBreak() which writes a "
".
protected override void Render(HtmlTextWriter writer)
{
writer.WriteBreak();
lblHelloWorld.RenderControl(writer);
writer.WriteBreak();
writer.WriteBreak();
btnDemo.RenderControl(writer);
}
4. Perform the steps from 5 (of first example) to deploy the web part
Accessing SharePoint data in our web part
1. Repeat the steps 1-3 of first example.
2. Reference Microsoft.SharePoint.dll by browsing to the directory "[Program Files]\Common Files\Microsoft Shared\web server extensions\12\ISAPI".
3. To take care of the code access security for our web part by setting the target SharePoint site's trust level to "Full". This level of trust is generally acceptable in an Intranet environment. Find the following in our site's web.config file:

change this to:

4. Write some code to access SharePoint data. Here I show a simple web part that displays the name of the presently logged in user:
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
namespace ExampleWebPartLibrary
{
public class HelloUser : WebPart
{
protected override void Render(System.Web.UI.HtmlTextWriter writer)
{
// Get a contextual reference to the current SPWeb
SPWeb currentWeb = SPContext.Current.Web;
// Write a message to the current user
writer.Write("Hello " + currentWeb.CurrentUser.LoginName);
}
}
}
Note : SPContext.Current.Web is the starting point for accessing SharePoint data. For example we can use it to access data in lists and document libraries.
5. Perform the steps from 5 (of first example) to deploy the web part

WebPart Deployment

Within a SharePoint site, we can deploy a Web Part assembly in any of the following locations.
bin directory — The bin directory is a folder stored in your Web application root directory. For most installations, this is located in the %SYSTEMDRIVE%\inetpub\wwwroot\wss\VirtualDirectories\\bin directory.
Global Assembly Cache (GAC) — The GAC enables you to share assemblies across numerous applications. Components are typically installed in the %SYSTEMDRIVE%\WINDOWS\Assembly directory.
Note that the recommended practice is to deploy assemblies to the bin directory.
Windows SharePoint Services provides a SafeControls list to prevent users from arbitrarily adding server-side code within ASPX pages. The SafeControls list is a list of approved controls and Web Parts that are specific to the SharePoint site that we have designated as safe for invocation on any ASPX page within our site. This list is contained in the web.config file in your Web application root. The local path contains the physical location of the web.config file.

Web Parts are designed to be distributed over the Internet or an intranet. For security reasons, when we create a custom Web Part, we should give it a strong name to ensure that the Web Part can be trusted by our users.

By default, the trust level for a server will be WSS_Minimal, which does not allow access to the Windows SharePoint Services object model. In order to perform such actions, we must perform one of the following three actions:

Create a custom policy file for your assembly,
Install your assembly in the GAC global assembly cache
Increase the trust level for the entire virtual server. Eg: increase the default trust from WSS_Minimal to WSS_Medium in the web.config file.