RE: [cgiapp] Re: CGI::Application::Session - session plugin for CGI::Application

["Kinyon, Rob" <suppressed>]

Well, we're not really talking about inheritance, in the classic sense.
We're more discussing the Decorator pattern (for Gang of Four).
C::A::Foo and C::A::Bar are really adding capabilities to C::A.
Discussing inheritance is actually clouding the picture.

What about considering the 3rd-party plugins as delegates vs.
subclasses? C::A::MySuperClass would be a subclass of C::A, but
C::A::Session or C::A::DBI (for example) would not. They would, instead,
register on use() with C::A (using some register method). Registration
would indicate the following:
1) What portions of the pipeline they need access to (the standard areas
would probably be good enough for starters)
2) What method within the class needs to be called at that point
3) When that method need to be called in relation to the other methods
(Use the Apache FIRST, MIDDLE, LAST, REALLY_FIRST, REALLY_LAST options
here)

Registration would also have the effect of instantiating that class and
saving off the object. I'm assuming that these classes will be
singletons, with some being factories, as needed. For example,
C::A::Session would actually register C::A::Session::Factory with C::A,
and it would create C::A::Session objects on each request, as needed.

Part of the issue I'm having with discussing the pipeline is that I
haven't seen what it is we're passing down the pipe from handler to
handler. In Apache, the pipeline passes an Apache::Request object from
the first bucket to the last. Every handler deals with $r, modifying it
as needed.

There's also the capability of declining to handle this situation. The
classic example here is an output filter which cleans HTML. If the
content-type isn't text/html, the filter declines to handle this
request.

By adding the concepts of OK, DECLINED, and NOK, we gain the ability of
adding additional modules, such as C::A::Security. Right now, in my
C::A, I have a App::User object which determines if someone is allowed
in. I'd prefer to delegate that responsibility to C::A::Security. (I'd
actual want to delegate that responsibility to Apache, but I can't, for
legacy issues.)

Rob

-----Original Message-----
From: Stephen Howard [mailto:suppressed 
Sent: Thursday, January 22, 2004 10:04 AM
To: Cees Hek
Cc: petersm; suppressed
Subject: Re: [cgiapp] Re: CGI::Application::Session - session plugin for
CGI::Application



Cees Hek wrote:

>> From: Stephen Howard <suppressed> wrote
>>
>>> do consider when making your "hook stacks" that it might be handy 
>>> for a module to be able to state a preference as to whether it would

>>> rather it's version of the method in question to be run before or 
>>> after the methods of its parent module(s).  There should also be an 
>>> option to blow the stack away and replace it with a new one 
>>> containing only the current module's method.
>>
>
The 'before, after, or clobber' options are to simulate what one would 
normally do during inheritence depending on if you called the 
$self->SUPER::method at the top, at the bottom, or not at all, in your 
derived module's method.

While I still think the pipeline metaphor is an interesting and 
potentially very useful concept, I'm beginning to realize that we're 
potentially negating some of the simplicity and power we get for free 
from Inheritence.

-Stephen



---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed