Re: [cgiapp] hook question
Hi Cees,
I'm not actually trying to add all three hooks at once; I'm only enabling one
at
a time. The only one that was working was the $self-add_callback().
When I rearrange the code as you have, all three callbacks work, just as you
say. I don't understand why though.
What's the difference between:
#!/usr/bin/perl
use strict;
use warnings;
my $webapp = Private::Webapp-new();
$webapp-run();
package Private::Webapp;
use base 'CGI::Application';
__PACKAGE__-add_callback('prerun', sub { print STDERR hook_prerun 1\n });
Private::Webapp-add_callback('prerun', sub { print STDERR hook_prerun 2\n });
# ...
... and ...
#!/usr/bin/perl
use strict;
use warnings;
package Private::Webapp;
use base 'CGI::Application';
__PACKAGE__-add_callback('prerun', sub { print STDERR hook_prerun 1\n });
Private::Webapp-add_callback('prerun', sub { print STDERR hook_prerun 2\n });
# ...
package main;
my $webapp = Private::Webapp-new();
$webapp-run();
1;
It seems like adding package main; (which I believe is happening implicitly in
the first example) and moving the code is changing the semantics of how it's
processed even though things should still be happening in the same phases?
Todd
From: Cees Hek cees...@gmail.com
To: CGI Application cgiapp@lists.erlbaum.net
Sent: Thu, July 29, 2010 6:48:34 PM
Subject: Re: [cgiapp] hook question
On Fri, Jul 30, 2010 at 7:58 AM, Todd Ross tar.li...@yahoo.com wrote:
I understand the distinction between compile time and run time (as phases),
but
I'm not fully appreciating the impact here; I'm still a little lost.
Hi Todd,
You are actually running into a couple of problems, one of them is
what Michael has described, and the other is that the callback code
will not run the same callback method multiple times at the same hook
location. You are hooking the same method three times, but it will
only ever be executed once.
So, place your instance code at the end of the file, and create a
separate callback for each call to add_callback and you will see that
it does work (ideally though, you should be placing your packages into
separate files as it will save you many headaches down the road --
especially when working with mod_perl or other persistant perl
processes):
#!/usr/bin/perl
use strict;
use warnings;
package Private::Webapp;
use base 'CGI::Application';
__PACKAGE__-add_callback('prerun', sub { print STDERR hook_prerun 1\n });
Private::Webapp-add_callback('prerun', sub { print STDERR hook_prerun 2\n });
sub setup {
my $self = shift;
$self-start_mode('begin');
$self-mode_param('rm');
$self-run_modes(
begin = 'do_begin'
);
$self-add_callback('prerun', sub { print STDERR hook_prerun 3\n });
}
sub do_begin {
my $self = shift;
my $output = Hello, CGI::Application!\n;
return $output;
}
package main;
my $webapp = Private::Webapp-new();
$webapp-run();
1;
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] hook question
On 07/29/2010 05:58 PM, Todd Ross wrote:
I understand the distinction between compile time and run time (as phases),
but
I'm not fully appreciating the impact here; I'm still a little lost.
You indicate that method calls happen at runtime. Assuming that these qualify
as method calls ...
__PACKAGE__-add_callback('prerun', \hook_prerun);
Private::Webapp-add_callback('prerun', \hook_prerun);
Yes those are method calls and they happen at run time. So they happen
after you've already created and run your application.
... isn't the only time they can be processed during compile time? They're
not
in a method that can be invoked at run time.
No, they aren't any different than the methods you invoked to create
your application object (new) nor the method you invoked to run it (run).
Even if the package were placed into a separate .pm file, you indicate that
the
usepackage statement is going to be processed at compile time, which seems
like the same phase they're processed in in my existing example. Why would
the
behavior change?
use will find the package, compile it and then run it, returning the
value of the last operation in that package (which is why you always see
Perl packages with a 1; at the bottom, so that it has a successful
statement to run that returns a true value).
In your case the same basic things happen except that there is no use
to compile and run the package before you create and run your
application object. So perl compiles that script (including your web app
package) and then starts executing the script. And you create and run
your application object before you run those callbacks, so you never see
them executing.
--
Michael Peters
Plus Three, LP
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Running a plain CGI::Application as FastCGI / PSGI
A long time ago Mark Rajcok wrote: I want to convert an app I have from FastCGI and Apache to PSGI and Starman. Sorry to come back this old issue, but I'm planning to move from (Apache) mod_cgi to mod_fastgci. However I have recently read a lot about Plank/PSGI. I think I got the idea of Plank/PSGI (a specification and middleware for web framework developers) but I don't quite understand what benefits my CGI::App based webapp gets using mod_psgi instead of mod_fastcgi ? Which one is faster ? Will I have more hosting options when PSGI has been established as de-facto standard ? Anyway PSGI is a future-proof, right ? # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Running a plain CGI::Application as FastCGI / PSGI
On 07/30/2010 11:50 AM, Jani Hurskainen wrote: I think I got the idea of Plank/PSGI (a specification and middleware for web framework developers) but I don't quite understand what benefits my CGI::App based webapp gets using mod_psgi instead of mod_fastcgi ? It's Plack not Plank :) The benefit is that once your application works with PSGI then you can move it between mod_cgi, mod_perl, fastcgi, Starman, Tatsumaki, Twiggy, etc. It's not tied to a particular web server since there are Plack adapter layers that can be used to make a PSGI application run on any of those. Most web frameworks try to abstract away most of this already, but they all do it in different wants. PSGI is meant to standardize all of these so there's not so much wheel reinvention. Also it allows people to write middleware components that can be run for any PSGI application. So a catalyst app running under mod_perl can use the same debugging toolbar as a CGI::Application app running under Starman. -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
