Development Opportunities:

1. ASP.Net master pages and CSS
2. Standard ASP.NET server controls, Web Parts, event handlers, custom field types, and custom policies.
3. Site Column
4. Content type
5. Office Open XML file format
6. Workflow
7. Features

Features are a new developer-focused innovation that has been added to WSS 3.0. 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. (lulu: Activate and De-Activate events)

WSS object model
The WSS object model exposes an SPSite class that serves as an entry point into the WSS object model at the site collection level. Each site within a site collection is represented as an SPWeb object. Each list within a site is represented as an SPList object. Here’s a simple example using the WSS object model to access the top-level site within a target site collection and discover all its lists.

using Microsoft.SharePoint;
namespace Hello_WSS_OM {
  class Program {
    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) {
        Console.WriteLine(list.Title);
      }
      // clean up by calling Dispose.
      site.Dispose();
      siteCollection.Dispose();
    }
  }
}

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.

The WSS team created a virtual path provider named SPVirtualPathProvider that is integrated into every Web application. The SPVirtualPathProvider class is integrated into the ASP.NET request handling infrastructure by the SPRequestModule. More specifically, the SPRequestModule component contains code to register the SPVirtualPathProvider class with the ASP.NET Framework as it does its work to initialize a Web application. Figure 2-6 displays a diagram that depicts the role of the SPVirtualPathProvider.

Application Page (Ghosted and Non-customizable)
Site Page (Customizable, so Non-Ghosted) 

As a rule, application pages should derive from a base class in the Microsoft.SharePoint assembly named LayoutsPageBase.

Web Part pages in a WSS 3.0 site are built on top of the new Web Part infrastructure introduced with ASP.NET 2.0. 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.

The Web Part infrastructure of WSS 3.0 does not use the standard WebPartManager control from ASP.NET. Instead, 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.

Site pages and application pages use separate master pages.

Delegate Controls and ContentLightup

A Web Part is a class that inherits from the WebPart class defined in the System.Web.UI.WebControls.WebParts namespace inside the System.Web assembly. The Web Part is a special type of Web control that is deployable inside of a Web Part Zone control after the initial page has been created and deployed.

Web Parts interact with the Web Part Manager control, which itself adds and maintains the instances of Web Parts that are added to Web Part zones either at page design time or at run time.

Web Parts render inside of chrome.

Forms Authentication vs. Windows Authentication<h1></h1>
http://msdn.microsoft.com/en-us/library/bb977430.aspx#MOSSFBAPart3_IntegratingWithOffice2007

See the Forms Authentication Integration Update for Office 2007 part.

http://technet.microsoft.com/en-us/windowsserver/sharepoint/dd355701.aspx

http://www.simple-talk.com/dotnet/windows-forms/configuring-forms-authentication-in-sharepoint-2007/

http://technet.microsoft.com/en-us/windowsserver/sharepoint/dd251268.aspx

How to configuring SQL Server 2005 for Remote Access http://www.datamasker.com/SSE2005_NetworkCfg.htm

Extra steps:

1. Should use hostname\SQLEXPRESS (or .\SQLEXPRESS) as the server name to access the DB in “ASP.NET SQL Server Setup Wizards”
2. Create firewall rules for port 1433
3. In SSMS, change the “Server Authentication” to “SQL Server and Windows Authentication mode”

Windows SharePoint “How do I” Videos:   http://technet.microsoft.com/en-us/windowsserver/sharepoint/dd353225.aspx

http://www.yuvalararat.com/2006/06/sharepoint-server-2007-anonymous-access-howto/

1. Enable anonymous in IIS

2. Enable anonymous in SharePoint admin site

3. Enable anonymous in target SharePoint site.

In Central Admin/App Management/Authentication Providers, click on your provider. There is an option for "Enable Client Integration". If it is set to no Connect to Outlook does not work.

http://msdn.microsoft.com/en-us/library/bb977430.aspx#MOSSFBAPart3_IntegratingWithOffice2007

