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, rich...@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:mcwa...@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, rich...@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:mcwa...@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-unsubscr...@perl.apache.org > > > > For additional commands, e-mail: embperl-h...@perl.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: embperl-unsubscr...@perl.apache.org > > > For additional commands, e-mail: embperl-h...@perl.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: embperl-unsubscr...@perl.apache.org For additional commands, e-mail: embperl-h...@perl.apache.org