Mod_perl Application Development

[Jonathan Lonsdale <jo...@iname.com>]

I'm curious to know how people approach application development with
mod_perl in situations where there could be dozens of distinct
screens/interfaces. I'm currently using the HTML::Template system.

Here's a few approaches I thought of:

1. Single monolithic content handler. Could be hard to maintain.
2. Distinct content handlers each with their own Location directive. Could
be a pain to maintain the server config.
3. Take a small performance hit and use an Apache::Registry script for each
screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache::
modules and don't bother being backwardly compatible with CGI.

Thanks,
Jonathan

Re: Mod_perl Application Development

[Chris Winters <ch...@cwinters.com>]

On Sat, 2002-08-17 at 19:31, Jonathan Lonsdale wrote:
> I'm curious to know how people approach application development with
> mod_perl in situations where there could be dozens of distinct
> screens/interfaces. I'm currently using the HTML::Template system.
> 
> Here's a few approaches I thought of:
> 
> 1. Single monolithic content handler. Could be hard to maintain.
> 2. Distinct content handlers each with their own Location directive. Could
> be a pain to maintain the server config.
> 3. Take a small performance hit and use an Apache::Registry script for each
> screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache::
> modules and don't bother being backwardly compatible with CGI.

There's a separate one that's used in OpenInteract: create a single
content handler that uses some sort of lookup table to map requests to
handlers. This lookup table can be maintained separately from the apache
configuration and can generally be more flexible, allowing for
application-level security settings, etc.

Chris

-- 
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.

Re: Mod_perl Application Development

[Perrin Harkins <pe...@elem.com>]

Jonathan Lonsdale wrote:
> 2. Distinct content handlers each with their own Location directive. Could
> be a pain to maintain the server config.

You would typically have a single handler that covers one "application" 
with many screens, so instead of having an entry there for every 
template you would have a just a small number of entries for 
applications like a shopping cart or a message board.  The applications 
then manage which template to send out on each request using their own 
internal logic.  Things like CGI::Application and Apache::PageKit are a 
formalization of this approach.

People often seem to get bent out of shape about putting a few Location 
directives in httpd.conf, but I find it simple to manage and like doing 
this the standard way.  Having Location directives lets you use all of 
the normal Apache config options for access control, customized logging, 
etc. without inventing your own config system.  There are exceptional 
situations (a requirement to add new handlers without a restart, for 
example), but most people will be just fine doing it the old-fashioned way.

- Perrin

Re: Mod_perl Application Development

[Tom Hukins <to...@eborcom.com>]

On Sun, Aug 18, 2002 at 12:31:03AM +0100, Jonathan Lonsdale wrote:
> I'm curious to know how people approach application development with
> mod_perl in situations where there could be dozens of distinct
> screens/interfaces. I'm currently using the HTML::Template system.

When using HTML::Template, I've found its query() method useful to
tell the controller what code to call to pass data back to the
template:
http://perlmonks.org/index.pl?node_id=150608

Tom

Re: Mod_perl Application Development

["Ken Y. Clark" <kc...@logsoft.com>]

On Sun, 18 Aug 2002, Jonathan Lonsdale wrote:

> Date: Sun, 18 Aug 2002 00:31:03 +0100
> From: Jonathan Lonsdale <jo...@iname.com>
> To: modperl@perl.apache.org
> Subject: Mod_perl Application Development
>
> I'm curious to know how people approach application development with
> mod_perl in situations where there could be dozens of distinct
> screens/interfaces. I'm currently using the HTML::Template system.
>
> Here's a few approaches I thought of:
>
> 1. Single monolithic content handler. Could be hard to maintain.
> 2. Distinct content handlers each with their own Location directive. Could
> be a pain to maintain the server config.

I've usually done #2, and it is a pain.  When you're developing and
making up just one <Location> at a time, it's not so bad, but when you
go to distribute the application and you see that someone will have to
set up 10 or so or them, then it looks a little hacky.

I've considered going to #1 and using CGI arguments (e.g.,
"page=foo") or path_info (e.g., "/my_handler/foo") to dispatch to the
correct module.  I certainly wouldn't advise that the logic for all
these <Location>s be in one module.

> 3. Take a small performance hit and use an Apache::Registry script for each
> screen to handle the content phase. Use 'PerlSetupEnv Off', $r and Apache::
> modules and don't bother being backwardly compatible with CGI.

There's nothing wrong with this or just about any other way you can
think as long as it works properly for you.  I'm currently looking at
the new Apache::TT2 module (http://apache-tt2.sourceforge.net/) as a
way of getting rid of all <Location> directives.  The templates are
called in the same manner as HTML pages (i.e., by specifying a URL)
and Apache::TT2 processes the pages as it normally would, allowing you
to call out to objects and libraries and such.

The exhaustive list of how other people are doing this would be
difficult to compile and voluminous.  I'd recommend you also look into
all the other very fine application frameworks, like HTML::Mason,
CGI::Application, Apache::PageKit and others.

ky

RE : Mod_perl Application Development

[Frédéric SCHWIEN <fr...@igtech.fr>]

Check CGI::Application from CPAN,

Very useful. It uses differents "Run Mode" for Application. Originally,
it uses HTML::Template, but can be easily subclassed to use another
Template System. We use it with Text::Template.

Fred



-----Message d'origine-----
De : Jonathan Lonsdale [mailto:jon3001@iname.com] 
Envoyé : dimanche 18 août 2002 01:31
À : modperl@perl.apache.org
Objet : Mod_perl Application Development


I'm curious to know how people approach application development with
mod_perl in situations where there could be dozens of distinct
screens/interfaces. I'm currently using the HTML::Template system.

Here's a few approaches I thought of:

1. Single monolithic content handler. Could be hard to maintain. 2.
Distinct content handlers each with their own Location directive. Could
be a pain to maintain the server config. 3. Take a small performance hit
and use an Apache::Registry script for each screen to handle the content
phase. Use 'PerlSetupEnv Off', $r and Apache:: modules and don't bother
being backwardly compatible with CGI.

Thanks,
Jonathan

Re: Mod_perl Application Development

[Ask Bjoern Hansen <as...@develooper.com>]

On Sun, 18 Aug 2002, Jonathan Lonsdale wrote:

> Here's a few approaches I thought of:

In a previous life[1] I made a system that was configured like

<perl>
  my $site1 = new Foo::Site(site => 'www.example.com');
  $site1->register_handler(
    new Foo::ImageHandler(path => '/images/', format => 'png');
  );
  $site1->register_handler(
    new Foo::SomeOtherHandler(...);
  );
  ...
</perl>

<VirtualHost>
   ...
   PerlHandler $site1->take_request
</VirtualHost>

(it wasn't quite like that; the site configurations were all in Perl
modules dynamically utilizing perl_sections to configure Apache).

When running register_handler, the Foo::Site object would call some
method on the Handler object to figure out which namespace or which
requests it wanted to handle.  During take_request it would then
just dispatch the right handler.

This made it really easy to activate a subsystems when the customer
needed them.  The system also made it easy to customize the handlers
for each customer. (Just inherit the base Foo::BarHandler into
Customer::BarHandler and add the extra magic).

  - ask

[1] okay, not quite a previous life; but it is more than 4 years
ago. :-)

-- 
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();