http://social.msdn.microsoft.com/Forums/en-US/sharepointadmin/thread/7eb091ee-0253-4df5-bbb1-749dab8c332f

http://www.tonytestasworld.com/post/Howto-Start-a-Sharepoint-Workflow-Programmatically.aspx

http://www.sharepointkings.com/2008/09/how-to-start-workflow-programmatically.html

a farm is a set of one or more server computers working together to provide WSS functionality to clients.

An IIS Web site that has been specially configured to run WSS sites is known as a Web application.

The installation of WSS creates and configures a Web application named the WSS 3.0 Central Administration application.

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. A site can either define its own set of users, or it can inherit the users of its parent site. A site also contains a configurable set of groups and permissions that define the level of accessibility that various users have on the site’s lists and document libraries.Third, a site is an application with an extensible, fully customizable user interface. A site administrator can create pages and customize their layout and appearance. A site administrator can also modify a site’s navigation structure using the browser. Finally, a site is the foundation for using the Microsoft Web Part Page and Web Part technology.

Every WSS site must be provisioned within the scope of an existing Web application. However, a site cannot exist as an independent entity within a 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.

WSS 3.0 has added a valuable new innovation known as the site column. 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. Once you have defined a site column, you can then use it as you define the schema for custom lists and document libraries. An obvious advantage is that you can update the site column in a single place and have that update affect all the lists where the site column has been used.

WSS 3.0 adds a second powerful innovation focused on content storage. It is known as a content type. 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. Then you can create a new document library and configure it to support both of these content types. The introduction of content types is very significant to WSS 3.0 because it provides an ability that did not exist in WSS 2.0 to deal with heterogeneous types of content in lists and document libraries.

Another great new development opportunity is to work with the new Office Open XML file formats. This new technology introduced with Microsoft Office 2007 provides you with the ability to generate and/or manipulate Microsoft Office Word documents and Microsoft Office Excel documents from server-side code within custom components such as event handlers and workflows. What’s nice is that the Office Open XML file formats eliminate the need to install and run a version of a Microsoft Office desktop application such as Office Word or Office Excel on the server. Everything can be done by programming against server-side libraries, which provide high degrees of scalability and robustness.

Though there are many different avenues for custom development in WSS, you should start off by learning about features. Features are a new developer-focused innovation that has been added to WSS 3.0. 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 user-friendly Title.

While a custom feature allows a developer to define one or more elements that can be activated inside the context of a site or site collection, WSS also provides a developer with the ability to define the entire blueprint for a site by creating a custom site definition. The development of custom site definitions allows a developer to take control over every aspect of a new site such as its branding, its initial set of lists, and which features it uses. Chapter 9, “Solutions and Deployment,” is dedicated to working with site definitions.

Another important aspect of WSS development is programming against the WSS object model. The core types provided by the WSS programming model are exposed through a standard WSS assembly named Microsoft.SharePoint.dll (under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI).

When you modify a page and save a customized version of it in the content database using SharePoint Designer, you eliminate the possibility of page ghosting. Instead, the provided SPVirtualPathProvider must retrieve the customized version of the page from the content database, as shown in Figure 2-6. For this reason, customized pages are sometimes referred to as unghosted pages.

Pages that support user customization are known as site pages. This security concern is mitigated in WSS by having a default policy that prohibits in-line scripting in site pages. The default policy also runs site pages in a no-compile mode, which means they are not compiled into DLLs.

WSS architecture provides another type of page known as an application page. One of the key characteristics of an application page is that it does not support customization. Therefore, application pages can circumvent some of the main performance concerns and security issues associated with site 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. Site pages do not support in-line code under the default security policy enforced by WSS.

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. Now that you have a basic understand of what constitutes an application page, it will be worthwhile to see what is involved in creating your own application pages for a custom solution.

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.

Debug WSS Components

