DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24135>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24135 carselector sample: reloading page puts old values in messages ------- Additional Comments From [EMAIL PROTECTED] 2003-10-26 15:03 ------- Mmmmh... this results from a weird interaction between the value-changed listeners and the reload. With livehttpheaders on Mozilla, I can see that hitting reload sends a POST with woody_submit_id=make&make=Audi&type=Twingo, which is normal since on the original page "Twingo" was selected and we selected "Audi" (hence also woody_submit_id=make) When the page is loaded at first, the "make" widget is set to "Audi", the "type" widget was also set to "Twingo" (which means its value did not changed). The "make"'s widget value-changed listener is then triggered and sets the value of "type" to null. Now when we reload, the "make" widget doesn't see any change in its value ("Audi"), but the "type" widget sees one (from null to "Twingo") and so triggers its value-changed listener, which builds the message "A Audi Twingo is a very good choice." A solution in this particular case could be to change the selection-lists not on value change, but on activate, since the popups are "live". This means that <wd:on-action> should exist on any widget (and not only actions) But this doesn't prevent forged requests to circumvent the above workaround by simply not sending the "woody_submit_id". However, this clearly shows the need for closed enumerations, where a selection-list not only serves as a helper for the user, but also enforces the list of acceptable values. That way, whatever requests are sent, we cannot exit the form with incorrect values.
