By the way, there is no need to invent something that maps URLs to Perl modules. Apache already handles every conceivable mapping through httpd.conf, and if you run mod_perl you can use things like Apache::Dispatch to simplify it even more.

Not offbase at all. My standard recommendations are:

• Going lightweight? Try Maypole (Simon's written a couple of articles on perl.com as well.)
• Want something more heavyweight? (Authentication, security, distributed apps) Try OpenInteract (I'm biased about this one, naturally...)

package Handler;
use strict;
use warnings;

my %handlers = ( '/'        => 'Handler::Index',
                 '/logout'  => 'Handler::Logout',
                 '/details' => 'Handler::Details',
               );

sub handler ($$) {
  my $self = shift;
  my $r    = shift;
  $self = $self->new( r => $r ) unless ref $self;

  my $uri  = $r->uri;

  # User auth etc. can happen here.
 
  if ( my $handler = $handlers{ $uri } ) {
    eval "require $handler" || die "Error with $handler";
    return $handler->handler( $r );
  }
 
  # If not on list then it was not found.
  return NOT_FOUND;
}

#########
# httpd.conf

<Location />
  SetHandler  perl-script
  PerlHandler Handler
</Location>
[download]

What have you accomplished by doing this? You've moved the configuration from a configuration file into your code. What you're doing here could be replaced by this snippet of conf file:

<Location />
  SetHandler  perl-script
  PerlHandler Handler::Index
</Location>
<Location /logout>
  SetHandler  perl-script
  PerlHandler Handler::Logout
</Location>
<Location /details>
  SetHandler  perl-script
  PerlHandler Handler::Details
</Location>
[download]

Or, with mod_macro installed:

<Macro MapURL $url $handler>
<Location $url>
  SetHandler  perl-script
  PerlHandler $handler
</Location>
</Macro>
Use MapURL /        Handler::Index
Use MapURL /logout  Handler::Logout
Use MapURL /details Handler::Details
[download]

Well - it looks prettier for a start...

One advantage is that if the modules are distributed to others then the amount that they need to type into the httpd.conf file is reduced. It also means that the module authors get control of the url layout and so can change it without ever changing the httpd.conf file - ie easy upgrades. For something like a drop in blog or mail solution this would be vital.

Another reason is that you can then ensure that the user has jumped through some hoops before letting them get as far as the next modules. This could be authenticating them or setting up variables based on their preferences.

Also the layout does not need to come from a hash, it could come from an XML file. This opens up the possibility of allowing plugins to be added to a site automatically - the plugin would register itself in the XML and the handler would then know that it could dispatch to it. There is more needed to make this work (ie modding templates etc) but it allows for it.

Finally it allows the _possibility_ of running the same code as a plain CGI (although the $r would have to be faked up). This would not be trivial but there would be one less obstacle.

Thanks to everybody for their responses. I'll definately check out OpenInteract and CGI::Application. The article also looks really good; I don't know how I missed it on the mod_perl site.

The accounting side of the application works fairly well via a set of stored procedures under SQL Server 2000, so I wanted to use that as a base as we built further functionality. Unfortunately, Class::DBI doesn't play well with the current release of FreeDTS and SQL Server; evidently bind variables aren't supported. This kind of takes Maypole out of the running unless I can reimpliment the T-SQL logic fairly quickly with perl modules.

Great advice, and thanks again!

If you keep on having trouble on this kind of problem, then perhaps it would be valuable to do some post mortems, think about why past projects went wrong rather than trying to come up with idealized plans for how to do better.

It doesn't matter how good the design that you come up with is if you can't get people to buy into it. Or if people say that they buy into it and then erode the design. Or if you erode the design and only afterwards realize that you have done so.

At Re (tilly) 6: Code Critique I pointed out some of the factors which come into play and cause our well-laid plans to fall apart. You might read that, think about the past, and see if you can identify how to head off potential problems before they become real ones.