view release on metacpan or  search on metacpan

site/articles/perlmonth1_intro.html  view on Meta::CPAN

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 ;) ... 
<p>
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.
<p>
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 <b>modular</b> include files.  Thus is becomes
easy to decompose a basic site template like:
<pre>
&lt;html&gt;
&lt;head&gt;&lt;title&gt;Company Name&gt;&lt;/title&gt;&lt;/head&gt;
&lt;body&gt;
&lt;!-- main body of page here --&gt;
Copyright / Disclaimer
&lt;/body&gt;&lt;/html&gt;

</pre>

and separate a common header and footer that can be reused 
across every script:

<pre>
[header.inc]
&lt;html&gt;
&lt;head&gt;&lt;title&gt;Company Name&gt;&lt;/title&gt;&lt;/head&gt;
&lt;body&gt;

[footer.inc]
Copyright / Disclaimer
&lt;/body&gt;&lt;/html&gt;

[sample.asp]
&lt;!--#include file=header.inc--&gt;
&lt;!-- main body of page here --&gt;
&lt;!--#include file=footer.inc--&gt;

</pre>
<h3>Powerful</h3>

When developing a web site under ASP, one has access to a complete 
set of objects and events, my favorite being $Session, which was one of ASP's
key selling points for me.  $Session is ASP's answer to the problem of HTTP being a 
stateless protocol.  By using temporary session cookies, each web user 
has a unique $Session in which you may store data, and that follows them from
script to script. Because the data storage
for $Session is handled on the server, you do not have to worry about
size limits of cookies as an alternate mechanism of storing user session data.
<p>
There are some very useful events as well.  Let's say that you are
using <tt>$Session->{login}</tt> 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
<tt>$Session->{login}</tt> 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.
<p>
Here is a basic listing of the built-in <a href=http://www.apache-asp.org/objects.html>objects</a> 
available to the developer within every <a href=http://www.apache-asp.org>Apache::ASP</a>
script:
<pre>
	Object		-	Function
	------			--------
	$Session	-	session state
	$Response	-	output
	$Request	-	input
	$Application	-	application state
	$Server		-	OLE support + misc.
</pre>

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.
<p>
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 
<a href=http://www.apache-asp.org/events.html>events</a>
are as follows:
<pre>
	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
</pre>
<p>
<h3>Fast</h3>
Execution speed is always important when picking your web application
environment ... shoot for the stars and design with the fastest
from the beginning, saving yourself a massive redesign later when 
your site becomes a success.  One of the motivations for not using PerlScript 
under IIS, a couple years ago, was that it was painfully slow, but has since been 
much improved.  

The <a href=http://perl.apache.org>mod_perl</a> project boasts a 20 times
speedup in CGIs handled by Apache::Registry, and it 
handles perl ASP scripts just as well under Apache::ASP, with
some performance lost because of all the objects initialization and 
events execution that ASP handles.  
<p>