Fog Creek Software
Discussion Board

ASP and code soup

> I finally think I know where the best place to put
> database access code is, the best way to use ADO
> to get recordsets, the best way to separate HTML
> and code, etc.

I think this is a very interesting topic. I have recently completed a medium-sized ASP project and I am not satisfied with it. The very idea of ASP seems to drive you towards writing a code and tag soup, where all your pages start with retrieving some data from the database and end up with a big loop through the recordset and a series of Response.Write calls. I don't like this. Therefore my question: what are the recommended ways to separate code from presentation in ASP, apart from XML/XSLT? There's nothing wrong with XSLT, I just want to know if it is possible, say, to have a separate HTML-designer to make the looks of ASP-pages and a programmer who would write the code - so that these to things aren't stored in one .asp file as a horrible mess.

Michael Skulsky
Thursday, December 19, 2002

Have you looked into ASP.NET and code behind? Its much improved.

Thursday, December 19, 2002

I think its pretty easy, just use the <%=%> as if they were custom tags (like in aspx).  I usually put big blocks of HTML in subroutines, with <%=variable%> for the dynamic content (generated tables, etc).  This cleans it up some.

Vincent Marquez
Thursday, December 19, 2002

I've spent the past month checking out the different ways to write web-apps.

My conclusion so far : Since I don't like Java (too many components required to have a working server) and Perl (don't like the language, too permissive), I still hesitate between PHP + templates (eg. FastTemplate, Smarty, or frameworks like Midgard, etc.) or Zope. I've been looking at Zope on and off for months now, and I'm only now starting to get it.


Frederic Faure
Friday, December 20, 2002

I sprinkle my HTML liberally with class and id attributes this tends to keep designers happy.

John Ridout
Friday, December 20, 2002

I know what you mean. I like PHP for small projects, but it really needs a template extension for larger solutions, and I haven't found one I like yet.

ASP.NET has a lot to offer, but it has a nasty tendancy to produce non-XHTML complient code, which is not good. And the VS.NET environment keeps rewriting my HTML, for which it gets a slap on the wrist.

At the moment I'm happy using it for internal development, but I don't think it's quite ready for use on public websites. I'm hoping the next version will be an improvement.


James Shields
Friday, December 20, 2002

ASP code can get ugly pretty quick, but it also lets you crank out a finished product pretty quick.

One way to make your asp pages cleaner is to use objects to do all the dirty work.  You can define objects in asp pages using VBScript syntax then write code like:

Set objContact = new clsContact

Response.write objContact.getPhoneNumber &"<BR>"

Response.write objContact.DrawContactQuickInfoTable() 

This approach let's you hide^H^H^H^Horganize the code that handles database interaction and drawing.  You can let junior developers handle the front-end html pieces while more experienced developers work on the backend pieces.

Steve H
Friday, December 20, 2002

ASP in .NET (.ASPX) partly solves the problem - it allows you to separate code into components and reuse them fairly well. However, you can simulate this in the old ASP by using objects or functions/subs. For instance function like this:

Sub PrintMyRecordset (rs)
..... header
<% While Not (rs.EOF) %>
.... single line
<% rs.MoveNext
End %>
.... footer
<% End Sub %>

This approach has a reasonable performance and allows you to avoid a lot of code cloning. If you decide to use JScript on the server, you will be also capable of passing functions as parameters. For instance the above function could look like:

<% function PrintRecordset (rs, fnLine) %>
... header
while (!rs.EOF ())
  fnLine (rs)
  rs.MoveNext ();
%> ... footer <%

function fnLine1 (rs)
  %><tr><td><% = rs.Fields ("Name")  %></td></tr><%

function fnLine2 (rs)
  %><tr><td>address: <% = rs.Fields ("Address")  %></td></tr><%

PrintRecordset (rs, fnLine1)
PrintRecordset (rs, fnLine2)

Alexander Chalucov
Friday, December 20, 2002

Thank you guys for responding. It is really invaluable for me to hear your design condiderations.
As far as ASP.Net is concerned - this is a completely different language and it dictates different approaches. Actually when asking about ASP I also had PHP guys in mind - because the difference between PHP and ASP is mostly syntactical, not conceptual (which is not the case with ASPX). And as PHP is a big hit nowadays, the problem of code/presentation separation must be well-known and somehow solved.
As for using objects and functions - this doesn't really help a lot. Yes, it helps to factor the code in smaller reusable parts, but these smaller parts still contain both code and presentation. Taking Alexander's example:

function fnLine1 (rs)
  %><tr><td><% = rs.Fields ("Name")  %></td></tr><%

If I write things like that, I cannot ask a web-designer to create the looks of the web page for me. Or rather I can, but after he's done with it, I have to divide his page into zillion of smaller parts, wrap them in functions, insert <%= %> things - so he is not able to change anything anymore.
This is what I want to avoid.

