A RAD (Rapid Application Deployment).ASP Architecture: Introduction

Introduction

Truthfully, how many sites have *you* really built?  Then, ask yourself how many have you actually maintained?  By maintaining, I mean creating new content pages and linking them in -- not merely updating the text on a site (which I view as an administrative effort).   This article will explain many facets of how to design an architecture for a web site that you will be able to reproduce, and place the management of content (where it is usually most cost-effective) with a site administrator almost effortlessly.

NOTE: This article is a work-in-progress and will be updated periodically.

Background

I am a do-it-yourself kinda guy.  I am from the days way-back-when you had to scour bulletin boards to glean the programming voodoo that we do.  Although books can be helpful, many times they miss the mark or are examples of generic stuff.  When the internet came around this offered a huge medium for us programmers to learn with, this article is an attempt to give something back to all of those folks who have religiously offered up their ideas for free to everyone else.

I started programming very young around 1984. I have worked through a bunch of different programming languages and when the web came around I thought - what an easy way of programming.  I jumped into HTML and started building page after page after page after page.  Wonderful I thought!  Then I had to start updating content.

In my experience, there are two types of programmers -- those that are great at proto-typing, and design and those that are great at maintenance.  Each has a very distinct and undeniable purpose.  Sometimes you find one that crosses-over into each field.  I am the creative type and if you want to truly take a proto-typing programmer and turn them into a mass of vegetable mush, relegate them to updating text in a site.

Then... this great thing called Active Server Pages (ASP) came around.  "FINALLY", I said.  I can hook a database to all of this content and allow my clients to more cost-effectively maintain it.  Well, that is what I told them of course -- that was about 20% of my motivation, the other 80% was my sanity.

To pull this off, I then found out that instead of having to update a hundred "content" pages all the time, I had to now build 100 data-entry pages for an administrator to be able to "update" that content.

Now, I have this big architecture of both site content and administrative management pages that if I would like to reuse to any degree for another client, I have to completely retool their layout (so it doesn't look the same).  Anyone that has done this knows just how daunting a step this can be.

To solve this cross-client problem, a new technology called XML looked intriguing (albeit a bit bloated from a datastream perspective) and I thought, "hey what if I put the whole page in XML", used server-side includes and XSLT to transform the page layouts.  This way I could still have 100-plus pages, but only have to minimally update the few items that change on a page-per-page basis by putting each page into a XML tag.  Then, when a new client comes along I can just change the XSLT template that transforms that XML "page layout data" into a new client-specific layout.

*NOW* I can crank sites out and not have to retool the whole site top-to-bottom each time I build a new one.

This also better segments the roles of the people involved.  I can throw in an Architect to figure out the layout / business process flow initially to prototype the framework, then have an Engineer "own" the thing as new items are needed, and an Administrator manage the day-to-day content of the site.  This approach seems to work well for me, and is cost-effective and intellectually gratifying from a people perspective (which can actually be a big factor in rollouts).

NOTE: This architecture, was actually put together before .NET came around, so some of it might be useful to those of you who haven't taken the leap.  That said, the application of this could be accomplished in any web / server scripting language and is not limited to just using ASP. I do however believe that migrating to .NET in whole or at least in part can offer a few new optimizations.

The Series

The series of articles I will be publishing will be as follows:

• 100 - An Introduction
• 101 - The Business Processes
• 102 - The Site Layout
• 103 - The Database
• 104 - Server-Side Includes (SSIs)
• 105 - XML Data-Islands
• 106 - XSLT - Layout Implementation and CSS (Cascading Stylesheets)
• 107 - XML Layout Templates

100 - An Introduction

This article, the first article of the series, outlines and describes all of the other series articles and their content.

101 - The Business Processes

This article will discuss some of the considerations that need to be understood of the business processes you are implementing as well as their importance.

102 - The Site Layout

This article will discuss some layout and design considerations and things to think about when designing a layout.

103 - The Database

This article will discuss some of the database considerations for our architecture.  While I will most likely use SQL Server, any database should do, although I have a huge preference for databases which support GUIDs.

104 - Server-Side Includes (SSIs)

This article will discuss the concept of Server-Side Includes (SSIs), how to use them, and some of the "gotchas" when they are used.

105 - XML Data-Islands

Now that we have the business processes, the data, and the layout defined - we can start building XML.  This data we will later use when building each page.

106 - XSLT

This article will discuss how to use a technology called XSLT to convert our XML data into HTML

107 - XML Layout Templates

Instead of hard-coding each page, we will take a look at using XML and XSLT to actually build the layout portion of our pages and then point the items in the page to various XML data-islands.

Points of Interest

I have to give some credit to Kundan Narendra for writing his article on Server-Side Includes to help kick me in the butt and just write this thing.  I have been wanting to for some time.

History

• 05.07.2003 - Initial Introduction Written