perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: Handler attributes
Date Fri, 02 May 2003 00:15:44 GMT
Marc M. Adkins wrote:
>>I saw this recently - the cause IIRC was that I didn't preload the module
>>with PerlModule first, so try that if you haven't already.

I'll check why this doesn't work without preloading.

> I've been using:
> 
> 	  <Location /filter>
> 	    SetHandler          modperl
> 	    PerlOutputFilterHandler +Site::Filter
> 	  </Location>
> 
> The '+' is supposed to implicitly call PerlModule (and apparently does).
> 
> When I attempt to use the PerlModule directive separately (outside of the
> <Location> tag) I get an error related to the @INC value not including my
> code directory, which is in fact set up in startup.pl.  So far the directive
> above is the only configuration that I've managed to get working.

+ is fine.

but when do you load startup.pl? This should work:

PerlRequire /path/to/startup.pl (where @INC is adjusted)
PerlModule Site::Filter
<Location /filter>
	    SetHandler          modperl
	    PerlOutputFilterHandler Site::Filter
</Location>

Actually you don't need 'SetHandler modperl' if you don't run a response phase 
in mod_perl.

>>which is the example from the perl.com article
>>
>>http://www.perl.com/pub/a/2003/04/17/filters.html
> 
> 
> Ah, yes, there's that thing where the filter is invoked multiple times...I
> had read about that but forgotten.  Doubtless that is why I'm getting double
> output.  D'oh!

Use $filter->ctx to ensure that something happens once (this is documented). 
Or $filter->remove. I'll update the filter docs soonish.

> Note that your example from the article does not actually use the
> FilterRequestHandler attribute (I'm still wondering just exactly what it is
> supposed to do...I suppose I'll have to traipse through the code sometime).
> Meanwhile, I had apparently gotten the right configuration (using the '+' as
> discussed above) and not re-checked my code with the attribute because _now
> it works_ for me.

FilterRequestHandler marks the handler as a request filter handler (which is 
the default, so you don't have to use that attribute). However if you want to 
use a connection filter you have to use the FilterConnectionHandler attribute.

Why do you need to mark these? Because the configuration directive doesn't say 
anything about the type of the filter:

   PerlOutputFilterHandler Site::Filter

So if we don't know if it's a connection filter or a request one, we don't 
know when to invoke it. Perhaps reading the whole filters document and working 
through all examples will make it more clear.

> Now I've fixed my code to do single output.  A side note, in case anyone
> cares...the method Filter::seen_eos() will _never_ be true unless the code
> calls Filter::read() enough times to go through all of the input.  An
> obvious thing, once it happens.  Perhaps worth a note in the doc, perhaps
> not.  I only found out because I was ignoring the input in my simplistic
> test code, an unrealistic situation for an output handler.	-- mma

That's correct. $f->seen_eos() is a special function for streaming filters and 
you have to read all the input in a loop to get it set. This will be 
documented in the Apache::Filter manpage.


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message