Michael Skulsky
Saturday, December 21, 2002

Back when I did ASP i found it more intuitive to just write the entire pages in code. I.e response.write instead of the <%%> mayhem.
If you have a well made design all done before the coding starts, its the way to go imho.

And all formatting that can be moved to external stylesheets should be moved to an external stylesheet.

Include-files are good for reoccuring stuff like the regular lefthand menu column.

Eric DeBois
Saturday, December 21, 2002

Using the "default" approach with ASP (and still to a large extent with ASP.NET) can easily lead to pages with heavily intermixed HTML and script code, presentation and business logic, etc. Long ago, I created a template structure that attempted to separate some of these functional areas into separate files that can be somewhat independently maintained and modified. This served my purpose at the time, but since browsers at the time did not support CSS, it still intermixed HTML attributes with ASP script code to some extent.

I have recently started creating a similar template structure based on XHTML and CSS (and optionally XML/XSLT), moving all of the presentation markup (FONT, COLOR, etc tags) out of the ASP page into CSS and XSL files. A preliminary outline of this approach is shown below.

[Note: Writing out complete sections of HTML using Response.Write performs much better than a lot of context switching between HTML and script (using the <%= %> tags), provided that you're careful about the way that you construct long strings in script. However, this makes it more difficult to create and maintain the HTML (because you can't view the ASP code in "design view" to see how the page looks before you actually execute the page, all the quotes for HTML attributes need to be doubled, etc). I once wrote a small script that allowed you to create the HTML in an authoring tool and then produce the "Response.Write" version from that (adding string variable names and Response.Write statements, doubling quotes, etc) before adding the ASP variables and script - but this was a one-way process.]

The template shown below assumes a menu at the top of the page, but the template can be easily re-arranged for a left-side menu or other styles. Variations can be created if a site contains several different major categories of pages. A more complex template with multiple different sections in the page could also be created in this same conceptual style. Also, the template as shown is intended for recent browsers (IE 5 and 6, Netscape 6, Opera 7, etc) that substantially support W3C web standards. The content will still display in older browsers, but it will not be visually styled in the same way.

This approach allows the page style and appearance, menus, and content layout and style to each be developed and maintained separately (and optionally by different people). The "inner content" (the table of data, for example) is still the least separated, but once the basic style for this area is defined or created as a sample by a web designer in pure HTML, it should be relatively easy to change it (in code) in the future (especially if it uses CSS style classes - for example, <table class="TopicData"><tr class="RowOdd">...<tr class="RowEven">... instead of <table border="1"><tr bgcolor="white">...<tr bgcolor="yellow">...).

<%@ Language=VBScript %>
<% Option Explicit %>
<!--#INCLUDE FILE="setup-and-variables.asp" -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<html xmlns="">

<!--#INCLUDE FILE="Server-common-functions.asp" -->


<!--#INCLUDE FILE="meta-and-stylesheet-links.asp" -->
<script type="text/javascript" src="JavaScript-for-all-pages.htm"></script>

<!-- ##### Includes specific to this page ################ -->
<!--#INCLUDE FILE="Server-functions-for-THIS-page.asp" -->
<script type="text/javascript" src="JavaScript-for-THIS-page.htm"></script>
<!-- ##################################################### -->

<title>Page Title Goes Here (or call a function if the title is dynamic)</title>

<!--#INCLUDE FILE="UI-header-and-menus.asp" -->

<DIV id="PageContent">
<H3 class="PageMain">Section Header</H3>

' Call function(s) in ASP file (that contains only VBscript
' code and calls to COM components, no embedded HTML) to ' generate this section of content for the page.

' This could be, for example:
Response.Write TransformXML(XML-read-from-database, XSL-for-this-set-of-data)



<!--#INCLUDE FILE="UI-footer-copyright-etc.asp" -->

The included files contain items such as the following:
(Note - the file names shown are intended to represent the purpose of the file, not the actual file name, and may also represent more than one file.)

Response.Buffer, Response.Expires, cache control, any page-level variables, perhaps authentication checking, etc

Server-side (VBScript) functions that are common to all (or most) pages - such as data retrieval, XML transformation, etc.

Server-side (VBScript) functions specific to this page

HTML META tags and stylesheet link tags, including stylesheets for printing, and alternate stylesheets

Client-side JavaScript functions that are common to all pages

Client-side JavaScript functions specific to this page

DIV blocks containing common sections (logo, navigation menus, etc) at top of page

DIV block containing common section (copyright notice, etc) at bottom of page

Philip Dickerson
Tuesday, December 31, 2002

*  Recent Topics

*  Fog Creek Home