Am 07.11.2012 00:10, schrieb Jeff Lawson:
> On Tue, Nov 6, 2012 at 3:30 AM, Harald Oehlmann
> <harald.oehlm...@elmicron.de> wrote:
>> Am 06.11.2012 09:48, schrieb Jeff Lawson:
>>> I have verified that it now seems fixed for textareas with your
>>> change. I will try to confirm with my colleague about his purported
>>> failure with checkboxes and construct an example if needed.
>>
>> Thank you, Jeff.
>>
>> The reason for this change was to correctly interpret list and values to
>> avoid a malfunction or crash, if the user enteres something, which is
>> not a list.
>>
>
> Here is another example that demonstrates the difference in checkbox
> behavior... In form 1.0, there are several checkboxes selected by
> default, but on form 2.0 none of them are. Note that -value is not
> specified for the checkboxes, but any "true" value was accepted as
> signalled a checked state under form 1.0
>
>
>
> package require form 1.0
>
>
> set response(comnav_O) t
> set response(comnav_L) t
> set response(comnav_D) t
> set response(comnav_G) t
> set response(comnav_R) t
>
> form myform -defaults response -method post
> myform start
>
> puts "<table><tr>"
>
> foreach key {V O L D G R W H I J} {
> puts "<td>"
> myform checkbox comnav_$key -id comnav_$key
> puts "<label for=\"comnav_$key\">$key</label>"
> puts "</td>"
> }
>
> puts "</tr></table>"
> myform submit save_tps -value "Save Report"
>
> myform end
> myform destroy
>
Jeff,
well, this example is IMHO very tricky and it does something very strange.
The base is, that no parameter "-value" is given to the checkboxes.
If there is a default value, then this is taken as value.
Then this is compared to the default value. They are identical, and thus
the checkbox is checked.
It is not the case, that it must be any "true value". It must just exist.
So, the generated code is:
<input type="checkbox" name="comnav_D" checked="checked" id="comnav_D"
value="t" />
if a default value is given, and:
<input type="checkbox" name="comnav_W" id="comnav_W" />
if not.
This can be seen as bug, security hole or feature, that depends.
I think, it is a bug, as arbitrary values may be introduced in the
generated html code.
On html-level, a checkbox without value defaults to "on", at least, this
value is posted by my firefox.
I can understand, that if you have a checkbox with a unique name, you
may just not care about the name and thus, this will work.
I can modify the form package to respect this.
My questions are:
- is this really intended (it is not documented)
- is this intended for all form items (as it was before)
I am personally not in-favour supporting this.
Any opinions ?
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
