AspAlliance.com LogoASPAlliance: Articles, reviews, and samples for .NET Developers
URL:
http://aspalliance.com/articleViewer.aspx?aId=1721&pId=-1
SharePoint Application and Site Pages - Part 2 of 2
page
by Steven Barden
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 34974/ 70

Introduction

A recap of Part 1

As it was previously described in part one of this two part series, there are two primary types of pages found in a WSS application, Application Pages and Site Pages. The first type of SharePoint pages (they can go in either order by description really) are Application pages, and are generally aspx pages that you will find used across multiple sites. This is due to the fact that any SharePoint site, by default, uses the same various virtual directories that point to the 12 directory (usually "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12" in a standard windows and SharePoint install). Since all SharePoint sites use the same directories, they all use the same pages, which are commonly "behind the scenes" type administrative type pages. The other type of page, site pages are those pages that are used inside an individual site for direct user interaction. These are basically, user level pages that make up the site, for example the default.aspx page. When you enter a site as a user you will probably be viewing Site pages. As a user, you will rarely see Application pages, with a few exceptions… certain login and error pages may be examples of Application pages of a site that users may see. Ironically, these are also the types of pages that managers may complain about "not looking like the rest of the site". The reason for this and possible solutions (but not all possible solutions) were discussed in Part 1 or this article.

Beginning the new project

This article and project are designed to cover building and deploying an Application page in a way that builds upon the previous part of this writing. It is assumed at this point that you have very likely used the SharePoint Designer at some time to build a SharePoint website. This is a pretty straight forward process, whether the site has built in page templates or not. It is not too difficult to add a new ASPX page to the existing site and customize it according to your needs. This author is likely to detail more about this in a later article, or you can certainly find more examples of this objective on the internet. But because building and deploying Application pages is more involved, this will be our objective.

So with that said, let's get started building and deploying this project. To give you a basic heads up of what to expect, the following are some highlights of what will take place with this project as we move forward…

1.    Begin the project with Visual Studio 2005.

2.    Open and make use of all components that are needed, including building ASPX and code-beside pages by hand.

3.    Deploying the application.

In all, it is basically that simple, so let's begin…

Writing the code

·         Open Visual Studio 2005 and begin a class project. It may seem odd that you are beginning with a class project, rather than an ASPX project, but more will soon be revealed.

·         Right mouse on references and select Add. You have likely noticed this before, but don't be surprised or concerned when it takes time for the desired window to pop up in place.

·         Select the "browse" tab and enter “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.SharePoint.dll” if you're using a standard install.

·         Do the same for "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Web.dll"

NOTE: It should make sense that you would add a reference to the SharePoint assembly but the manual reference to the assembly "System.Web.dll", might be a bit of a surprise. This goes back to the information described above… you are starting with a windows assembly project, but you need to add the information required to manually build ASPX pages. You will see more information like this as move farther along.

·         Rename the namespace, class, and file as desired.

·         Compile to ensure all is in order (<Control> + <Shift>+<B>)

·         In the root of the project add a folder named TEMPLATE.

·         Inside that, add directories named FEATURES, IMAGES and LAYOUTS.

