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.
That is a nice consise way of
On 2004-01-21, Cees Hek [EMAIL PROTECTED] wrote:
I think a nice addition to CGI::Application would be a system where you
can register multiple functions at the different stages of execution in
CGI::App.
So instead of doing the following:
sub cgiapp_prerun {
my $self = shift;
# do
Cees Hek wrote:
From: Stephen Howard [EMAIL PROTECTED] 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
issues.)
Rob
-Original Message-
From: Stephen Howard [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 22, 2004 10:04 AM
To: Cees Hek
Cc: petersm; [EMAIL PROTECTED]
Subject: Re: [cgiapp] Re: CGI::Application::Session - session plugin for
CGI::Application
Cees Hek wrote:
From: Stephen
Well, this makes sense to me at least to some degree. I'll admit I
haven't reat GoF before, and am having some difficulty coming up with
thorough online information about exactly what a decorator is, but from
what I'm gathering its something of a formalized notion of a mixin.
Please correct
Stephen Howard wrote:
That makes a lot of sense to me for things like Session and DBI, which
could install things similar to $self-query ($self-dbh,
$self-session), but I don't see why a mixin would need to hook into the
pipeline, rather than be called upon by methods in the pipeline.
Perhaps
Mark Stosberg wrote:
On 2004-01-21, Terrence Brannon [EMAIL PROTECTED] wrote:
Cees Hek wrote:
What if someone wants to create a CGI::Application::Session module
based on Apache::Session?
Someone has:
http://perlmonks.org/index.pl?node_id=142050
Thanks for the reference. I definitely don't
From: Cees Hek [EMAIL PROTECTED]
I think a nice addition to CGI::Application would be a system where you
can register multiple functions at the different stages of execution in
CGI::App.
So instead of doing the following:
sub cgiapp_prerun {
my $self = shift;
# do some stuff
}
This is something I've been thinking about in a slightly broader sense,
as I've watched C::A mature. As time has gone on, people have requested
the ability to insert code into certain stages of the C::A process, and
what we've wound up with is something like (if memory serves me right):
petersm wrote:
From: Cees Hek [EMAIL PROTECTED]
We actually do something like this in the CheesePizza. The base class for all
of our plugins (named 'Plugin' btw) has an implementation of cgiapp_prerun
that looks to see if a param named 'preRun' exists. It it does, then it is
run. This was any
On 2004-01-21, Cees Hek [EMAIL PROTECTED] wrote:
I think a nice addition to CGI::Application would be a system where you
can register multiple functions at the different stages of execution in
CGI::App.
So instead of doing the following:
sub cgiapp_prerun {
my $self = shift;
# do
mimicking or stealing what they've done and implementing it in C::A?
Rob
-Original Message-
From: Stephen Howard [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 10:41 AM
To: [EMAIL PROTECTED]
Subject: Re: [cgiapp] Re: CGI::Application::Session - session plugin for
CGI::Application
PROTECTED]
Subject: Re: [cgiapp] Re: CGI::Application::Session - session plugin for
CGI::Application
This is something I've been thinking about in a slightly broader sense,
as I've watched C::A mature. As time has gone on, people have requested
the ability to insert code into certain stages
petersm wrote:
I agree with Mark. I don't see why you have a problem with a call like
$self-SUPER::cgiapp_prerun(). If they are overriding a method but they still
want that method to run then I think this is a very clean and easy solution.
For the most part I feel that there are enough hooks that
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
On Wed, Jan 21, 2004 at 04:15:02PM -0500, petersm wrote:
} I personally like the places that C::A has the hooks in place. Maybe we can
} simply have a way to push code refs onto individual stack (a stack for each
} hook), run the C::A hook method (ie, cgiapp_prerun, cgiapp_postrun...), then
} run
From: Stephen Howard [EMAIL PROTECTED] 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).
From: Stephen Howard [EMAIL PROTECTED] 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
Mark Stosberg wrote:
I've now reviewed the POD and code for this. I find it very useful.
Sure, it's very simple. That means I can focus on CGI::App and
CGI::Session and this little glue module will just work and be easy to
use. So I give the usefulness two thumbs up.
Thanks.
I have one
On 2004-01-19, Cees Hek [EMAIL PROTECTED] wrote:
I haven't put this on CPAN, because I would like some comments on the
usefulness of this module, and more importantly, on the
implementation...
Thanks for putting this together Cees.
I've now reviewed the POD and code for this. I find it
20 matches
Mail list logo
