Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: Embperl

Handler example?

 

 

ModPerl embperl RSS feed   Index | Next | Previous | View Threaded


mcwanek at fourddev

Jan 7, 2011, 12:12 PM

Post #1 of 5 (1703 views)
Permalink
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 [at] perl
For additional commands, e-mail: embperl-help [at] perl


richter at ecos

Jan 11, 2011, 8:30 PM

Post #2 of 5 (1589 views)
Permalink
RE: Handler example? [In reply to]

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 [at] fourddev]
> Sent: Friday, January 07, 2011 9:13 PM
> To: embperl [at] perl
> 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 [at] perl
> For additional commands, e-mail: embperl-help [at] perl



---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe [at] perl
For additional commands, e-mail: embperl-help [at] perl


mcwanek at fourddev

Jan 12, 2011, 6:44 AM

Post #3 of 5 (1581 views)
Permalink
Re: Handler example? [In reply to]

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 [at] ecos 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 [at] fourddev]
> > Sent: Friday, January 07, 2011 9:13 PM
> > To: embperl [at] perl
> > 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 [at] perl
> > For additional commands, e-mail: embperl-help [at] perl
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe [at] perl
> For additional commands, e-mail: embperl-help [at] perl
>

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe [at] perl
For additional commands, e-mail: embperl-help [at] perl


richter at ecos

Jan 12, 2011, 10:53 AM

Post #4 of 5 (1585 views)
Permalink
RE: Handler example? [In reply to]

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 [at] fourddev]
> Sent: Wednesday, January 12, 2011 3:44 PM
> To: Gerald Richter - ECOS
> Cc: embperl [at] perl
> 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 [at] ecos 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 [at] fourddev]
> > > Sent: Friday, January 07, 2011 9:13 PM
> > > To: embperl [at] perl
> > > 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 [at] perl
> > > For additional commands, e-mail: embperl-help [at] perl
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: embperl-unsubscribe [at] perl
> > For additional commands, e-mail: embperl-help [at] perl
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe [at] perl
For additional commands, e-mail: embperl-help [at] perl


mcwanek at fourddev

Jan 12, 2011, 5:44 PM

Post #5 of 5 (1584 views)
Permalink
Re: Handler example? [In reply to]

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 [at] ecos 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 [at] fourddev]
> > Sent: Wednesday, January 12, 2011 3:44 PM
> > To: Gerald Richter - ECOS
> > Cc: embperl [at] perl
> > 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 [at] ecos 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 [at] fourddev]
> > > > Sent: Friday, January 07, 2011 9:13 PM
> > > > To: embperl [at] perl
> > > > 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 [at] perl
> > > > For additional commands, e-mail: embperl-help [at] perl
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: embperl-unsubscribe [at] perl
> > > For additional commands, e-mail: embperl-help [at] perl
> > >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe [at] perl
For additional commands, e-mail: embperl-help [at] perl

ModPerl embperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.