MVC: etoys article

[Marc Lambrichs <ma...@melange-it.nl>]

Hi All,

I just read the article on esite on the perl.com site and I wonder if some
of you have understood it all well enough to answer my questions.

1. Perrin wrote: "All requests are dispatched to the ESF::Control->run()
method first, wrapping them in a try{} block before calling the appropriate
handler() method." Now, is the Control package a PerlInitHandler? If that's
the case Perrin  probably defined a handler() method that contains a sort of
a switch statement, that calls some other handler further up the request
loop, right?

2. Why use a ESF::Util->get_request() method? Wouldn't it have been simpler
to make Control a subclass of Apache or Apache::Request? What's the overall
use of the ESF::Util class?

Cheers,

Marc Lambrichs
----------------------------------
M É L A N G E  I T  B. V.
Amsterdam
----------------------------------

Re: etoys article

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

> If this is the case, then you've already got a hold of the request
through
> the run method. Wouldn't this be possible:
>
> sub run ($$){
>     my ($class, $r) = @_;
>     eval {
>        $class->handler($r);
>     }; etc......
> }
>
> and...
> sub handler ($$) {
>     my ($class, $r) = @_;
>     etc....
> }

Sure, in fact it did do that, but we still needed the
Util->get_request() method.  There were often multiple classes that
needed access to the Apache::Request object (helper methods in the
control base class, some mod_perl-specific model objects, access
handlers, etc.), so we would have been passing it around a lot if we
didn't have that accessor.

- Perrin

Re: etoys article

[Marc Lambrichs <ma...@melange-it.nl>]

----- Original Message -----
From: "Perrin Harkins" <pe...@elem.com>
To: "Marc Lambrichs" <ma...@melange-it.nl>; <mo...@perl.apache.org>
Sent: Sunday, June 16, 2002 11:16 PM
Subject: Re: etoys article


> > 1. Perrin wrote: "All requests are dispatched to the
> ESF::Control->run()
> > method first, wrapping them in a try{} block before calling the
> appropriate
> > handler() method." Now, is the Control package a PerlInitHandler?
>
> No, it's a content handler.  ESF::Control is a base class that the other
> controller classes all inherit from.  It has a run() method that looks a
> bit like this:
>
> sub run {
>     my $class = shift;
>     eval {
>         $class->handler();
>     };
>     if ($@) {
>         # uncaught exception, log and send out pretty error page
>     }
> }
>
> Then in httpd.conf:
>
> <Location /my/controller>
>     SetHandler perl-script
>     PerlHandler My::Controller->run
> </Location>
>
If this is the case, then you've already got a hold of the request through
the run method. Wouldn't this be possible:

sub run ($$){
    my ($class, $r) = @_;
    eval {
       $class->handler($r);
    }; etc......
}

and...
sub handler ($$) {
    my ($class, $r) = @_;
    etc....
}

Saluti,
Marc

Re: etoys article

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

> 1. Perrin wrote: "All requests are dispatched to the
ESF::Control->run()
> method first, wrapping them in a try{} block before calling the
appropriate
> handler() method." Now, is the Control package a PerlInitHandler?

No, it's a content handler.  ESF::Control is a base class that the other
controller classes all inherit from.  It has a run() method that looks a
bit like this:

sub run {
    my $class = shift;
    eval {
        $class->handler();
    };
    if ($@) {
        # uncaught exception, log and send out pretty error page
    }
}

Then in httpd.conf:

<Location /my/controller>
    SetHandler perl-script
    PerlHandler My::Controller->run
</Location>

The idea was to make sure that this common functionality of wrapping the
whole request in an eval block didn't need to be repeated in every
controller class.  There are other ways to do it without using method
handlers, but this seemed the simplest at the time.  The base class also
contains some other shared methods for sending out the response which
all the controllers use.

> 2. Why use a ESF::Util->get_request() method?

So that the Apache::Request object only gets created once per request,
but we don't have to pass it around to any modules that might need it.
It's kind of like making a singleton wrapper around Apache::Request.
Since then, I believe Apache::Request has changed to make this
unnecessary.

> Wouldn't it have been simpler
> to make Control a subclass of Apache or Apache::Request?

That doesn't really make sense to me.  Controllers are not requests, so
why would they subclass from something modelling a request?  They use
the request, but they are not themselves the request.

> What's the overall use of the ESF::Util class?

Besides the Apache::Request object, we had accessors there for getting a
database handle, getting the current session, and similar tasks.  Each
of these would cache for the life of the current request so that the
session would only be fetched once, even if many different modules used
it during the request.  Basically, it saved us from passing all that
stuff around all the time and avoided doing unnecessary work, i.e. if
nothing in the current request needs the session it will not be fetched.

- Perrin