perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerald Richter" <>
Subject RE: [$ hidden $] bug in 2.0?
Date Mon, 01 Aug 2005 06:56:34 GMT

Basicly I agree to your argumentation. The point why it is like it is, is
that it should be the same as in 1.3 . The difference is the different
handling of spaces, which is not part of the hidden command, but is due to
the new parser.

The point is that changing it, might break applications that depends on the
current behaviour (not sure if such applications really exists). My plan was
to release final 2.0 next weekend and I don't know if it is a good idea to
change something like this at this point. On the other side, if we want to
change it, it needs to be done right now.


Gerald Richter            ecos electronic communication services gmbh
IT-Securitylösungen * Webapplikationen mit Apache/Perl/mod_perl/Embperl

Post:       Tulpenstrasse 5          D-55276 Dienheim b. Mainz
E-Mail:          Voice:   +49 6133 939-122
WWW:      Fax:     +49 6133 939-333
ECOS BB-5000 Firewall- und IT-Security Appliance:


> -----Original Message-----
> From: Neil Gunton [] 
> Sent: Thursday, July 28, 2005 9:10 PM
> To: Gerald Richter
> Cc:
> Subject: Re: [$ hidden $] bug in 2.0?
> Gerald Richter wrote:
> > Hi Neil,
> > 
> >>I'm attaching the Embperl tar and the source file. You 
> should be able 
> >>to duplicate what I am seeing using these... if not then 
> maybe reality 
> >>is becoming even more distorted here in America than I thought!
> >>
> >>;-)
> >>
> >>Let me know if/what you see...
> >>
> > 
> > 
> > I found the difference. You really used a "bug" in the 1.3 parser.
> > 
> > You wrote [$ hidden $] and I wrote [$hidden$]. The 
> difference is the 
> > space after the hidden. The 1.3 parser interprets this space as an 
> > first empty argument. You can get the same result with [$ 
> hidden , $] 
> > (with or without
> > spaces) in Embperl 2.
> > 
> > I think the way Embperl 2 behaves is more predictable and clean. I 
> > don't think it makes sense to move this bug over to Embperl 2.
> > 
> > You can simple do a   s/hidden/hidden ,/   in your code and 
> things should
> > work with both versions.
> > 
> > Gerald
> Hi Gerald,
> Thinking about this some more, I would like to make one more 
> plea to you about making %fdat work as it did before. The 
> reason is consistency and simplicity. As long as I've used 
> Embperl, I've used %fdat to handle the form variables being 
> passed in, and to control the values going out in the 
> generated HTML. When I want to build a populated form, I set 
> variables in %fdat, and these values are also set up 
> automatically for the script. It's really a very convenient 
> and easy way to handle this stuff. I believe that it's 
> important to make this mechanism work consistently and in a 
> way that doesn't introduce needless additional code for 
> application programmers.
> For example, if I want to set a value for a form field (not 
> hidden, but a real field) then I can just set that value in 
> %fdat, somewhere prior to the form definition. Then, later 
> on, Embperl automatically populates the value of the field 
> accordingly. I believe that this is also the way it is 
> supposed to work in Embperl 2.0. This should, in my opinion, 
> work in the same way for the [$hidden$] meta command. It is 
> highly unintuitive to require a comma after the hidden 
> keyword, or to require a '@ffld = keys %fdat' in order to 
> transfer variables over. You never had to do that before, so 
> why should it be necessary now? Maybe there was a bug in the 
> prior implementation of [$hidden$], but that same bug surely 
> did not also apply to the way we set non-hidden form 
> variables. For those, we simply set the variable value in 
> %fdat. Making it different for hidden variables is just wrong, to me.
> Can't we just make %fdat the one-stop-shop for form 
> variables, as I have always thought it was? I'm not just 
> saying this because all my code works that way - I'm making 
> an impassioned plea for simplicity as well as backward 
> compatibility. I realize it's not the way you designed the 
> new version, but please consider this as being something that 
> might be worth bending.
> Of course, if there is a very good reason for it *not* to 
> work this way (apart from ease of internal
> implementation) then I'm all ears...
> Thanks,
> -Neil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message