Jan 12, 2011, 5:44 PM
Post #5 of 5
(3514 views)
Permalink
Yep, tried that too.
When we do that, then the %fdat is right inside all the different
Execute() calls, but Embperl fails to fill out form fields automagically
like it should.
So I think we're pretty much sunk at this point :(.
Thanks for the info.
Matt
On 01/12/11 19:53 +0100, richter@ecos.de wrote:
> Mmmh, that looks like you hit a bug :-(
>
> The quick workaround would be to do the fdat => \%fdat for every Execute.
>
> The correct solution is to fix the bug, but I cannot not promise when I will find time to do so, because this looks like some more work...
>
> Gerald
>
>
> > -----Original Message-----
> > From: Matt J Cwanek [mailto:mcwanek@fourddev.com]
> > Sent: Wednesday, January 12, 2011 3:44 PM
> > To: Gerald Richter - ECOS
> > Cc: embperl@perl.apache.org
> > Subject: Re: Handler example?
> >
> > Yes, we're already doing that.
> >
> > The problem is if I do that from inside my handler, then if the requested page
> > being Execute()'d does it's own calls to Execute() to include (say) a header
> > and footer, the fdat inside the header/footer pages (nested Execute()) have
> > an empty fdat, and it's address is different from the fdat I passed to the initial
> > Execute().
> >
> > For example:
> >
> > -> request for index.html
> >
> > -> my handler builds fdat and then calls:
> > Embperl::Execute(
> > { input => \src,
> > inputfile => $filename,
> > fdat => \%fdat,
> > output => \$body,
> > options => 256
> > });
> >
> > where $src is the contents of index.html with some other perl code added
> > (which is the reason for the handler).
> >
> > -> index.html contains calls to Execute() to include header.html,
> > footer.html, etc.
> >
> > -> if I dump out %fdat in index.html (or even in my handler), it has the
> > correct contents (and same memory address)
> >
> > -> if I dump out %fdat in header.html/footer.html, it is empty and has
> > a different memory address than %fdat in index.html
> >
> >
> > I tried replacing Embperl::Execute() in my handler with
> > Embperl::Req::ExecuteRequest( undef, { <same options as above> } ), like
> > Embperl.pm does in it's handler, but that didn't change anything.
> >
> >
> > Thanks,
> > Matt
> >
> >
> >
> >
> > On 01/12/11 05:30 +0100, richter@ecos.de wrote:
> > > Hi,
> > >
> > > you should pass your %fdat as hashref to the outermost Execute call with
> > the parameter fdat.
> > >
> > > That should normaly do the trick
> > >
> > > Gerald
> > >
> > >
> > > > -----Original Message-----
> > > > From: Matt J Cwanek [mailto:mcwanek@fourddev.com]
> > > > Sent: Friday, January 07, 2011 9:13 PM
> > > > To: embperl@perl.apache.org
> > > > Subject: Handler example?
> > > >
> > > > Hello:
> > > >
> > > > Is there an example somewhere of using a custom handler that
> > > > eventually calls Embperl to process the page? I'm working from some
> > > > old code that used HTML::Embperl to do this, and am having trouble
> > > > getting fdat to work properly with my handler under Embperl/MP2.
> > > >
> > > > The HTML::Embperl handler that I'm working from (and that works fine
> > > > with
> > > > HTML::Embperl) would take care of creating fdat on it's own using
> > > > CGI, and eventually would call HTML::Embperl::Execute to process the
> > > > page (optDisableFormData was enabled).
> > > >
> > > > As I try to port this forward to Embperl/MP2, I'm having problems
> > > > with fdat being clobbered later by subsequent nested
> > > > Embperl::Execute calls, which wasn't a problem with
> > > > HTML::Embperl/MP1. It's almost like a scope problem, but it only seems
> > to shows up if I have nested Execute calls.
> > > >
> > > >
> > > > Thanks for any help.
> > > >
> > > > Matt
> > > >
> > > >
> > > > --------------------------------------------------------------------
> > > > - To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> > > > For additional commands, e-mail: embperl-help@perl.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> > > For additional commands, e-mail: embperl-help@perl.apache.org
> > >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org