This is PerlMonks "Mobile"

Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Item Description: For developing dynamic web applications

Review Synopsis:

Author

Joshua Chamas

Version

2.31

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:

$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.

Replies are listed 'Best First'.
Re: Apache::ASP
by knobunc (Pilgrim) on Feb 20, 2002 at 21:31 UTC

    Nice review.

    For similar functionality with what I consider a cleaner interface and neater structure see HTML::Mason module review at www.masonhq.com. (I realize the author mentions it, but I wanted to make the plug more prominent and provide links).

    It can intersperse code and HTML (or whatever language, it is not tied to HTML, it could spit out text, XML, ASP, gifs, jpegs, you name it...). And it has an interesting component structre where each file is considered to be a component (whether or not it can be called externally) and components can call each other so you can make widgets that take arguments in mason as well as the top-level components that get called directly. Also it has a neat object-like hierarchy where you can define a method call to generate the page framework (a top, bottom and side for instance) and then all the other pages need to do is output the appropriate content for the content area. The sub-pages can override the methods of the lower-level pages to customize the way things display.

    -ben

[reply]
      I also found myself migrating from Apache::ASP to Mason. I must say, I'm much happier with Mason, personally. Here's a quick hack that can migrate the template format of a set of files from Apache::ASP to Mason. You still have to change any use of the Apache::ASP objects over, of course. 
      #!/usr/bin/perl

#foreach $file ( split(/\n/, `find . -depth -print`) ) {
#  next unless $file =~ /(cgi|html)$/;
foreach $file ( @ARGV ) {
  open(F,$file) or die "can't open $file for reading: $!";
  @file = <F>;
  #print "$file ". scalar(@file). "\n";
  close $file;
  $newline = ''; #avoid prepending extraneous newlines
  $all = join('',@file);

  $w = '';

  $mode = 'html';
  while ( length($all) ) {

    if ( $mode eq 'html' ) {

      if ( $all =~ /^(.+?)(<%=?.*)$/s && $1 !~ /<%/s ) {
        $w .= $1;
        $all = $2;
        next;
      } elsif ( $all =~ /^<%=(.*)$/s ) {
        $w .= '<%';
        $all = $1;
        $mode = 'perlv';
        #die;
        next;
      } elsif ( $all =~ /^<%(.*)$/s ) {
        $w .= $newline; $newline = "\n";
        $all = $1;
        $mode = 'perlc';

        #avoid newline prepend fix from borking indented first <%
        $w =~ s/\n\s+\z/\n/;
        $w .= "\n" if $w =~ /.+\z/;

        next;
      } elsif ( $all !~ /<%/s ) {
        $w .= $all;
        last;
      } else {
        warn length($all); die;
      }
      die;

    } elsif ( $mode eq 'perlv' ) {

      if ( $all =~ /^(.*?%>)(.*)$/s ) {
        $w .= $1;
        $all=$2;
        $mode = 'html';
        next;
      }
      die "unterminated <%= ??? (in  $file):";

    } elsif ( $mode eq 'perlc' ) {

      if ( $all =~ /^([^\n]*?)%>(.*)$/s ) {
        $w .= "%$1\n";
        $all=$2;
        $mode='html';
        next;
      }
      if ( $all =~ /^([^\n]*)\n(.*)$/s ) {
        $w .= "%$1\n";
        $all=$2;
        next;
      }

    } else { die };

  }

  system("chmod u+w $file");
  select W; $| = 1; select STDOUT;
  open(W,">$file") or die "can't open $file for writing: $!";
  print W $w;
  close W;
}

      [download]
[reply]
[d/l]
Re: Apache::ASP
by Anonymous Monk on Feb 20, 2002 at 04:04 UTC
    great review, really objective, bravo
[reply]
Re: Apache::ASP
by chicks (Scribe) on Jul 09, 2009 at 03:20 UTC
    I really like that Apache::ASP lets you create your own XML tags. I've found that a great way to generalize functionality across an application. Apache::ASP is one of the most agile development environments I've found. I hope to migrate to Catalyst, but I don't do much web development these days.
[reply]