FAQ
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

Search Discussions

  • Richter at Jan 12, 2011 at 4:31 am
    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
    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
  • Matt J Cwanek at Jan 12, 2011 at 2:44 pm
    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
    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
  • Richter at Jan 12, 2011 at 6:53 pm
    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
    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
    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
  • Matt J Cwanek at Jan 13, 2011 at 1:44 am
    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
    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
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupembperl @
categoriesmodperl, perl
postedJan 7, '11 at 8:13p
activeJan 13, '11 at 1:44a
posts5
users2
websiteperl.apache.org

2 users in discussion

Matt J Cwanek: 3 posts Richter: 2 posts

People

Translate

site design / logo © 2022 Grokbase