[Fwd: Re: mp2: processing a subrequest with HTML::FillInForm]
Here's how I managed to solve it
my $subr = $r->lookup_uri( $redirect );
$subr->add_output_filter( My::Filter::build_handler( $cgi, $messages ) );
build_handler returns a sub which expects to be used like a filter.
This way I can build this sub with request-specific information for
altering the html generated by the subrequest.
Jim Brandt wrote:[color=blue]
> Just a guess since I haven't done it, but maybe the input_filters
> method would give you the Filter object you need?
> Stephen Howard wrote:[color=green]
>> Hi Mark,
>> The other pages on the site are not broken. I appreciate your
>> attempt to identify an underlying flaw, but that is not the case
>> here, and I am aware of the vagaries of html parsing (which is why I
>> leave it in the capable hands of HTML::FillInForm).
>> My question is how do I create a Apache2::Filter "object" to pass
>> into lookup_uri() when all the filter documentation i've seen
>> suggests that filters are subroutines. I'd love to be able to just
>> pass in a subroutine as the second argument to lookup_uri, but none
>> of the documentation suggests that as the way to go.
>> - Stephen
>> Mark Hedges wrote:[color=darkred]
>>> On Mon, 21 Jul 2008, Stephen Howard wrote:
>>>> I have a form validator PerlResponseHandler (using
>>>> Data::FormValidator) that needs to repopulate a form upon
>>>> failure. Problem is, the original form is not generated
>>>> by the handler, but by other pages on the site. My
>>>> thinking is that I ought to be able to do a lookup_uri and
>>>> pass it a filter that can repopulate the html correctly,
>>>> but the online docs for filters is failing me. The
>>>> lookup_uri documentation says that it takes an
>>>> Apache2::Filter object, but nowhere can I find information
>>>> on how to create one of these. Whatever filter I build
>>>> I'll need to be able to pass into it data specific to the
>>>> parent request in order to repopulate the html form
>>>> correctly. How do I do this?
>>> Have you considered fixing the "other pages on the site"?
>>> Pattern-matching HTML that will then be subject to change by
>>> other people on these "other pages" is going to drive you
>>> crazy. Why not just make the forms do what they're supposed
>>> to do?