in reply to mod_perl & TT2 Architecture

perrin metions using Apache::Dispatch, which is a good idea. However it is fairly easy to achieve in the code. The main advantage is that all the magic happens in the code and not in the httpd.conf file. This is good as it makes installation easier and you can kick in a whole load of error catching mechanisms. 
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]
If any one has any comments on this I'd love to hear them.

--tidiness is the memory loss of environmental mnemonics

Replies are listed 'Best First'.
Re: Re: mod_perl & TT2 Architecture
by perrin (Chancellor) on May 25, 2004 at 16:51 UTC
    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]
[reply]
[d/l]
[select]
      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.

[reply]
        I respect your opinion, but I disagree with you on nearly all of this.

        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.

        You can't get much shorter than adding Include myproject.conf to your httpd.conf file.

        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

        Anyone who is allowed to write a module that will run under mod_perl should be allowed to change the conf file. The amount of damage that can be done is equivalent, so responsibility should be the same.

        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.

        I normally structure my apps to run some common setup stuff before handling any request. This has nothing to do with the conf file -- you just make your apps use a common base, like CGI::Application or Maypole. Auth stuff, on the other hand, belongs in the conf file. Apache has a built in phase for dealing with it that allows you to easilly change the auth system and permissions for specific apps. This is much harder to modify if you shove it all into your main application code instead.

        Also the layout does not need to come from a hash, it could come from an XML file.

        How would that be better than httpd.conf? It's not quite XML, but it's close. It's actually less verbose than XML would be.

        Finally it allows the _possibility_ of running the same code as a plain CGI

        It actually makes this no easier or harder than it would be if you did the mapping in the conf file. You can map to CGI scripts just as easilly as you can to handlers.

        Finally, there is value in doing things the standard way. No one on earth knows how to set things up using the private configuration method you just invented. Tons of people know how to set up an Apache conf file. That is valuable in itself.

[reply]
[d/l]

In Section Seekers of Perl Wisdom