Apache-ASP
view release on metacpan or search on metacpan
<!-- end sample here -->
Notice that your perl code blocks can span any html. The for loop
above iterates over the html without any special syntax.
=head2 XMLSubs
XMLSubs allows a developer to define custom handlers for
HTML & XML tags, which can extend the natural syntax
of the ASP environment. Configured like:
PerlSetVar XMLSubsMatch site:\w+
A simple tag like:
<site:header title="Page Title" />
can be constructed that could translate into:
sub site::header {
my $args = shift;
print "<html><head><title>$args->{title}</title></head>\n";
print "<body bgcolor=white>\n";
}
Better yet, one can use this functionality to trap
and post process embedded HTML & XML like:
<site:page title="Page Title">
... some HTML here ...
</site:page>
and then:
sub site::page {
my($args, $html) = @_;
&site::header($args);
$main::Response->Write($html);
$main::Response->Write("</body></html>");
}
Though this could be used to fully render XML
documents, it was not built for this purpose, but
to add powerful tag extensions to HTML development
environments. For full XML rendering, you ought
to try an XSLT approach, also supported by Apache::ASP.
=head2 Editors
As Apache::ASP supports a mixing of perl and HTML,
any editor which supports development of one or the
other would work well. The following editors are
known to work well for developing Apache::ASP web sites:
* Emacs, in perl or HTML modes. For a mmm-mode config
that mixes HTML & perl modes in a single buffer, check
out the editors/mmm-asp-perl.el file in distribution.
* Vim, special syntax support with editors/aasp.vim file in distribution.
* UltraEdit32 ( http://www.ultraedit.com/ ) has syntax highlighting,
good macros and a configurable wordlist (so one can have syntax
highlighting both for Perl and HTML).
Please feel free to suggest your favorite development
environment for this list.
=head1 EVENTS
=head2 Overview
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 $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.
=head2 Script_OnStart & Script_OnEnd
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.
There is one caveat. Code in Script_OnEnd is not guaranteed
( run in 1.268 second using v1.01-cache-2.11-cpan-97f6503c9c8 )