<configuration>
  <SharePoint>
    <SafeMode CallStack="true" />
   </SharePoint>
  <system.web>
    <customErrors mode="Off" />
    <compilation debug="true" />
  </system.web>
</configuration>

Two Tokens: ~site ~sitecollection

~masterurl/default.master ~masterurl/custom.master

Site Page

A Module element can be thought of as a file set. 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, whereas the file instance being provisioned is being created inside the context of a particular site.

Inside the TEMPLATE directory resides a nested directory named CONTROLTEMPLATES. This directory contains many different user controls that are deployed as part of the standard WSS installation. The CONTROLTEMPLATES directory is also a place where you should deploy custom user control files.

Site pages and application pages use separate master pages.

A Web Part is a class that inherits from the WebPart class defined in the System.Web.UI.WebControls.WebParts namespace inside the System.Web assembly. The Web Part is a special type of Web control that is deployable inside of a Web Part Zone control after the initial page has been created and deployed.

The Web Part Manager class that SharePoint uses is SPWebPartManager, which is a bridge between the page’s Web Part Zone objects and the content database. When you add a Web Part to the page, you are actually adding a serialized instance of the Web Part to the content database.

Web Parts render inside of chrome. Chrome refers to the common user interface elements, such as a formatted title bar and borders around the Web Part’s body that the framework adds to controls. The chrome adds a bit of style to your Web Part in a way that is consistent with the user interface of the application.

A Web Part Verb is an action that is rendered in the Web Part menu by the Web Part framework as part of the chrome that is rendered around the control. The action can call a client-side function or a server-side handler.

Content types are a powerful new enhancement introduced in WSS 3.0. The central idea is that a content type defines the underlying schema for either an item in a list or a document in a document library. However, it’s important to understand that content types are defined independently outside the scope of any list or document library. After you have created a content type, you can use it across several different lists or several different document libraries.

For example, imagine you create a content type named Company that defines a set of columns for tracking information about a company. After creating this content type you could then create two different lists named Vendors and Customers and configure both of these lists to use the Company content type. This gives you something akin to polymorphism, because you have two different list types that contain homogeneous items that are defined by the same schema. With an application design such as this, you can write a Web Part by using the SPSiteDataQuery that queries across lists and sites to find and display all the items that have content based on the Company content type.

Content types also provide you with the ability to maintain heterogeneous content inside a single list or document library. For example, you can configure a single list to support multiple content types. Imagine a business scenario in which you need to track customers, and those customers may be either companies or individuals. The problem you face is that customers that are companies and customers who are individuals require different columns to track their information. The solution is to create two different content types for each type of customer and then to create a Customers list and configure it to support both content types.

Item-based content types are used exclusively in lists, and document-based content types are used exclusively in document libraries. You should observe that no content type can be used in a list and also in a document library.

In terms of general WSS architecture, it’s important to observe that a document library is really just a specialized type of list. Similar to any standard list.

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.

A site definition itself does not represent a creatable site template. Instead, 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.

Note that almost everything that can be defined in a site definition can also be defined in a feature. Features should be used for implementation, and site definitions should be used to aggregate features into user-creatable site templates. Both the Features element and the site definition Project element share common XML schema defined inside wss.xsd.

Note that the resource format within CAML is $Resources:ResourceFile,ResourceName;, where ResourceFile is the name of the file and ResourceName is the name of the string within the file. The WSS runtime replaces this as it parses the CAML. Note that you can access the localized site definition (which is cached for the Internet Information Services [IIS] application lifetime) through the site-relative URL _vti_bin/owssvr.dll?Cmd=GetProjSchema.

Timer Job

http://msdn.microsoft.com/en-us/library/cc406686.aspx (Code)

http://sharepointmagazine.net/technical/development/the-dog-ate-my-task-use-sharepoint-designer-to-email-daily-task-reminders (Designer)

http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=271 (Hierarchical Object Store)

http://office.microsoft.com/en-us/sharepointtechnology/HA101544311033.aspx