NAME
Plasp::GlobalASA - global.asa
SYNOPSIS
### in global.asa
sub Script_OnStart {
printf STDERR "Executing script: %s\n", $Request->ServerVariables('SCRIPT_NAME');
}
DESCRIPTION
The ASP platform allows developers to create Web Applications. In fulfillment of real software requirements, ASP allows event-triggered actions to be taken, which are defined in a global.asa file. The global.asa file resides in the Global
directory, defined as a config option, and may define the following actions:
Action Event
------ ------
Script_OnStart * - Beginning of Script execution
Script_OnEnd * - End of Script execution
Script_OnFlush * - Before $Response being flushed to client.
Script_OnParse * - Before script compilation
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
These actions must be defined in the "$self->Global/global.asa"
file as subroutines, for example:
sub Session_OnStart {
$Application->{$Session->SessionID()} = started;
}
Sessions are easy to understand. When visiting a page in a web application, each user has one unique $Session
. This session expires, after which the user will have a new $Session
upon revisiting.
A web application starts when the user visits a page in that application, and has a new $Session
created. Right before the first $Session
is created, the $Application
is created. When the last user $Session
expires, that $Application
expires also. For some web applications that are always busy, the Application_OnEnd
event may never occur.
METHODS
- $self->execute_event($event);
-
Execute the event defined in global.asa
- Application_OnStart
-
This event marks the beginning of an ASP application, and is run just before the
Session_OnStart
of the first Session of an application. This event is useful to load up$Application
with data that will be used in all user sessions. - Application_OnEnd
-
The end of the application is marked by this event, which is run after the last user session has timed out for a given ASP application.
- Session_OnStart
-
Triggered by the beginning of a user's session,
Session_OnStart
gets run before the user's executing script, and if the same session recently timed out, after the session's triggeredSession_OnEnd
.The
Session_OnStart
is particularly useful for caching database data, and avoids having the caching handled by clumsy code inserted into each script being executed. - Session_OnEnd
-
Triggered by a user session ending,
Session_OnEnd
can be useful for cleaning up and analyzing user data accumulated during a session.Sessions end when the session timeout expires, and the
StateManager
performs session cleanup. The timing of theSession_OnEnd
does not occur immediately after the session times out, but when the first script runs after the session expires, and theStateManager
allows for that session to be cleaned up.So on a busy site with default
SessionTimeout
(20 minutes) andStateManager
(10 times) settings, theSession_OnEnd
for a particular session should be run near 22 minutes past the last activity that Session saw. A site infrequently visited will only have theSession_OnEnd
run when a subsequent visit occurs, and theoretically the last session of an application ever run will never have itsSession_OnEnd
run.Thus I would not put anything mission-critical in the
Session_OnEnd
, just stuff that would be nice to run whenever it gets run. - Script_OnStart
-
The script events are used to run any code for all scripts in an application defined by a global.asa. Often, you would like to run the same code for every script, which you would otherwise have to add by hand, or add with a file include, but with these events, just add your code to the global.asa, and it will be run. This runs before a script is executed.
- Script_OnEnd
-
Like
Script_OnStart
except at the end.There is one caveat. Code in
Script_OnEnd
is not guaranteed to be run when$Response->End()
is called, since the program execution ends immediately at this event. To always run critical code, use the API extension:$Server->RegisterCleanup()
- Script_OnParse
-
This event allows one to set up a source filter on the script text, allowing one to change the script on the fly before the compilation stage occurs. The script text is available in the
$Server->{ScriptRef}
scalar reference, and can be accessed like so:sub Script_OnParse { my $code = $Server->{ScriptRef} $$code .= " ADDED SOMETHING "; }
- Script_OnFlush
-
API extension. This event will be called prior to flushing the
$Response
buffer to the web client. At this time, the$Response->{BinaryRef}
buffer reference may be used to modify the buffered output at runtime to apply global changes to scripts output without having to modify all the scripts.sub Script_OnFlush { my $ref = $Response->{BinaryRef}; $$ref =~ s/\s+/ /sg; # to strip extra white space }