I applied the fix suppplied by Frank in :
http://www.gossamer-threads.com/lists/modperl/embperl/98673

And it worked for me. I am using newest released Apache
2.2/Embperl/CGI/mod_perl2 with Perl 5.10.1 (thanks Frank)

Cheers
Brett

> diff ~/Embperl.pm ~/Embperl.pm-FIXED
320,323c320,321
<       # the param_fetch needs CGI.pm 2.43
<       #$params = $cgi->param_fetch( $_ ) ;
<       $params = $cgi->{$_} ;
<       if ($#$params > 0)
---
>       my @values = $cgi->param($_);
>       if ($#values > 0)
325c323
<           $fdat->{ $_ } = join ("\t", @$params) ;
---
>           $fdat->{ $_ } = join ( $self -> config -> mult_field_sep() ,
@values) ;
329c327
<           $fdat->{ $_ } = $params -> [0] ;
---
>           $fdat->{ $_ } = $values[0] ;


On Fri, Feb 5, 2010 at 8:11 PM, Gerald Richter - ECOS <
gerald.rich...@ecos.de> wrote:

>  Hi,
>
>
>
> there are no changes in form handling between 1.x and 2.x (only that 2.x
> can handle UTF-8 correctly).
>
>
>
> %fdat was never persistent between requests. You can use %udat for this,
> use [$ hidden $] to create a set of hidden fields to pass the data to the
> next request.
>
>
>
> That the fields are not shown correctly on your POST example might be the
> case that you use multipart/formdata and yes, I guess you have the problem
> mentioned in http://www.gossamer-threads.com/lists/modperl/embperl/98672
>
>
>
> The APPNAME is not related to forms. It’s necessary for EmbperlObject.
>
>
>
> Gerald
>
>
>
> P.S. Lets move the discussion to the Embperl list
>
>
>
> *From:* Brett @Google [mailto:brett.maxfi...@gmail.com]
> *Sent:* Friday, February 05, 2010 10:51 AM
> *To:* Gerald Richter
> *Subject:* Re: Embperl question
>
>
>
> This was a very stupid question, sorry.
>
> My problem seems that Embperl/CGI.pm form handling may have changed since
> 1.x
>
> In particular there was no concept of an EMBPERL_APPNAME then, now it is
> required.
>
> This legacy 1.x applcation does its own form processing, so maybe i am
> running afoul of the new form processing code.
>
> When i run with arguments on the URL line it works file (the application
> copies request params to %fdat in a way it likes)
>
> [13217]Use App: common
> [13217]Formdata... length = 340
> [13217]FORM: name=value
>
> When the same page gets parameters via a form post, Embperl debug shows
> only form field names, with no values.. so perhaps here Emperl is copying
> the data in some new way that the custom form application dies not like /
> now ?
>
> [13217]Use App: common
> [13220]FORM: Read multipart formdata, length=4220
> [13220]FORM: name=
>
> Or perhaps i am running afoul of the problem sited here :
>
> http://www.gossamer-threads.com/lists/modperl/embperl/98672
>
> I will delve more into the form parsing on monday, for for now the weekend
> calls me :)
>
> Cheers
> Brett
>
> On Thu, Feb 4, 2010 at 12:29 PM, Brett @Google <brett.maxfi...@gmail.com>
> wrote:
>
> HI Gerald,
>
> Does Embperl 2.x copy contents of %fdat from one page to the next in a
> related page flow ?
>
> From reading some legacy HTML::Embperl code, this seems to have been the
> case in the past, running this code ported to Embperl 2.x, the contents of
> %fdat are lost.
>
> The code puts some values in %fdat, and uses them over a set of related
> pages.
>
> When i navigate to the second page in the related page flow, %fdat seems to
> have only what the current page put in it.
>
> If this has always been the case, perhaps i am missing some "magic"
> somewhere on the client side which maintains %fdat between forms.
>
> I am using :
>
> # restore old Embperl 1.x behavior (no parsing HTML blocks)
> EMBPERL_SYNTAX EmbperlBlocks
>
> # optAllFormData, optDisableTableScan, optRawInput
> EMBPERL_OPTIONS 10256
>
> # very important (disable escaping of html etc.,)
> EMBPERL_ESCMODE 0
>
> # hashed db file of sessions (faster)
> PerlSetEnv EMBPERL_SESSION_CLASSES "DB_File Null"
> PerlSetEnv EMBPERL_SESSION_ARGS "FileName=/data/apache/sessions/sessions.db
> LockDirectory=/data/apache/sessions/locks"
>
> # embperl 2.0 + mod_perl 1.0 compat hooks
> PerlModule Embperl
> PerlModule Apache2::compat
>
> Cheers
> Brett
>
>
>

Reply via email to