ANNOUNCE: MasonX::WebApp 0.01
This is the first release of this code, and it's probably buggy, but I
think it's pretty neat.
>From the docs ...
=head1 SYNOPSIS
# Create a subclass of MasonX::WebApp
package My::WebApp;
use base 'MasonX::WebApp';
sub _init
{
# do neat stuff
}
# In your Apache config file
SetHandler perl-script
PerlHandler My::WebApp
=head1 DESCRIPTION
C works with Mason to let you do processing I
Mason is ever invoked. There are a number of things that one might
want to do:
=over 4
=item * Argument munging
You might want to make sure all incoming arguments are UTF-8 encoded.
Or you might want to create some objects which Mason will see as
incoming arguments. For example, a "user_id" parameter could be
turned into a user object.
=item * Handle requests without Mason
If you're not generating output for the browser other than a redirect,
then there's no reason to use Mason. You can use a C
subclass to handle all form submissions, for example.
This has the added benefit of making it easier to preload this code
once during server startup.
=item * Authorization checks
Why do authorization checks in Mason if a failed check just leads to a
redirect or NOT FOUND return code?
=back
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ANNOUNCE: MasonX::WebApp 0.01
>From the docs:
> You must call clean_request_args() on the ApacheHandler object at the end of
> the request, unless you are making a new ApacheHandler object for every
> request. Otherwise bad things will happen.
>
> This is lame, so if someone thinks of a better way to do this, I'd be happy to
> hear about it.
In my massively more complicated (in both the good and bad senses of the
word), but spiritually similar Mason-using WebApp framework, I do something
like this:
---
PerlSetVar WebAppClass "WebApp::Foo::Bar"
SetHandler perl-script
PerlHandler Apache::WebApp
---
# Apache/WebApp.pm
our(%Apps, $Interp); # caches
sub handler($$)
{
my($self, $r) = @_;
$self = $self->new($r) unless(ref $self);
$self->sanity_check() or return $self->status;
my $app = $self->app;
$self->parse_query($r, $app) or return $self->status;
return $self->handle_request($r, $app);
}
...
# "app" is a "get, set, init" attribute (c.f. Class::MethodMaker)
sub init_app
{
my($self) = shift;
my $r = $self->apache_request;
my $class = $r->dir_config('WebAppClass')
or die "No WebAppClass defined for this location: ", $r->uri;
if($r->dir_config('WebAppNoAppCache'))
{
return $class->new();
}
else
{
return $Apps{$class} ||= $class->new();
}
}
sub init_mason_interp { $Interp ||= ... } # more "get, set, init"
sub handle_request
{
my($self, $r, $app) = @_;
$app->refresh();
$app->params($self->params);
$app->mason_interp($self->mason_interp);
$app->run();
my $status = $app->status;
$app->clear();
return $status;
}
---
# WebApp/Foo/Bar.pm
package WebApp::Foo::Bar;
use strict;
use WebApp;
our @ISA = qw(WebApp);
sub root_uri { '/foo/bar' } # duplicated, but oh well
...
---
Basically, I try to separate the thing that dispatches incoming requests
(Apache::WebApp) and the things that are dispatched to (the actual apps,
e.g. WebApp::Foo::Bar)
Every directive has the same PerlHandler (Apache::WebApp) but
different WebAppClass settings.
Of course, I'm free to subclass any of these classes to make some sort of
specialized behavior, but so far, the basic "dumb caching" dispatcher
(Apache::WebApp) has done everything I need.
But getting back to the point of this post, Apache::WebApp is where I do all
the per-request setup and cleanup, not in the apps themselves. That way,
writing a WebApp doesn't involve worrying about any of the boring setup and
cleanup stuff that every app needs to do in order to work correctly (e.g.
Not have any stale data left over)
Session cleanup/save-back can be done either in the Apache::WebApp
dispatcher or at the end of the app objects' run() method. In practice, I
do it in the dispatcher and also in some apps, using a save_if_modified()
method which is inexpensive enough that I don't care about duplicated calls.
You'll also notice that I do a "$app->refresh" before and a "$app->clear"
after processing a request in the dispatcher. This is because some apps may
choose to "empty" themselves when not in use, even if they app object is
still cached in %apps. So "clear()" would really clean out all data
structures, while "refresh" would rebuild them before the next run.
-John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ANNOUNCE: MasonX::WebApp 0.01
On Wed, 12 May 2004, John Siracusa wrote: > > You must call clean_request_args() on the ApacheHandler object at the end of > > the request, unless you are making a new ApacheHandler object for every > > request. Otherwise bad things will happen. > > > > This is lame, so if someone thinks of a better way to do this, I'd be happy to > > hear about it. > > In my massively more complicated (in both the good and bad senses of the > word), but spiritually similar Mason-using WebApp framework, I do something > like this: [ much stuff snipped ] I think one of the reasons you can do your stuff that way is that you are using the Mason Interp object to dispatch to Mason, rather than the ApacheHandler object. Mason's ApacheHandler has no mechanism for being handed a set of arguments, it insists on getting them itself (from an Apache::Request or CGI object), which is a little annoying. I hope to make ApacheHandler a little less self-contained in the next major release (1.4), but for now I'm stuck with nasty hacks. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ANNOUNCE: MasonX::WebApp 0.01
On 5/12/04 12:30 PM, Dave Rolsky wrote: > On Wed, 12 May 2004, John Siracusa wrote: >>> You must call clean_request_args() on the ApacheHandler object at the end of >>> the request, unless you are making a new ApacheHandler object for every >>> request. Otherwise bad things will happen. >>> >>> This is lame, so if someone thinks of a better way to do this, I'd be happy >>> to >>> hear about it. >> >> In my massively more complicated (in both the good and bad senses of the >> word), but spiritually similar Mason-using WebApp framework, I do something >> like this: > > [ much stuff snipped ] > > I think one of the reasons you can do your stuff that way is that you are > using the Mason Interp object to dispatch to Mason, rather than the > ApacheHandler object. Mason's ApacheHandler has no mechanism for being > handed a set of arguments, it insists on getting them itself (from an > Apache::Request or CGI object), which is a little annoying. > > I hope to make ApacheHandler a little less self-contained in the next > major release (1.4), but for now I'm stuck with nasty hacks. ...which begs the question, why not use an interp in MasonX::WebApp instead of trying to wedge in behind Mason's ApacheHandler? After all, I think that's the advice you originally gave me way back when... :) -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ANNOUNCE: MasonX::WebApp 0.01
On Wed, 12 May 2004, John Siracusa wrote: > > I hope to make ApacheHandler a little less self-contained in the next > > major release (1.4), but for now I'm stuck with nasty hacks. > > ...which begs the question, why not use an interp in MasonX::WebApp instead > of trying to wedge in behind Mason's ApacheHandler? After all, I think > that's the advice you originally gave me way back when... :) Don't listen to me! Seriously, the ApacheHandler provides some useful functionality like parsing arguments, configuration via httpd.conf, automatic header handling, etc. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
