Building a Better ASP.NET 1.1 BasePage Framework --By Chase Thomas

This is a journey on how to build a better Base page. The result of this will be a reusable framework that you can use to create as many Base pages as you like (on many different sites) and still have something that will keep the designers on your team happy. There is a lot to explain so I am breaking this up into several parts starting with the pros and cons of all the approaches I have seen in the past.

Whenever I start a new ASP.NET project I am asked how to make a look and feel that can be reused on all pages of the site. The following are the several approaches I have seen to date:

Have a designer create an HTML template and reuse it in all your pages

  • Pros
    • No need to recreate the look and feel for each page.
    • You can see the look and feel in the designer (big deal) :P
  • Cons
    • You have to cut and paste the HTML into all your pages.
    • You have to maintain all the pages on the site to make the simplest change to your site (not much of an advantage if you ask me).

Comments: This is the approach I have seen done by folks breaking into ASP.NET development. Maintaining sites like this can be a nightmare to say the least. Just pray your client does not ask to change the main look and feel or you will be staying late to get it done…

Create user controls and reuse them on all pages of the site

  • Pros
    • Simply drag and drop your UI into your new pages and you're done!
  • Cons
    • Difficult to maintain the site because if you need to remove/add user controls in the Base layout, you have to touch every single page in the site.
    • You cannot see the complete look and feel in the designer (again – big deal).

Comments: This is a little better as it makes use of User Controls to centralize the look and feel into separate components but can still be problematic and time consuming when the main look and feel templates need to be added/removed.

Create a base page and hardcode the look and feel into the base page’s OnInit() call

  • Pros
    • Now we're getting somewhere! We no longer have to maintain the main look and feel across the entire site from each individual page – nor do we need to worry about changes to what elements are added to the main UI because we can change it all from one place.
  • Cons
    • Very difficult to maintain from a designer perspective (there is no designer support for this approach available), try telling that to your web design team and see what happens.
    • You will need to recompile the site if the slightest HTML changes need to be made to the look and feel of the site.
    • You should not do this in the OnInit() because it does not guarantee that your controls will be in place at all phases of execution within your ASP.NET pipeline, the code for generating the base page should be in the CreateChildControls() call. You can force CreateChildControls() to be called by calling EnsureChildControls().

Comments: We used this approach at two different client sites and it worked well. However when I presented this approach to the client I was at when I wrote this, they balked and wanted to know how to use the visual designer and also how to make changes without compiling and redeploying the site DLL. The next approach is the answer to that question.

Create UserControls for all the sections of your main look and feel, and dynamically load them when your Base page is generated

  • Pros
    • Designers can alter the HTML of each user control without recompiling the website DLL (unless they add server controls).
    • You can make changes to the site’s look and feel without having to change any Base page code (in most cases).
  • Cons
    • You still have to deal with hardcoding the layout of your controls into the Base page (not cool).

Comments: Although this approach served us well at a client site, we also did not have to worry about them changing the main layout (yet). If that happens I am going to recommend migrating to the next approach which is the approach we are going to be implementing in this series of posts related to this topic.

Build a Basepage base framework in a separate library and reference it in your websites – derive from this Base page and create 1-n Basepages that you can use within your site – make each Base page configurable in the Web.Config file

  • Pros
    • Designers can alter the layout and look and feel of your site from not only the separate UserControls (which I call base controls or Base controls) but also from the UI layout, which is just another UserControl with placeholders.
    • All information about how to generate the HTML header and what styles / scripts to link in and how to set up the body tag can be altered from the web.config.
  • Cons
    • Still – the full support of having the Base page elements viewable in the designer is not available (you’ll just have to wait for the MasterPages in ASP.NET 2.0).

I mention ASP.NET 2.0 here because the fact that it’s coming soon will make most of the ASP.NET 1.1 techniques in this article obsolete.

Comments – We have used this approach at several clients in the past, it has worked well in the past. One of the things I did not like about it was the lack of centralized configuration and no way to solidify the state objects in our site. It would be nice to have a framework that did all this, that is what we are going to do in this article.

So why write this article? Simple, even though I have seen a lot of companies upgrade their systems to Windows 2003 Server, Windows XP and have embraced using the .NET framework, I do know of a few places that are still stuck using NT 4 Server (even though the client machines are on Windows 2000 Professional which for them are doing well). So yes, using this approach will be invalid when VS.NET 2005 is released to the world. But for the rest of us that get stuck working with old technology, this will be a huge timesaver.

To close this section, I will describe the steps to get started on your own BasePage Framework implementation.

  1. Create a Class Library Project, call it “BasePageFramework”.
  2. Add the System.Web reference.
  3. Create a SuperBasePage class and inherit from System.Web.UI.Page.
  4. Create a class and call it BasePageConfigurationHandler. Implement the System.Configuration.ICustomConfigurationHandler interface.

Add an XML file so we have a place to put our configuration stuff (this does not need to be part of the project, it’s just a nice place to keep our configuration schema for the Base pages).

Add the following XML to the schema…


    
/

你可能感兴趣的:(Building a Better ASP.NET 1.1 BasePage Framework --By Chase Thomas)