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
