Apache::ASP is a module that allows for embedding Perl into your HTML
files and runs in concert with mod_perl. It has been run in test
environments as CGI, but it is recommended that in production it be run
under mod_perl.
Things I Don't Like
Not highly configurable
There are lots of things that you can't easily turn on or off that
might be nice at a page level, it may be possible, but it is not
well/clearly documented if you can.
Interface causes keyboard gymnastics
The keyboard gymnastics occur by attempting to mimic its namesake
Microsoft ASP. To get a parameter passed with the GET method you would
use something like:
$Request->QueryString('param_name');
To me that seems like a lot of typing, but when you keep in mind it is
to mimic the ASP/PerlScript methods then it makes sense in that
context. So it really isn't the authors desire to make your fingers ache
:)
Separate Methods for QueryString and Form parameters (default)
Having to remember which method was used to send the variables to the
page is annoying. This has been corrected in later releases with a
$Params object. You have to set an configuration parameter in the
httpd.conf file get this behavior.
Custom Session Management
Apache::ASP uses its own Session management that only works with
Apache::ASP. It would be nice to have the option of using
Apache::Session since it has proven to be very durable. No Variable
Clean Up (default)
Not having auto variable cleanup at the end of each page compile leads
to possible global/persistent values that can really gum up the works
if you have old code that you would rather not have to bring up to
"strict" standards to use. I am not saying that is a good idea, but we
all have time constraints that push us to do ugly things from time to
time.
Things I Do Like
Script_OnStart t/Script_OnEnd
The Script_OnStart and Script_OnEnd subs in the global.asa (default
application code) allows for particular actions to be taken on each
page (script) load so you can verify session validity or update session
information, add headers and footers, load default mouldes, create
database connections, etc. inside of these subs.
Configuration Simplicity
The configuration doesn't implement a bitmask like HTML::Embperl which
can be a bit confusing to developers that aren't from a computer
science background. Typically you simply set the parameter with one
option in the httpd.conf and forget about it.
Unique Session Options
The cookieless sessions allow for a method in which session information
is automaticly added to URLs so your application doesn't break when the
user turns off cookies. There are some caveats on this and they are
explained in the documenation. Paranoid sessions are best explained
with this snipet from the documentation.
"This config option is to help prevent a brute force cookie search from
being successful. The number of possible cookies is huge, 2^128, thus
making such a hacking attempt VERY unlikely. However, on the off chance
that such an attack is successful, the hacker must also present
identical browser headers to authenticate the session, or the session
will be destroyed. Thus the User-Agent acts as a backup to the real
session id. The IP address of the browser cannot be used, since because
of proxies, IP addresses may change between requests during a session."
Easy to Read Debug Information
The debug information that is presented to the developer is for the
most part very clear and you can configure various levels including
mailto debug display options.
Good Documentation
The documentation is well written and is available at the Apache::ASP
web site. It has a good example code section that provides simple
examples that should get you started in short order.
Great Support via Mailing List
The support provided on the mailing list is great. My last development
project with Apache::ASP had me posting to the mailing list or emailing
the author directly and he was very responsive. Since the official
mailing list has started the response level is just as good. Previously
support was handled via the mod_perl list. It is not completely
inappropriate to cross post your question since not all Apache::ASP
users may subscribe to both lists and it is possible that your issue is
not where you think it is.
Separate Application Object and Session Object
The Application object allows for you to setup application level
attributes at server start or first user access. It is as flexible as
the session data in that you can create your own key value pairs for
your particular needs.
Pure Perl
Pure Perl. I don't know why(1), but I like to see packages that use
only Perl and no XS extensions, even though XS extensions can provide
speed improvements depending on the process, it is still nice to know
that if you know Perl and not C you stand a fighting chance at hacking
the source if you need to.
Good Advice on Tuning
There is a section called tuning in the documentation that has good
advice on which configuration options will have the most speed impact
on the server.
Caveats or Pitfalls
CODE CLEAN OR DIE in Apache::ASP. I can't say that enough. When I
started on the previously mentioned web project using Apache::ASP,
development had already begun and the code was not strict compliant and
with close to 300 pages in the application and a timeline that didn't
allow for a complete rewrite the fact that the variables weren't
cleaned up at the completion of every page really wrecked havoc. So if
you want to use Apache::ASP turn on the Strict option in the
configuration and code cleanly.
Use the $Params settings so you don't have to keep track of how the
parameters are coming it. This is a feature that I helped bring into
the module with my constant prodding of the author. I had come from
HTML::Embperl development and we had several scripts that were used
with both form and QueryString based parameters depending on the page
it was being accessed from. This lead to even more finger gymnastics
because we would have to create new variables with an || conditional
for each method.
Read all the documentation. That may sound silly, but I think it
something that a lot of us don't do always. I find the
templating/framework systems such as Apache::ASP, HTML::Mason,
HTML::Embperl all be very well documented and many a question is
answered in the documentation.
So who should use Apache::ASP? Some one that is coming from an ASP
background will like the syntax for the most part, might take a bit
getting used to the $'s and ->'s if they were doing VB ASP, but at
least the objects are named the same. If you are running a small to
medium size site I think Apache::ASP is a good choice, I would not
recommend it for larger scale development, I can't back that up with
any firm data, but having done large scale sites in HTML::Embperl and
Apache::ASP, I found HTML::Embperl much easier to work with.
And don't forget to read
the mod_perl Guide.
1 - Maybe it is empathy for people that know only the Microsoft way.