Re: mod_perl and ssi
Kenneth Lee wrote: > > which handler comes first? PerlHandler or mod_include? > i want to have my PerlHandler generate a SSI skeleton and then > pass it the mod_include's parser to insert some existing static > HTMLs. push_handler() and set_handler() doesn't work for me. > > or is it better to parse the skeleton myself? but i still wonder > if there's any way to chain non-perl handlers. > To my knowledge, there are no layered Apache handlers, so you can't stack mod_perl before mod_include. You can however have layered handlers in mod_perl, for example you can generate SSI HTML with Apache::ASP and then filter it with Apache::SSI, which fully implements mod_include & then some. -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks >> free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Header Sending Bug?
Hello all. I've looked in various mod_perl FAQs but haven't seen the answer to what seems to be a (minor) bug in Apache::Registry. It seems that when PerlSendHeader is On if I haven't yet done a print "Content-type: text/html\n\n" but I want to print a comment into the weblog by doing a print STDERR "I got value $value.\n" It seem Apache::Registry will go ahead and print out the default headers, causing my "Content-type: text/html" to show up ad verbatim on the rendered page: not the desired effect! While I understand that it would make sense for Apache::Registry to print out the headers if I start spewing out text to STDOUT, it is, IMHO, not a good behavior for it to do the same when I write to STDERR. Has this been reported like a kajillion times (in which case someone will politely reach their virtual hand out and smack me upside the head) or is this a sufficiently out-of-the-way sort of error that people haven't reported it yet? At any rate, I'd just be tickled pink if someone fixed it. Yours, David Weekly
Re: Apache::DBI->connect_on_init in BEGIN?
Checkout the sample startup.pl that comes with Apache::DBI.
--Jeff
At 05:08 PM 5/14/00, svante sörmark wrote:
>hi all,
>
>what i'd like to do is "pre-initialize" my DBI connections from whithin
>my PerlHandler's BEGIN block.
>
>something like this:
>BEGIN {
> if ( Apache->dir_config('CONNECT_ON_INIT') {
> Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
> }
>}
>
>but of course the Apache* stuff isn't available at this stage...
>
>does anyone have a clever solution to this? i've resorted to `grep`ing
>httpd.conf for the DBI_INFO string, but that is sooo ugly.
>
>thanks.
>--
>
>Svante Sörmark | Chalmers University IT systems & services | 031-7728665
>
Jeff Beard
_
Web:www.cyberxape.com
Email: jeff at cyberxape.com
Location: Boulder, CO, USA
Re: [TOOT]: Dyslectics untie!
Tobias Hoellrich wrote: > For one of our web services we ask people for a valid email-address to > access the service. Once the address passes an initial RFC822 check we send > a message to the user which contains an activation link. Once the user > receives the message and clicks on the link we consider the email address > valid and he/she can use the service. Maybe this will be useful: http://public.yahoo.com/~jfriedl/regex/code.html and Email::Find from http://athens.arena-i.com/~schwern/src/ /Alex
Re: [OT] Great book!
> "Alex" == Alex Farber <[EMAIL PROTECTED]> writes: Alex> Clayton Cottingham aka DrFrog wrote: >> another great one ive yet to purchase is object oriented perl >> there is some sample chapters >> online somewhere Alex> http://www.effectiveperl.com/toc.html That would be sample chapters for EPP, not OOP. :) For sample chapters of OOP, try somewhere south of www.manning.com, I believe. -- 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!
an idea for a PerlFixupHandler
It always bugged me that for a PerlHandler, I needed to set *two* things... both the SetHandler and the PerlHandler. I have this idea that a good generic PerlFixupHandler would fix that. Instead of setting the mime-type to "text/html", we'd set the mime-type to "text/html;Apache::Registry" for those directories that wanted Registry mangling, or "text/html;HTML::Mason" for Mason, etc. That of course would skate through the standard MIME phase being unmatched, and the Fixup handler would see the semicolon, rip out the second part as a Perl handler, and unshift the handler while setting the handler to perl-script. So, I'd merely have to do things like AddHandler text/html;HTML::Mason .htm .html at the top level. And if I wanted a particular file not to be Mason, I could wrap it: ForceType text/html I bet mod_mime_magic could even then be used to reach inside a file and intuit the right PerlHandler based on content. And stacking would be easy: AddType text/html;Apache::OutputChain;Apache::SSIChain Any thoughts on this? Am I confused to think that MIME phase would not get in the way? Or should this go ahead of the core MIME so that it can do some magic redirection as well? For that, I think I'd like PerlTypeHandler ahead of the core MIME that can do stuff like this: PerlSetVar ReType 'text/(plain|html)=text/html;Apache::Registry' and then anything that made it to here that looks text/plain or text/html really gets mapped to Registry. Thoughts? Am I trying to be too generic? I like useful frameworks. :) -- 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: Virtual servers mixing up "require"d scripts
Hi all, On Sun, 14 May 2000, Uri Bernstein wrote: > Geoffrey Young wrote: >> http://perl.apache.org/guide/control.html#Starting_a_Personal_Server_for_E >> Ged Haywood wrote: >>> You shold use one real server per developer. Make them listen on >>> different ports (>1024). You won't lose much on memory. > - Is this a known bug, or an unavoidable by-product of the way > mod_perl works? The latter. > - Is it related to the fact I'm using Apache::Registry? Would > switching to the native Apache API fix it? > - Is it related to the fact I'm using "require", with ".pl" files? > Would switching to "use" (with .pm modules) fix it? I guess the previous answer answers all these too. 73, Ged.
Re: Header Sending Bug?
I don't see a problem with this but maybe I'm missing your point. :) If PerlSendHeader is set to "On", you don't have to send a header in your program. If you want to retain control of when the header is sent, set PerlSendHeader to "Off" and do it yourself. --Jeff At 12:53 AM 5/14/00, David E. Weekly wrote: >Hello all. I've looked in various mod_perl FAQs but haven't seen the >answer to what seems to be a (minor) bug in Apache::Registry. > >It seems that when PerlSendHeader is On if I haven't yet done a >print "Content-type: text/html\n\n" > >but I want to print a comment into the weblog by doing a >print STDERR "I got value $value.\n" > >It seem Apache::Registry will go ahead and print out the default >headers, causing my "Content-type: text/html" to show up ad verbatim >on the rendered page: not the desired effect! > >While I understand that it would make sense for Apache::Registry >to print out the headers if I start spewing out text to STDOUT, >it is, IMHO, not a good behavior for it to do the same when I write >to STDERR. > >Has this been reported like a kajillion times (in which case someone >will politely reach their virtual hand out and smack me upside the >head) or is this a sufficiently out-of-the-way sort of error that >people haven't reported it yet? At any rate, I'd just be tickled >pink if someone fixed it. > > Yours, > David Weekly Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Re: Apache::DBI->connect_on_init in BEGIN?
I guess I don't know enough about your specific case. :)
On the systems I work on, I use "PerlRequire startup.pl" prior to loading
anything else so that I can use the connection in subsequent code. Seems to
work out fine for what I'm doing.
--Jeff
At 05:30 PM 5/14/00, svante sörmark wrote:
>yeah, i know about startup.pl, and i have been using it until now,
>but the goal here was to avoid having to put the same configuration
>in two different files :).
>
>Jeff Beard wrote:
> >
> > Checkout the sample startup.pl that comes with Apache::DBI.
> >
> > --Jeff
> >
> > At 05:08 PM 5/14/00, svante sörmark wrote:
> > >hi all,
> > >
> > >what i'd like to do is "pre-initialize" my DBI connections from whithin
> > >my PerlHandler's BEGIN block.
> > >
> > >something like this:
> > >BEGIN {
> > > if ( Apache->dir_config('CONNECT_ON_INIT') {
> > >
> Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
> > > }
> > >}
> > >
> > >but of course the Apache* stuff isn't available at this stage...
> > >
> > >does anyone have a clever solution to this? i've resorted to `grep`ing
> > >httpd.conf for the DBI_INFO string, but that is sooo ugly.
> > >
> > >thanks.
> > >--
> > >
> > >Svante Sörmark | Chalmers University IT systems & services | 031-7728665
> > >
> >
> > Jeff Beard
> > _
> > Web:www.cyberxape.com
> > Email: jeff at cyberxape.com
> > Location: Boulder, CO, USA
>
>--
>
>Svante Sörmark | Chalmers University IT systems & services | 031-7728665
>
Jeff Beard
_
Web:www.cyberxape.com
Email: jeff at cyberxape.com
Location: Boulder, CO, USA
Re: Apache::DBI->connect_on_init in BEGIN?
yeah, i know about startup.pl, and i have been using it until now,
but the goal here was to avoid having to put the same configuration
in two different files :).
Jeff Beard wrote:
>
> Checkout the sample startup.pl that comes with Apache::DBI.
>
> --Jeff
>
> At 05:08 PM 5/14/00, svante sörmark wrote:
> >hi all,
> >
> >what i'd like to do is "pre-initialize" my DBI connections from whithin
> >my PerlHandler's BEGIN block.
> >
> >something like this:
> >BEGIN {
> > if ( Apache->dir_config('CONNECT_ON_INIT') {
> > Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
> > }
> >}
> >
> >but of course the Apache* stuff isn't available at this stage...
> >
> >does anyone have a clever solution to this? i've resorted to `grep`ing
> >httpd.conf for the DBI_INFO string, but that is sooo ugly.
> >
> >thanks.
> >--
> >
> >Svante Sörmark | Chalmers University IT systems & services | 031-7728665
> >
>
> Jeff Beard
> _
> Web:www.cyberxape.com
> Email: jeff at cyberxape.com
> Location: Boulder, CO, USA
--
Svante Sörmark | Chalmers University IT systems & services | 031-7728665
Re: an idea for a PerlFixupHandler
On 14 May 2000, (Randal L. Schwartz) wrote: > > It always bugged me that for a PerlHandler, I needed to set *two* > things... both the SetHandler and the PerlHandler. > > I have this idea that a good generic PerlFixupHandler would fix that. > Instead of setting the mime-type to "text/html", we'd set the > mime-type to "text/html;Apache::Registry" for those directories that > wanted Registry mangling, or "text/html;HTML::Mason" for Mason, etc. > That of course would skate through the standard MIME phase being > unmatched, and the Fixup handler would see the semicolon, rip out the > second part as a Perl handler, and unshift the handler while setting > the handler to perl-script. So, I'd merely have to do things like > > AddHandler text/html;HTML::Mason .htm .html You mean AddType here I think... > at the top level. And if I wanted a particular file not to be Mason, > I could wrap it: > > > ForceType text/html > Why not again just: AddType text/html .html > I bet mod_mime_magic could even then be used to reach inside a file > and intuit the right PerlHandler based on content. And stacking would > be easy: > > AddType text/html;Apache::OutputChain;Apache::SSIChain > > Any thoughts on this? Am I confused to think that MIME phase would > not get in the way? Or should this go ahead of the core MIME so that > it can do some magic redirection as well? For that, I think I'd > like PerlTypeHandler ahead of the core MIME that can do stuff like this: > > PerlSetVar ReType 'text/(plain|html)=text/html;Apache::Registry' > > and then anything that made it to here that looks text/plain or text/html > really gets mapped to Registry. > > Thoughts? Am I trying to be too generic? I like useful frameworks. :) Nah - go for it. AxKit's XMLFinder does something pretty similar, only in not quite as generic a way, so it would be perfectly possible. -- 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: mod_perl and ssi
[EMAIL PROTECTED] (Joshua Chamas) wrote: >Kenneth Lee wrote: >> >> which handler comes first? PerlHandler or mod_include? >> i want to have my PerlHandler generate a SSI skeleton and then >> pass it the mod_include's parser to insert some existing static >> HTMLs. push_handler() and set_handler() doesn't work for me. >> >> or is it better to parse the skeleton myself? but i still wonder >> if there's any way to chain non-perl handlers. >> > >To my knowledge, there are no layered Apache handlers, so you >can't stack mod_perl before mod_include. You can however >have layered handlers in mod_perl, for example you can generate >SSI HTML with Apache::ASP and then filter it with Apache::SSI, >which fully implements mod_include & then some. Yes - you'll probably want to use Apache::Filter (implements the filtering framework, so one handler can filter another) with Apache::SSI and Apache::RegistryFilter (which ships with new Apache::Filter). If you use this approach, you'll have a config directive like "PerlHandler Apache::RegistryFilter Apache::SSI" in your httpd.conf file. You can also call the methods of Apache::SSI yourself if you don't want to chain PerlHandlers. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Apache::DBI->connect_on_init in BEGIN?
hi all,
what i'd like to do is "pre-initialize" my DBI connections from whithin
my PerlHandler's BEGIN block.
something like this:
BEGIN {
if ( Apache->dir_config('CONNECT_ON_INIT') {
Apache::DBI->connect_on_init(Apache->dir_config('DBI_INFO');
}
}
but of course the Apache* stuff isn't available at this stage...
does anyone have a clever solution to this? i've resorted to `grep`ing
httpd.conf for the DBI_INFO string, but that is sooo ugly.
thanks.
--
Svante Sörmark | Chalmers University IT systems & services | 031-7728665
Re: [OT] Great book!
Clayton Cottingham aka DrFrog wrote: > another great one ive yet to purchase is object oriented perl > there is some sample chapters > online somewhere http://www.effectiveperl.com/toc.html > > "Effective Perl Programming" by Hall w/ Schwartz. /Alex
Re: Virtual servers mixing up "require"d scripts
Geoffrey Young wrote: > > -Original Message- > > From: Ged Haywood [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, May 11, 2000 12:26 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Virtual servers mixing up "require"d scripts > > > > > > Hi there, > > > > On Thu, 11 May 2000, Uri Bernstein wrote: > > > > > Hi, > > > In order to provide a "private" development environment to each of > > > our developers, we defined a virtual server per developer. > > Each virtual > > > server has its root aliased to a different directory > > > [snip] > > > This seems to work fine most of the time, but, sometimes, > > the "require"d > > > scripts get mixed up: The "main" script from one virtual > > server seems to > > > be using "require"d scripts belonging to another virtual server. > > > > You shold use one real server per developer. Make them listen on > > different ports (>1024). You won't lose much on memory. > > as an alternative, I think this crept into the latest guide: > > http://perl.apache.org/guide/control.html#Starting_a_Personal_Server_for_E > > HTH > > --Geoff Thanx, Geoff and Ged, for your help. I guess I'll go with a multiple-ports solution (although having people's names as a their virtual host names was really convenient). However, just out of curiosity, I wonder if someone can give me some insight into this problem: - Is this a known bug, or an unavoidable by-product of the way mod_perl works? - Is it related to the fact I'm using Apache::Registry? Would switching to the native Apache API fix it? - Is it related to the fact I'm using "require", with ".pl" files? Would switching to "use" (with .pm modules) fix it? -- Uri
Re: mod_perl and ssi
> "JC" == Joshua Chamas <[EMAIL PROTECTED]> writes: JC> Kenneth Lee wrote: >> >> i want to have my PerlHandler generate a SSI skeleton and then >> pass it the mod_include's parser to insert some existing static >> HTMLs. push_handler() and set_handler() doesn't work for me. JC> To my knowledge, there are no layered Apache handlers, so you JC> can't stack mod_perl before mod_include. You can however If all that is desired is to insert static html pages, then try using Apache::Include from your mod_perl handler. Check out Apache::Sandwich to see how it is used there if you need more examples.
Re: Problem with @INC
Yeah but that doesn't help him entirely with a solution to his problem --
which is that he wants to load something at runtime later on -- not at
compile time.
And in fact, it is a must to be able to do this in some cases. eg he
correctly points out that LWP uses the factory design pattern to load
modules dynamically rather than at compile time. I use this technique all
over the stuff I write because it conveniently defers the decision of what
to load --
Of course, if it is loaded ahead of time using PerlRequire then there isn't
any problem... and you get enhanced performance, but it is also a pain to
know all the modules and submodules you want to load ahead of time.
CAVEAT ALERT: Then the only caveat is namespace problems if there is more
than one local copy of a module...
however, given that caveat in mind, the following code should work well:
use lib qw(./Modules);
use vars qw(@SAVED_INC);
BEGIN {
@SAVED_INC = @INC;
}
@INC = @SAVED_INC;
In the header of the relevant scripts.
Later,
Gunther
At 11:36 PM 5/13/00 +0300, Stas Bekman wrote:
>On Sat, 13 May 2000, Robert Nice wrote:
>
> > Hi,
> >
> > Simple problem, I had a quick search thorugh the archives and a good
> > delve into the perl website, no joy.
>
>You didn't delve deep enough, perl.apache.org/index.html reveals no
>mod_perl specific info.
>
>Guide is your guide into mod_perl. The answer to your question is there:
>http://perl.apache.org/guide/porting.html#_INC_and_mod_perl
>
> > (Using modPerl 1.23)
> >
> > #!/usr/bin/perl -w
> >
> > use lib '../site_perl';
> > use CGI;
> >
> > my $cgi = new CGI;
> > print $cgi->header;
> > print join("\n", @INC);
> > ---
> > First time (compiling run):
> > ../site_perl
> > /usr/lib/perl5/5.00503/i386-linux
> > /usr/lib/perl5/5.00503
> > /usr/lib/perl5/site_perl/5.005/i386-linux
> > /usr/lib/perl5/site_perl/5.005
> > .
> > /etc/httpd/
> > /etc/httpd/lib/perl
> >
> > Second run :
> > /usr/lib/perl5/5.00503/i386-linux
> > /usr/lib/perl5/5.00503
> > /usr/lib/perl5/site_perl/5.005/i386-linux
> > /usr/lib/perl5/site_perl/5.005
> > .
> > /etc/httpd/
> > /etc/httpd/lib/perl
> > ---
> >
> > In other words my 'use lib' line disappears. I can understand why. You
> typically won't need it after
> > it's already been compiled. I've been happily using modPerl for ages
> and this
> > hasn't caused a problem. My company however newly requires that I speak
> to 25 different credit card
> > processors and I wanted to pull them in with 'eval "require
> $classname"' statements like LWP does
> > with net protocols. For efficency
> > I'd like to compile them when needed not in bulk on the first run.
> > I'd also prefer not to put my libraries in the system library area as
> it defeats my development
> > setup of having test and beta libraries on the same machine.
> > I've got a workaround (I force them all to load on the first run if
> under modPerl), however I
> > thought I'd post, might be something for the developers to think about.
> >
> > Cheers,
> >
> > Robert Nice
> > Technical Director
> > WebsiteBilling.com Inc
> >
>
>
>
>_
>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.org http://stason.org/TULARC
>http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
__
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
