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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to