Single Paged Web Application Approach

SINGLE PAGED WEBSITE DEVELOPMENT APPROACH

Introduction

Pages in Web applications often share common UI components, such as headers, sidebars, and footers. Win-Form Developers can encapsulate these common controls into a Master form. However, in ASP.NET, this can be a nightmarish. This is because there is no direct way to structure an application to accomplish such �Template Effect� in ASP.NET.
This article uses some of the ASP.NET concepts like Web User Controls and Caching to show you how to tackle the challenge of building an effective page templating scheme. As you will see, combining a Web Controls that represents the different components of Web UI, each containing its own template code, you can achieve an elegant yet simple and reusable approach that's easy to maintain and takes full advantage of the ASP.NET framework. This approach becomes especially important when dealing with complex sites containing large data-driven pages that require page-level customization.
I am sure everybody who reads this article spent too much time designing complex master-context page approaches involving custom controls, bubbling events. After revisiting existing patterns I've used before and what's proposed by the others so far, I've come up with my own approach of Single Paged Website Approach by which we can accomplish Template Effect in ASP.NET Application in easy and flexible manner.

Basic Idea

The basic idea of Single Paged Website approach is to think of website not containing pages but containing custom controls. Previously, where you were defining and implementing functionality in Web Pages, this approach tell us to do this in custom controls.
The idea is to separate the development process of Master Page and a Context Page making it possible to contain style definition and common basic functionality inside the Master Page and letting the Context Page handle the main functionality.
As the name suggests Single paged website approach contains only one class derives from Page class for the initialization of the application. This page will act as the Base or Master Page for website and will define Template Frame in which all of the defined custom controls will be rendered. The mechanics are simple:
� The Thumb rule of this approach is to think in terms of custom controls not in terms of pages. Like instead of creating Login.aspx page for login operation, create Login.ascx and code logic in its code behind in same way as you would have done in case of login.aspx.
� By translating your pages into custom controls you are indirectly creating Context Pages that will be dynamically loaded inside the Master Page.
� Create common user interface elements like header, footer, menu, sidebars that would appear on every visited page. Place them on Master Page Template.
� Create Master Page for your website. This will be the only .aspx page. You can name it default.aspx or index.aspx (whatever you like) and decorate it with common user interface elements you made in previous step.
� Instrument Master Page with the code responsible for the dynamic loading of Context Pages (custom controls) into special placeholder inside the Master Page.

Doesn't sound like a very hard approach to do in .NET, does it? Now let�s go into the nitty-gritty of each step and find out how it should be done and what are their benefits.

Explanation

I will explain this approach by using an example. In this example we are making web application for HR Department. This sort of application usually contains number of screens and operations. But as an example, we will be working on Login Screen and Employee Info Processing Screen (Add, Delete, and Edit) to prove the concept of Single Paged Website.

1. Creating Context Pages

Create Login and Employee Info Screen as Custom Controls and place executable code for these screens in code behind of these custom controls. The custom controls are just like .aspx pages having same Page Cycle Global Events (Page_Load, Page_PreRender, Page_Unload). By creating these screens as custom controls you are done with the context pages part.

2. Create common user interface elements

Create common user interface elements like header, footer, menu, sidebars that would appear on every visited page. Place them on Master Page Template.

3. Creating Master Page

Till this stage we are done with our context pages in so simple manner. Our next task is to design and implement Master Page for this application which is the only page (.aspx) in our application. Add Web page (.aspx) to your web application namely default.aspx. As you know ASP.NET master pages allow you to create a consistent layout for the pages in your application, create HTML layout of this page in such a way where you can place your menu, header, footer in whatever fashion you want. Normally, we divide web page layout in header, footer, side bars and content area. Place your already created custom controls for header, footer, side bars on this master page in their respective places. Place Placeholder web control in the content area. This placeholder will be responsible for the rendering of context pages.

4. Instrument Navigation Logic:

In your normal design, the links of the menu directs to the URL of destination page. For example

<A class="toolbar" id="Employee_Page_HyperLink" href="~/EmployeePage.aspx" runat="server"> Employee </A>

See href, its directed to EmployeePage.aspx. But in single paged approach this will contain the URL of Single Page (default.aspx) with query string like Page=Employee. We will use this query string to determine which custom control to load. Below is the example HTML fragment of my menu:

<td style="WHITE-SPACE: nowrap">
<A class="toolbar" id="Login_HyperLink" href="~/default.aspx?Page=Login" runat="server">Department</A> 
<A class="toolbar" id="Employee_HyperLink" href="~/default.aspx?Page=Employee_Master" runat="server" >Employee</A>
</td>

The navigation logic uses the query string for the change of screens. When user clicks on the menu link, the link will request the same page with the query string parameter containing the control to load. The Master or Base page will then render that requested control in the placeholder placed on master page. The code behind of my default page will look something like this:

public class MainPage : System.Web.UI.Page
{
protected string currentScreen = "Login";
 protected System.Web.UI.WebControls.PlaceHolder PlaceHolder1;
 protected Control screen;
public const string QRY_STRING_PAGE_NAV = "Page";
 public const string USR_CONTROL_EXT = "ascx";
 
 
 
 private void Page_Load(object sender, System.EventArgs e)
 {
   
  if (Request.QueryString[QRY_STRING_PAGE_NAV] != null)
  {
this.currentScreen = Request.QueryString[QRY_STRING_PAGE_NAV].ToString();
    
  }
  
  try
  {
   screen = LoadControl("Include/UserControls/" + this.currentScreen  + ".ascx");
   this.PlaceHolder1.Controls.Add(screen);
  }
  catch(Exception ex)
  {
  }
 }   
}

Note: If you closely see above code I am maintaining currentScreen Variable for the current screen name. Initialize this variable to the name of first screen which will be visible to the user when user types in your website address in web browser. Similarly you can say it default context page.

In this way you can create flexible and easy to maintain web application with the single page. Merging this approach with MVC architecture will make you application more scalable.

Why to Use This Approach

1. This is easy to use approach. You can easily plug-in new screens by creating new custom controls for each of these screens without worrying about navigational code.

2. You can use Fragment Caching to cache common user interface elements for improved performance. In this way only context page code will run on server.

3. This approach provides enhanced security as physically website will contain only single page, so if someone tempers the URL in query string to provide invalid value as page name, the application will not show YES (Yellow Error Screen).