I was first drawn to Active Server Pages (ASP) as a web development platform a couple years ago when researching how to best develop the NODEWORKS web site. I needed something maintainable, powerful, fast, portable, and of course perl.
Microsoft had developed the ASP standard as the end all to web application development, which promised to be maintainable, powerful, and fast. But support for perl under PerlScript was shoddy, VBScript, ASP's native tongue, seemed a pathetic alternative, and an NT/IIS solution lacks a certain portability. Thus I was led to developing Apache::ASP, which runs under Doug MacEachern's mod_perl for Apache.
Check out the difference in how it feels to embed the HTML in the scripting, versus embedding the scripting in the HTML. A reasonably complex table, which is structurally HTML heavy, only touches the tip of the iceberg:
|
|
|
Coding this table in CGI, you might get:
When designing the above table ASP style, a much more natural flow to the script takes form, wherein the developer can literally see the table in table layout of the page:
use CGI qw/:standard *table/; my(@data) = ('Some', 'Data', 'To', 'Loop', 'Over', ':)'); print header, start_html('Example'), start_table({-border=>2, -bgcolor=>'blue'}), Tr,td, start_table({-border=>4, -bgcolor=>'white'}) ; # pretend we are reading from database cursor, so code # would be written like so my($data, $count); while(@data) { if($data and $count++ % 2) { print end_table,td,start_table({-border=>4, -bgcolor=>'white'}); } $data = shift @data; print Tr({align=>CENTER}, [td([uc($data)."\n"])] ) ; } print end_table, end_table, end_html ;
<% my(@data) = ('Some', 'Data', 'To', 'Loop', 'Over', ':)'); %> <html> <head><title>Example</title></head> <body> <table border=2 bgcolor=blue> <tr><td> <table border=4 bgcolor=white> <% my($data, $count); while(@data) { if($data and $count++ % 2) { %> </table><td><table border=4 bgcolor=white> <% } $data = shift @data; %> <tr><td><%=uc $data%></td></tr> <% } %> </table> </td></tr> </table> </body> </html>
Doesn't the HTML-centric ASP read better? You'll see that this becomes more true as the html of your site becomes increasingly complex.
There are other aspects to maintainability, like who will be taking over your code in 2 years. With perl CGI, you can assume that any perl developer that you work with is going to be able to get through the mess you've made. But so too with ASP, because of the marketing muscle that Microsoft put behind its brainchild, you can expect to get plenty of ASP experience in the workforce, with a huge peer learning environment.
So far, this may sound religious to some, as project design and maintainability take on some very fuzzy and personal characteristics, with many varying perspectives, but it should be at the forefront of one's mind when beginning any software project. This leads me to the graphics designer you may end up working with, who doesn't know that the dynamic web site you are building really falls under software development ;) ...
Because ASP is scripting embedded in HTML, you can give the graphics designer a few easy function calls to embed, and s/he can take the rest from there, using her/his favorite GUI tools to craft the web site beautifully. Notice that you significantly increased the number of people that can work on your site by using an embedded scripting web application environment like ASP, versus going with a pure scripted CGI solution.
Another feature furthering maintainability is ASP's built-in support for Server Side Includes (SSI), which allows the developer to segment common parts of the site into modular include files. Thus is becomes easy to decompose a basic site template like:
<html> <head><title>Company Name></title></head> <body> <!-- main body of page here --> Copyright / Disclaimer </body></html>and separate a common header and footer that can be reused across every script:
[header.inc] <html> <head><title>Company Name></title></head> <body> [footer.inc] Copyright / Disclaimer </body></html> [sample.asp] <!--#include file=header.inc--> <!-- main body of page here --> <!--#include file=footer.inc-->
There are some very useful events as well. Let's say that you are using $Session->{login} to control a user account login and logout. Because $Session automatically times out every SessionTimeout, if a user walks away from her/his computer for SessionTimeout minutes, the $Session->{login} is destroyed along with the rest of the data stored in $Session, and the next person that uses the computer will find themselves automatically logged out from the account. This is a huge security win if you maintain a set of accounts at your web site that hold sensitive information like credit card numbers.
Here is a basic listing of the built-in objects available to the developer within every Apache::ASP script:
Object - Function ------ -------- $Session - session state $Response - output $Request - input $Application - application state $Server - OLE support + misc.You might be looking at the $Application object as saying "huh, what's that?". Simply, $Application allows you to share data between various ASP scripts and users. Metaphorically it represents your web site as an application, and $Application is initialized when the first user $Session is created, and destroyed when the last user $Session is destroyed.
Events are triggered when these objects are created and destroyed. In addition to data initialization and destruction, these events allow the developer to define, in the global.asa, subroutines to be executed at these event times, providing hooks enabling the web site to function easily as a dynamic software application. The events are as follows:
Action Event
------ ------
Script_OnStart * Beginning of Script execution
Script_OnEnd * End of Script execution
Application_OnStart Beginning of Application
Application_OnEnd End of Application
Session_OnStart Beginning of user Session.
Session_OnEnd End of user Session.
* These are API extensions that are not portable, but were
added because they are incredibly useful
The startup overhead on simple scripts is significantly more when moving from CGI to ASP under mod_perl for Apache, at least 20%, as shown in my previous Hello World - Web Application Benchmarks article, but this startup overhead will become relatively less important as your scripts get longer, and a base rate of 75 Apache::ASP requests per second on a PII 300 Solaris x86 is nothing to scoff at!
In order to justify using ASP over CGI despite the performance hit, just remember how much more maintainable and powerful ASP is. The general consensus is that developer time is much more valuable than computer time so save the former where possible!