Re: help on setting up a PerlFixupHandler
On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: > To fix that, is it safe to change the test to > > defined $r->content_type and $r->content_type ne 'text/html'; > > or is there a better way? I usually don't concern myself with the previous content type when writing -based content handlers. My output is always "text/html" anyway. Would it be safe in your application to just leave it out completely? -chris
Re: Mod_perl how to include the result of mod_autoindex?
On Mon, Aug 11, 2003 at 08:37:19AM -0700, Coexec wrote: > The end user will submit a form. One of the values in > that form will be a path on the local web server. So > in the return of the CGI, I want to include the > results of Apache's autoindex. I cannot figure out > how to do it. If I could pass a variable from a CGI > to an SSI, the problem would be solved, but I do not > believe that it is possible. I have been looking at > Apache::SSI and Apache::AutoIndex but I don't think I > can get them to do what I need. Does anyone have any > suggestions or recommendations? You could probably issue a subrequest in a CGI program running under Apache::Registry, though I'm unsure how to go about capturing the output of a subrequest. However, it would probably be easier to use Apache::Filter with your own Perl handler: PerlModule Apache::Filter PerlModule Apache::Icon PerlModule Apache::AutoIndex PerlModule Apache::MyHandler PerlSetVar Filter On SetHandler perl-script PerlTransHandler Apache::AutoIndex::transhandler PerlHandler Apache::AutoIndex Apache::MyHandler Then your handler can take the output of Apache::AutoIndex and do whatever it likes to it in the same manner as Apache::SSI. The perldoc for Apache::Filter shows you just how to do this. -chris
Re: help on setting up a PerlFixupHandler
On Wed, Aug 06, 2003 at 07:41:20PM +0200, Xavier Noria wrote:
> package Dispatcher;
>
> use Apache::Constants ':common';
>
> sub handler {
> my $r = shift;
>
> return DECLINED if $r->content_type ne 'text/html';
> return SERVER_ERROR unless $r->can_stack_handlers;
>
> $r->handler('perl-script');
> $r->set_handlers(PerlHandler => ['ContentHandler']);
>
> return OK;
> }
>
> 1;
>
> without luck however, keeps on looking under the document root
> for /admin. Should that change be enough?
Are you sure the content-type is "text/html"? Since you have your own
handler, Apache is probably using the value from the
DefaultType directive which, I think, defaults to "text/plain" when Apache
is installed.
-chris
Re: AUTOLOAD in mod_perl (was Re: When perl is not quite fastenough)
I may be veering off-topic, but I've started doing similar things in my own code (generating accessor methods via AUTOLOAD). I ended up writing `Class::Autoload,' which I intend to upload to CPAN when I'm done with documentation and testing. Basically, it exports an AUTOLOAD function that will work with the %FIELDS hash to insert accessor methods into the symbol table as needed. There's also a compile() method that can be used to precompile the methods, which I thought was relevent, given the mod_perl/memory discussion. It also provides for read-only methods, and a typing system like that of `Class::Class.' If there's interest, I'll clutter up the list some more with the POD. On Tue, 2002-12-17 at 11:13, kyle dawkins wrote: > Perrin (et al... cc'ing this back to the list) > > Thanks for this information... it is confirming what I originally > thought, so I don't need to change my code (yet). But I wanted to post > it back to the list to everyone else can benefit from it. > > I personally tend to avoid AUTOLOAD, only because it is a piece of perl > "magic" that can be super-confusing to developers coming to perl (and > mod_perl) from other languages (um, Java) and I think there's a > voodoo-level involved that's a bit high for my tastes. In the one > place I use it, I don't generate anything, just trap calls to methods > with AUTOLOAD and perform a lookup based on the arguments. If it > really is that slow, maybe I'll even rewrite that to use something > other than AUTOLOAD. > > Cheers! > > Kyle Dawkins > Central Park Software > > > On Tuesday, Dec 17, 2002, at 13:13 US/Eastern, Perrin Harkins wrote: > > > kyle dawkins wrote: > >> Sorry to mail you directly... can you just give me two cents on your > >> comment below about AUTOLOAD, mod_perl and memory sharing? I use > >> AUTOLOAD in one module to perform accessors and I wonder if there's a > >> better way to save memory. > > > > AUTOLOAD is kind of slow, so most people put something in there to > > define their accessors as subs by manipulating the symbol table. It's > > easy, and Damian's book has an example. > > > > In mod_perl, you want any methods that you expect to be called to be > > defined in the parent process so they will be shared. I do this by > > building all of the accessors in a BEGIN block in my module which is > > called when I use it in startup.pl. > > > > - Perrin > >
Re: [RFC] Apache::LDAP
On Sun, 2002-12-01 at 23:40, James G Smith wrote: > Per Einar Ellefsen <[EMAIL PROTECTED]> wrote: > >Hi James, > > > >At 02:32 02.12.2002, James G Smith wrote: > >>( Actually, the name is chosen to `rhyme' with Apache::DBI. There > >>are no dependencies on Apache or mod_perl. ) > > > >If there is no link with Apache::DBI, I suggest that you choose a more > >appropriate namespace, like Persistent::LDAP > > Unfortunately, that's already taken. The module on CPAN implements > persistent objects with an LDAP backend (if I read the docs right). > > The problem is that it's generic enough to be made available without > requiring a lot of misc. stuff (i.e., part of a larger package), but > there's not a good place for it. At least, I'm not thinking of > anything. I just did a search on CPAN for `LDAP.' It looks like `Net::LDAP::Persistent' would be a good namespace for your module. At least, I kind of like it. Others may disagree. -- Christopher Grau <[EMAIL PROTECTED]>
Re: Subroutine main redefined?
On Mon, 2002-11-25 at 08:33, Jan Theofel wrote: > > > [Sun Nov 24 17:59:45 2002] shop.pl: Subroutine main redefined at > > > /home/www/[...]/shop/engine/shop.pl line 19. > > > > This is a warning, not an error. > > Ok, but why do I get this warning? I don't redefine the sub. I think you are getting the warning for the same reason I was having trouble: http://perl.apache.org/docs/1.0/guide/config.html#Apache_Restarts_Twice_On_Start On start, Apache actually starts and then restarts. On the restart, you get the warning that the subroutine is redefined. It's harmless.
Problem using variable with @PerlSetVar
Hi, I have a fairly simple problem, but haven't had much luck finding the solution on Google or the mailing list archives. Basically, I have this code in httpd.conf: print "Enter some value you don't want written down: "; my $value = ; chomp $value; print "value = '$value'\n"; # The code works if I do this... # $value = "Foobar"; push @PerlSetVar, ["Foo" => $value]; The value in $value prints to stdout, but the variable "Foo" doesn't get set to $value. However, if I were to set $value to something explicitly, as in the comment above, the code works fine. Based on that, I'm guessing the problem lies with reading from . What am I missing here? Thanks. -chris