·         Note that this example will not use UserControls on the page(s), but if you were to do so you would add a CONTROLTEMPLATES directory as well, which would hold the user controls. Recall the intent (as described in the previous articles, Developing and Deploying a SharePoint Feature - Part 1 and Developing and Deploying a SharePoint Feature - Part 2, found by way of the link, http://aspalliance.com/author.aspx?uId=45726) is to duplicate the directory structure found at "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE". In description of the directories we have created, the FEATURES directory is where we will turn on and off this functionality. The IMAGES directory is pretty straight forward, and while the LAYOUTS directory may not be as obvious by the name. This is where your ASPX pages will be placed.

·         At this point it is it is important to acknowledge the intended name of the project because various sub-directories use this name. We will use DevAppPages, and as such each of the directories used will get a sub-directory named such.

·         Next we will create an ASPX page inside the LAYOUTS\ DevAppPages directory. Since we did not start this application as a web application we will not have the selection of a web page to add to our project, necessitating that we do this from scratch. Luckily there is not very much that needs to be added to a text file to make it an ASPX page.

·         Start by naming it what you want with an .ASPX extension.

·         Add an ASPX type reference to the four part version of the SharePoint DLL. In this case it is "<%@ Assembly Name="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>"

·         Add the four part name of the assembly for this project.

·         Using the project properties, assign a public key.

·         Open Reflector, open the compiled assembly in Reflector and copy everything from Name to the end of the public key token, being sure to change various characters as needed, such as the ":" after the name for "=" and adding double quotes where needed.

·         The end result should be "<%@ Assembly Name="Pages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c475c2fd38120dac" %>", or your version of it.

·         Finally add the Page declaration and the appropriate entries, "<%@ Page Language="C#" MasterPageFile="~/_layouts/application.master" Inherits="Pages.AppPage1" EnableViewState="false" EnableViewStateMac="false" %>".

·         Notice the location of the MasterPageFile… clearly this is intended for when the page reaches its final location.

·         Before I continue, I want to give credit to Ameet Phadnis for publishing an excellent article at http://aspalliance.com/1376_Customizing_WSS_30_with_Master_Pages, which covers (as it says) Customizing WSS 3.0 pages. He also references the Microsoft page http://office.microsoft.com/en-us/sharepointdesigner/HA101651201033.aspx#1, which, among other points, has a list of Content Placeholder names and descriptions that you will find helpful.

·         Now drop to the bottom of the page and manually add a place holder, "<asp:Content ID="Main" contentplaceholderid="PlaceHolderMain" runat="server"></asp:Content>"

·         Do the same for "<asp:Content ID="PageTitle" runat="server" contentplaceholderid="PlaceHolderPageTitle" ></asp:Content>"

·         Save and switch to the Design view and make various adjustments as desired, including adding a label that will be filled out later with the site name.

·         Switch to the AppPage1.cs file and (if you have not already) add the using statements for a web page and of course a reference to the SharePoint assembly. Also add a reference to the SharePoint.WebControls assembly. As you are likely aware, SharePoint sits on ASP.NET and inherits much of its functionality from it. This is the way to reference SharePoint's inherited functionality for building web controls.

·         In the name of the class, add the inheritance to the LayoutsBasePage. While on this step, ensure that the class is set as public.

·         In order for this class and the ASPX page to work together properly, since they were not added at the same time you need to add the required control references on the page to the class where you need interactivity. As such, since you will not affect the functionality of the placeholders, you do not need to reference them, but since you want to use the label in the page from the class, you want to make a reference to a label. The .NET and ASP.NET runtime will make the leap to link the two so long as the names match up. If you think about it, this is what an automated ASP.NET project is doing via Visual Studio. You are simply doing it manually here.

·         Now make use of the page OnLoad event. You can place the next statement inside this block or outside.

·         Use the following statements on two different lines to "drill into" the site to get the name, then add it to the label… "SPSite siteCollection = this.Site;", "SPWeb site = this.Web;", "LabelSiteName.Text = site.Title;".

·         That is it… you are complete with this stage. At this point your page and its corresponding class / assembly are complete.

Deploying the application

·         I am now going to make some references to a previous writing I made, called "Developing and Deploying a SharePoint Feature - Part 1".

·         That writing was actually completed very much with this goal in mind, to be used as a basis for pushing SharePoint work by way of Features. Although there are differences between the previous project and this one, which of course will be described, you could basically copy the components from that project into this project to get started. In fact, I suggest you do so, after of course reading the previous article in its entirety.

·         There will be one major difference between the basic Feature article and this one… a menu change. When it comes to this project, you can of course build the application page, and then actually navigate to it via the URL bar, but you are likely at some point going to want to be able to navigate to various pages based on menu options. This adaptation of the Feature project will allow you to add a menu option that can be used to navigate directly to a desired page, in this case the Application page we are building. As a quick peak ahead, you will do this in the elements XML file.

·         The install.cmd page needs only minimal changes.

·         After adding the feature.xml file, open it and change the ID, Title, Description, Version and ImageURL attributes as required.

·         Finally, change the ElementManifests section as the following, <ElementManifests><ElementManifest Location="elements.xml" /></ElementManifests>

·         This concludes the adjustments to the Feature.XML file.

·         Next add an xml file along-side the Feature.XML file, called Elements.XML. This will be used for specific information related to the components, in this case, the Application page we have constructed.

·         If you are using the example code simply review the code, copy and paste it into your project, adjusting it as you see fit.

·         I will not dig deeper into the lines at this time because this should be enough to get you started. Of course I would highly encourage you to review the Microsoft Windows SharePoint Services 3.0 SDK to review all of your options. Hint… search "elements.xml CustomAction"

·         You should now be prepared. Go to a command prompt and run the Install.cmd file. Open a browser to the site you are used to working with and login. Navigate to the settings, Features and turn on your new feature. After a refresh you should see a new option on your drop down menu that should lead to your new Application page.

·         If you find that your needs are to connect to Site pages with menus, instead of Application pages, so long as you know or can build the URL, you can do what you want here as well. A future article I plan to write will cover the act of programmatically, dynamically building menu links to both Application pages and Site pages, but at this point you should be starting down the right track.

·         Smile and be happy… all should be well.

Downloads
Conclusion

This article should do well in displaying the ability to use Visual Studio 2005 and SharePoint 2007 to build and deploy Application pages for your needs. Certainly not all circumstances are the same of course, and not everything shown here may align perfectly with what you are looking to do, but I certainly hope it does provide a good start point for not only beginning your construction and use of Application pages, and deploying them, but also how to make some simple changes to your menus for the purpose of accessing your custom pages, whether they are Application pages or Site pages.


Product Spotlight
Product Spotlight 

©Copyright 1998-2019 ASPAlliance.com  |  Page Processed at 2019-11-14 9:29:37 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search