|Do you know where your variables are?|
Apache::ASPby trs80 (Priest)
|on Feb 20, 2002 at 01:29 UTC||Need Help??|
Item Description: For developing dynamic web applications
Rating**** 4 out of 5 stars
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:
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
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.
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.
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. 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 PitfallsCODE 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.