NOTE: If you haven't read the first post in this series, I would encourage you do to that first, or check out the Sharepoint category. You can also always subscribe to the feeds.

The Sharepoint 2007 System introduces two types of pages the first type usually called Application Pages and other type called Site Pages.

As a sharepoint developer you should know both of these types of pages and when to use them, so let me define them here briefly and show some differences between them to help you decide which type of pages you will want to use when developing in sharepoint.

Application Pages

Application Pages are non customizable and are found in  the C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS, its worthy to note that this physical directory is mapped to the virtual _layouts directory whenever WSS/MOSS creates a new Web application in the IIS. By using this mapping scheme along with some additional processing logic, the WSS/MOSS runtime can make each application page accessible within the context of any site in the farm.

When building custom application pages you should use the Microsoft.Sharepoint.LayoutsPageBase as a base class and should be content pages that reference to the ~/_layouts/application.master master page, Application Pages might include in line code or have a code behind file compiled in a dll, to deploy application pages they should be the LAYOUTS directory and all custom code dlls either in the GAC.[more]

Site Pages (Content Pages)

Site Pages can be customized on a site-by-site basis. default.aspx page in the Blank site is considered a site page as well as the AllItems.aspx used in lists. When customizing site pages this might lead to hundreds of versions of one site pages, site pages have only one physical version and all customized pages reside in the Content Database of the Web Application. This leads us to one important optimization point known as page ghosting, 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? Ofcourse not, rather than copying 100 version of the same page in the content database, the WSS runtime 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.

Security consideration : Since the site page can be customized for every customized version, a copy must be stored in the content database, which in turn raises a security issue what if a user having an administrator permission and tries to write in line code within a customized version. This security concern is dealt 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.

 

Conclusion

In this part I just scratched the 2 types of pages used in the Sharepoint System I have to say that there is more and more to talk about on this topic which I will write more through this series.

A new feature in the Sharepoint 2007 is the "Feature" development style which means that every tiny and huge development task in the sharepoint is considered a "Feature".

Features can be activated or deactivated through a site administrator, which enables the very simple turn on/off of anything in the site.

Features are used for developing anything starting from a small button to a full site definition and tons of files and functions including webparts, workflows, lists, pages, content types, document libraries and others. I will try to include the development of all these topics in this series wish me luck and provide feedback. [more]

For a start I will show here in this part how to get started with the feature development and the basic elements and files needed for a developing and deploying a sharepoint feature.

Before opening the Visual Studio and starting to code, knowing what the files and where will they be deployed on the server will be mandatory. A very basic feature will include 2 xml files one named feature.xml and the other will hold the elements of this feature usually named elements.xml or elementsManifest.xml, consider that the files for any feature must be deployed in their own special directory inside the WSS system directory named FEATURES. The FEATURES directory is located inside another WSS system directory named TEMPLATE.

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES

In our Hello sharepoint feature we will make a very basic feature named HelloSharepoint that when activated will add menu item in the SiteActions menu that will redirect to google.

Feature.xml

<Feature
Id="{INSERT-GUID-HERE}"
Title="Hello Sharepoint Feature"
Description="This is a custom feature which adds a custom item to link to google"
Scope="Web"
Hidden="FALSE"
ImageUrl="google.gif"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="ElementsManifest.xml" />
</ElementManifests>
</Feature>

As shown above the feature.xml looks very simple, only Id and Scope are the two required attributes and all the others are optional and a full list can be found here.

ElementsManifest.xml

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction
Id="SiteActionsToolbar"
GroupId="SiteActions"
Location="Microsoft.SharePoint.StandardMenu"
Title="Hello Sharepoint"
Sequence="100"
Description="A custom menu item links to google"
ImageUrl="_layouts/images/google.gif" >
<UrlAction Url="http://www.google.com"/>
</CustomAction>
</Elements>

And the elementsManifest.xml here describes the elements to be installed with the feature and we only define one element (a CustomAction) you find a bunch of types of elements to be added here.

That's all we are done with building our very first feature inside the WSS/MOSS world, I know some of the attributes here seem vague and other seem simple anyway I will try to put a part or two for only discussing these files with their various options.

 

Deploying the feature

 

1. Copying the feature files (feature.xml and elementsManifest.xml) in the Features server path
   C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES , and the google.gif in the C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\images
2. Running STSADM.EXE operation to install the feature with WSS/MOSS "stsadm -o InstallFeature -filename HelloSharepoint\feature.xml -force"
3. Restarting IIS
4. Finally, activating the features within the site administration

SPpart1.zip (6.74 kb)

I mentioned a long while ago that I will work on some sharepoint and workflow foundation in order to enlarge my development knowledge base, I learned some stuff on the way may be all sharepoint and workflows beginners already know them but I love to share them for others.

I will start another series for sharepoint development (for beginners as myself) so If anyone out there finds out a better approach for anything I write or correction welcome for commenting on the posts so all can benefit too.

This series will start with introductory posts that are needed to understand the architecture and object model of sharepoint, these introduction points are all over the web and blogs of sharepoint pros, I will write them again in my wa, then proceed with some basic development then advanced, I don't have an outline for the posts I am gonna write I have some ideas any reader is welcome to add in comments any topic related to sharepoint development wants me to write about, hoping this series be useful like my older one Design Time Support of Custom Controls, so wish me luck.