Re: [RFC] Transitioning from Apache::Registry to Apache handlers
On 20 Apr 2000, Randal L. Schwartz wrote: > > "Doug" == Doug MacEachern <[EMAIL PROTECTED]> writes: > > Doug> why all the globals?? symbol table lookups are much slower than > Doug> lexicals. > > If I recall, the word lately is that they're much closer than they were. i take it back, the symbol table lookups for globals are done at compile time, 5.x has always done that, i think. by the looks of: perl -MO=Terse -e 'my $lex = 1; our $ogv = 1; $gv = 1' they still behave the same at runtime, though what happens during compile time might be different. > But lexicals are still "cleaner", if I recall. indeed.
Re: [RFC] Transitioning from Apache::Registry to Apache handlers
> "Doug" == Doug MacEachern <[EMAIL PROTECTED]> writes: Doug> why all the globals?? symbol table lookups are much slower than Doug> lexicals. If I recall, the word lately is that they're much closer than they were. But lexicals are still "cleaner", if I recall. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [RFC] Transitioning from Apache::Registry to Apache handlers
> So this (attached) section is to be deleted now as a non-relevant? i suppose.
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
On Mon, 17 Apr 2000, Vivek Khera wrote: > > "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: > > SB> Of course, anyone has a sample section handy? I'm still an > SB> C fan, to be changed soon :) > > I don't see what sections have to do with using or not > Apache::Registry instead of handlers... > > But, I've been toying with the idea of writing an Apache::Dispatch > module that would take all URL's of the form something like > > http://localhost/perl/My/Module/handlerfunc > > and dispatch the call to My::Module::handlerfunc() that would be really cool, so long as you can limit which namespaces can be called by the dispatcher. e.g. i wouldn't want the dispatcher to run http://localhost/perl/CORE/dump :)
Re: [RFC] Transitioning from Apache::Registry to Apache handlers
On Thu, 20 Apr 2000, Doug MacEachern wrote:
> On Fri, 14 Apr 2000, Stas Bekman wrote:
>
> > use vars qw($q $switch $status $sessionID);
>
> why all the globals?? symbol table lookups are much slower than lexicals.
> please don't promote globals, pass lexicals to the subroutines.
Yeah, I'll fix that. Just wanted to make the example less messy :)
> > sub handler{
> > my $r = shift;
> > Apache->request($r);
>
> you actually don't need to do that anymore as of 1.22
Oh, that's why -- I've tried without it and worked!
So this (attached) section is to be deleted now as a non-relevant?
=head1 Accessing the Request Object in non-Perl*Handler Modules
Cs can obtain a reference to the request object when it
is passed to them via C<@_>. For example:
sub handler {
my $r = shift;
# ... some code
return OK;
}
In C scripts (and friends), the request object
is available through the Crequest($r)> method. For example:
my $r = Apache->request;
print $r->uri;
In order to make the above work, C internally passes
the original object to Crequest($r)> (transparantly to
the its users). It does:
sub handler {
my $r = shift;
Apache->request($r);
# ... lots of voodoo code :)
return OK;
}
Some modules, like C, rely on the fact that
Crequest()> will retrieve the request object. So when you
use these modules with a script running under C (and
friends) everything is fine. However if you write your own
C you should explicitly write Crequest($r)>
to make these modules work, just like in the above code snippet.
__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--
Re: [RFC] Transitioning from Apache::Registry to Apache handlers
On Fri, 14 Apr 2000, Stas Bekman wrote:
> use vars qw($q $switch $status $sessionID);
why all the globals?? symbol table lookups are much slower than lexicals.
please don't promote globals, pass lexicals to the subroutines.
> sub handler{
> my $r = shift;
> Apache->request($r);
you actually don't need to do that anymore as of 1.22
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
On Mon, 17 Apr 2000, Vivek Khera wrote:
> > "MS" == Matt Sergeant <[EMAIL PROTECTED]> writes:
>
> >> adding handlers as easy as adding Registry scripts. I guess it is
> >> sort of an ultra-light-weight Registry, in some sense.
>
> MS> I've got something pretty similar. Let me know if you want some code.
>
> Sure; it is always good to see other ideas...
>
> Which handler phase did you tie into? I'm thinking just to go along
> the lines of Apache::Registry and use the content phase.
PerlFixupHandler. That way I eliminate stat() calls. At the end of the
fixup handler I push an ordinary PerlHandler onto the stack, which deals
with the main content delivery. But I suppose you could have the Fixup
handler determine what phase to use, via a call to a method in the module
you've used.
Anyway, here's the relevant bit of code, typed in and untested because
it's part of something much larger, so it might not quite work, but
hopefully you'll get the idea:
package Whatever;
sub fixup {
my $r = shift;
my $loc = $r->location;
my $handler = $r->uri;
if ($loc) {
$loc =~ s/\.\*$//; # remove wildcards
$loc =~ s/^\^//; # remove anchor at start
$prefix = $loc;
$handler =~ s/^\Q$loc\E//; # strip location from uri
}
else {
# handler starts from / (sensible?)
$handler =~ s/^\///;
}
$handler =~ s/\//::/g; # change / to ::
$handler =~ s/(.*)::/$1\->/; # change last :: to ->
my $module = $handler;
$module =~ s/\->.*$//;
eval {
require $module;
import $module;
}
if ($@) {
return 404;
}
no strict 'refs';
my $handler = $module->which_handler || 'PerlHandler';
$r->push_handlers( $handler, \&{$handler} );#
return OK;
}
Stick it as a PerlFixupHandler in a or
directive.
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
> "MS" == Matt Sergeant <[EMAIL PROTECTED]> writes: >> adding handlers as easy as adding Registry scripts. I guess it is >> sort of an ultra-light-weight Registry, in some sense. MS> I've got something pretty similar. Let me know if you want some code. Sure; it is always good to see other ideas... Which handler phase did you tie into? I'm thinking just to go along the lines of Apache::Registry and use the content phase.
Re: [RFC] Transitioning from Apache::Registry to Apache handlers
> "DT" == Drew Taylor <[EMAIL PROTECTED]> writes: DT> are beginning the transition to Apache handlers. One other thing that I DT> would love is a module to do checkboxes/pull-down list generation ALA DT> CGI.pm. I might rip off some code and create a module myself. I think it Have a look at CGI::Form. I think it needs CGI::Base and/or CGI::Request. These are dated modules, and have not been maintained in a long time as far as I can see, but they were intended as a more object-oriented CGI API than CGI.pm.
Re: [RFC] Transitioning from Apache::Registry to Apache handlers
Matt Sergeant wrote: > > On Mon, 17 Apr 2000, Vivek Khera wrote: > > > But, I've been toying with the idea of writing an Apache::Dispatch > > module that would take all URL's of the form something like > > > > http://localhost/perl/My/Module/handlerfunc > > > > and dispatch the call to My::Module::handlerfunc() > > > > Assuming that My::Module was already loaded, otherwise it would > > generate a run-time error (or maybe we'd do a "require" -- dunno yet). > > The URL trigger /perl/ would be configurable, of course. > > > > Does anyone have something like this already? It would certainly make > > adding handlers as easy as adding Registry scripts. I guess it is > > sort of an ultra-light-weight Registry, in some sense. > > I've got something pretty similar. Let me know if you want some code. Since I believe I'm the one that started this thread, I'd love to see some code to enable handlers on the fly. In my case I only have perhaps a half-dozen handlers, but multiply this times a lot of virtual hosts and it then becomes a great boon. IMHO, I think this would be a very useful module to people like me who are beginning the transition to Apache handlers. One other thing that I would love is a module to do checkboxes/pull-down list generation ALA CGI.pm. I might rip off some code and create a module myself. I think it would be a good first project (or maybe not - who knows until I try?) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
On Mon, 17 Apr 2000, Vivek Khera wrote: > But, I've been toying with the idea of writing an Apache::Dispatch > module that would take all URL's of the form something like > > http://localhost/perl/My/Module/handlerfunc > > and dispatch the call to My::Module::handlerfunc() > > Assuming that My::Module was already loaded, otherwise it would > generate a run-time error (or maybe we'd do a "require" -- dunno yet). > The URL trigger /perl/ would be configurable, of course. > > Does anyone have something like this already? It would certainly make > adding handlers as easy as adding Registry scripts. I guess it is > sort of an ultra-light-weight Registry, in some sense. I've got something pretty similar. Let me know if you want some code. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
On Mon, 17 Apr 2000, Vivek Khera wrote: > > "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: > > SB> Of course, anyone has a sample section handy? I'm still an > SB> C fan, to be changed soon :) > > I don't see what sections have to do with using or not > Apache::Registry instead of handlers... Because when you have hundreds of different 's to configure (and there is a lot of repetition), it's easier with Perl. Isn't it? At least that's what people said on the list. > But, I've been toying with the idea of writing an Apache::Dispatch > module that would take all URL's of the form something like > > http://localhost/perl/My/Module/handlerfunc > > and dispatch the call to My::Module::handlerfunc() > > Assuming that My::Module was already loaded, otherwise it would > generate a run-time error (or maybe we'd do a "require" -- dunno yet). > The URL trigger /perl/ would be configurable, of course. > > Does anyone have something like this already? It would certainly make > adding handlers as easy as adding Registry scripts. I guess it is > sort of an ultra-light-weight Registry, in some sense. Cool! __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: SB> Of course, anyone has a sample section handy? I'm still an SB> C fan, to be changed soon :) I don't see what sections have to do with using or not Apache::Registry instead of handlers... But, I've been toying with the idea of writing an Apache::Dispatch module that would take all URL's of the form something like http://localhost/perl/My/Module/handlerfunc and dispatch the call to My::Module::handlerfunc() Assuming that My::Module was already loaded, otherwise it would generate a run-time error (or maybe we'd do a "require" -- dunno yet). The URL trigger /perl/ would be configurable, of course. Does anyone have something like this already? It would certainly make adding handlers as easy as adding Registry scripts. I guess it is sort of an ultra-light-weight Registry, in some sense. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 PGP & MIME spoken herehttp://www.kciLink.com/home/khera/
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
On Fri, 14 Apr 2000, Chris Nokleberg wrote: > > > Someone has asked how to move from registry scripts to perl handlers, this > > is my attempt to show in details the process. Comments are welcome. > > In my mind, one of the biggest problems in transitioning from > Apache::Registry is the added server configuration complexity. Would it be > possible to add a section on the best way to simplify or eliminate the need > to modify the conf file for each new handler? sections, etc.? Of course, anyone has a sample section handy? I'm still an C fan, to be changed soon :) __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
> Someone has asked how to move from registry scripts to perl handlers, this > is my attempt to show in details the process. Comments are welcome. In my mind, one of the biggest problems in transitioning from Apache::Registry is the added server configuration complexity. Would it be possible to add a section on the best way to simplify or eliminate the need to modify the conf file for each new handler? sections, etc.? Thanks, Chris -- Chris Nokleberg + Internet Sports Network, Inc. [EMAIL PROTECTED] + http://www.SportsRocket.com/
[RFC] Transitioning from Apache::Registry to Apache handlers
Someone has asked how to move from registry scripts to perl handlers, this
is my attempt to show in details the process. Comments are welcome.
=head1 Transitioning from Apache::Registry to Apache handlers
Even if you are a CGI script die-hard at some point you might want to
move a few or all your scripts to Apache Perl handlers. Actually this
is an easy task, since we saw already what C does to
our scripts so they will appear as Perl handlers to Apache.
Now when you are no longer need a backward mod_cgi compatibility you
can benefit from the Perl libraries working only under
mod_perl. We will see why in a moment.
Let's see an example. We will start with a mod_cgi compatible CGI
script running under C, transpose it into a Perl
content handler and then convert it to use C and
C.
=head2 Starting with mod_cgi Compatible Script
This is the original script's code we are going to work with:
cookie_script.pl
use strict;
use CGI;
use CGI::Cookie;
use vars qw($q $switch $status $sessionID);
init();
print_header();
print_status();
### <-- subroutines --> ###
# the init code
###
sub init{
$q = new CGI;
$switch = $q->param("switch") ? 1 : 0;
# try to retrieve the session ID
# fetch existing cookies
my %cookies = CGI::Cookie->fetch;
$sessionID = exists $cookies{'sessionID'}
? $cookies{'sessionID'}->value : '';
# 0 = not running, 1 = running
$status = $sessionID ? 1 : 0;
# switch status if asked to
$status = ($status+1) % 2 if $switch;
if ($status){
# preserve sessionID if exists or create a new one
$sessionID ||= generate_sessionID() if $status;
} else {
# delete the sessionID
$sessionID = '';
}
} # end of sub init
#
sub print_header{
# prepare a cooke
my $c = CGI::Cookie->new
(-name=> 'sessionID',
-value => $sessionID,
-expires => '+1h');
print $q->header
(-type => 'text/html',
-cookie => $c);
} # end of sub print_header
# print the current Session status and a form to toggle the status
#
sub print_status{
print qq{Cookie};
# print status
print "Status: ",
$status
? "Session is running with ID: $sessionID"
: "No session is running";
# change status form
my $button_label = $status ? "Stop" : "Start";
print qq{
};
print qq{};
} # end of sub print_status
# A dummy ID generator
# Replace with a real session ID generator
sub generate_sessionID {
return scalar localtime;
} # end of sub generate_sessionID
The code is very simple. It creates a session if you've pressed the
I<'Start'> button or deletes it if the I<'Stop'> button has been
pressed. The session is stored and retrieved using the cookies
technique.
Note that we have split the obviously simple and short code into a
three logical units, by putting the code into three subroutines.
init() to initialize global variable and parse incoming data,
print_header() to print the HTTP headers including the cookie header
and finally print_status() to generate the output. Later we will see
that this logical separation will allow us an easy conversion to Perl
content handler code.
We have used global variables for a few variables since we didn't want
to pass them from function to function. In a big project you should be
very restrictive about what variables should be allowed to be global
if any at all. In any case, the init() subroutine makes sure all these
variables are re-initialized for each code reinvocation.
Note that we have used a very simple generate_sessionID() function
that return a date string (i.e. S) as a
session ID. You want to replace this one with code which generates a
unique session every time it was called. And it should be secure,
i.e. users will not be able to forge one and do nasty things.
=head2 Converting into Perl Content Handler
Now let's convert this script into a content handler. There are two
parts to be done; the first one is to configure Apache to run this new
code as a Perl handler, the second one is to modify the code itself.
First we add the following snippet to I:
PerlModule Test::Cookie
SetHandler perl-script
PerlHandler Test::Cookie
After we restart the server, when there is a request whose URI starts
with I, Apache will execute C
subroutine as a content handler. We made sure to preload the
C module at the server start-up, with the C
directive.
Now we are going to modify the script itself. We copy the content to
the file I and place it into one of the directories listed
in C<@INC>. For example if I is a part of C<@INC>
and since we want to call this package C, we can put
I into the I directory.
So this is a new code. Notice t
