You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Massimo Manghi <mx...@apache.org> on 2012/10/30 00:33:14 UTC
Rivet 2.1.0rc2 and 2.0.6rc2
New tar balls shipping Rivet 2.0.6 and 2.1.0 are available for download from
http://people.apache.org/~mxmanghi/
feedback will be appreciated.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 12.11.2012 23:53, schrieb Massimo Manghi:
>
>
> On 11/12/2012 11:03 AM, Harald Oehlmann wrote:
>>> 2) There are 2 entries for 'checkbox' and no explanation for
>>> 'checkboxes'. The second entry might be further elaborated adding some
>>> examples and be changed to be the manual entry for method 'checkboxes'.
>>> Harald can you provide for a simple code example to be placed there? I
>>> can do it myself but you probably have one at reach.
>>
>> Referencing page:
>> http://tcl.apache.org/rivet/manual/form_package.html
>> - checkbox is explained twice.
>> - the parameters -values and -labels are documented for checkbox (which
>> are AFAIK not supported). They should be documented for checkboxes
>> - As an example, I would just use the example in checkbox and formulate
>> it with checkboxes:
>> myform checkboxes options -values {opt1 opt2 opt3 opt3} -labels {"Option
>> 1" "Option 2" "Option 3" "Option 4"}
>
> I tested the example you proposed with the intention of using it for
> documenting the 'checkboxes' method. Value in the 'response' array are
> not treated properly at least in the case Option 2 and Option 4 are
> selected because also Option 3 gets checked after the form date are
> sent. It works if I check Option 1 and Option 3 for example, I haven't
> tested other combinations of checkbox selections. The whole script
>
> source form2.tcl
>
> load_response response
> catch {parray response}
> form myform -defaults response -method post
> myform start
>
> myform checkboxes options -values {opt1 opt2 opt3 opt3} -labels {"Option
> 1" "Option 2" "Option 3" "Option 4"}
>
> myform submit save_tps -value "Save"
> myform end
> myform destroy
Massimo,
Sorry, there was an error in my example, please correct the double-opt3
in the values list. The example should be as follows:
myform checkboxes options -values {opt1 opt2 opt3 opt4} -labels {"Option
1" "Option 2" "Option 3" "Option 4"}
Thank you,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Massimo Manghi <mx...@apache.org>.
On 11/12/2012 11:03 AM, Harald Oehlmann wrote:
>> 2) There are 2 entries for 'checkbox' and no explanation for
>> 'checkboxes'. The second entry might be further elaborated adding some
>> examples and be changed to be the manual entry for method 'checkboxes'.
>> Harald can you provide for a simple code example to be placed there? I
>> can do it myself but you probably have one at reach.
>
> Referencing page:
> http://tcl.apache.org/rivet/manual/form_package.html
> - checkbox is explained twice.
> - the parameters -values and -labels are documented for checkbox (which
> are AFAIK not supported). They should be documented for checkboxes
> - As an example, I would just use the example in checkbox and formulate
> it with checkboxes:
> myform checkboxes options -values {opt1 opt2 opt3 opt3} -labels {"Option
> 1" "Option 2" "Option 3" "Option 4"}
I tested the example you proposed with the intention of using it for
documenting the 'checkboxes' method. Value in the 'response' array are
not treated properly at least in the case Option 2 and Option 4 are
selected because also Option 3 gets checked after the form date are
sent. It works if I check Option 1 and Option 3 for example, I haven't
tested other combinations of checkbox selections. The whole script
source form2.tcl
load_response response
catch {parray response}
form myform -defaults response -method post
myform start
myform checkboxes options -values {opt1 opt2 opt3 opt3} -labels {"Option
1" "Option 2" "Option 3" "Option 4"}
myform submit save_tps -value "Save"
myform end
myform destroy
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Massimo Manghi <mx...@apache.org>.
On 11/12/2012 11:03 AM, Harald Oehlmann wrote:
> Am 12.11.2012 10:49, schrieb Massimo Manghi:
>> Two questions about form2.tcl
>>
>> 1) I realize there 2 methods (checkbox and checkboxes) with very close
>> names, the latter being obviously equivalent to calling the first as
>> many times as the number of boxes defined in its arguments. I think it
>> would be good if we supported only one of them ('checkboxes' since we
>> have also 'radiobuttons', deprecate the other) being general enough to
>> bear all the functionalities required.
> As far as I remember, I have introduces "checkboxes" in form2.tcl.
> It is exactly what "radiobuttons" is for "radiobutton".
> I have no issue to throw "checkboxes" out.
> checkboxes must be calles with "-labels" and "-values",
> checkbox with "-label" and -value"
yes, I think this is the way we should go. After all having a single
checkbox is meaningful (unlike for radiobuttons), so I would simply
stress out the syntax for checkboxes to make clear the analogy with
'radiobuttons' for mnemonic reasons.
> Referencing page:
> http://tcl.apache.org/rivet/manual/form_package.html
> - checkbox is explained twice.
> - the parameters -values and -labels are documented for checkbox (which
> are AFAIK not supported). They should be documented for checkboxes
> - As an example, I would just use the example in checkbox and formulate
> it with checkboxes:
> myform checkboxes options -values {opt1 opt2 opt3 opt3} -labels {"Option
> 1" "Option 2" "Option 3" "Option 4"}
>
> Thank you,
> Harald
>
Thanks Harald, I'm going to wait for Jeff's comments and then I will
change the docs and create the new Rivet release candidate.
thanks
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 12.11.2012 10:49, schrieb Massimo Manghi:
> Two questions about form2.tcl
>
> 1) I realize there 2 methods (checkbox and checkboxes) with very close
> names, the latter being obviously equivalent to calling the first as
> many times as the number of boxes defined in its arguments. I think it
> would be good if we supported only one of them ('checkboxes' since we
> have also 'radiobuttons', deprecate the other) being general enough to
> bear all the functionalities required.
As far as I remember, I have introduces "checkboxes" in form2.tcl.
It is exactly what "radiobuttons" is for "radiobutton".
I have no issue to throw "checkboxes" out.
checkboxes must be calles with "-labels" and "-values",
checkbox with "-label" and -value"
>
> 2) There are 2 entries for 'checkbox' and no explanation for
> 'checkboxes'. The second entry might be further elaborated adding some
> examples and be changed to be the manual entry for method 'checkboxes'.
> Harald can you provide for a simple code example to be placed there? I
> can do it myself but you probably have one at reach.
Referencing page:
http://tcl.apache.org/rivet/manual/form_package.html
- checkbox is explained twice.
- the parameters -values and -labels are documented for checkbox (which
are AFAIK not supported). They should be documented for checkboxes
- As an example, I would just use the example in checkbox and formulate
it with checkboxes:
myform checkboxes options -values {opt1 opt2 opt3 opt3} -labels {"Option
1" "Option 2" "Option 3" "Option 4"}
Thank you,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Massimo Manghi <mx...@apache.org>.
Two questions about form2.tcl
1) I realize there 2 methods (checkbox and checkboxes) with very close
names, the latter being obviously equivalent to calling the first as
many times as the number of boxes defined in its arguments. I think it
would be good if we supported only one of them ('checkboxes' since we
have also 'radiobuttons', deprecate the other) being general enough to
bear all the functionalities required.
2) There are 2 entries for 'checkbox' and no explanation for
'checkboxes'. The second entry might be further elaborated adding some
examples and be changed to be the manual entry for method 'checkboxes'.
Harald can you provide for a simple code example to be placed there? I
can do it myself but you probably have one at reach.
-- Massimo
On 11/10/2012 02:44 PM, Harald Oehlmann wrote:
>
>
> Yery good, thank you. I am happy, that we managed to get this out.
> IMHO the current solution is good. Thank you all, Harald
>
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 09.11.2012 20:24, schrieb Jeff Lawson:
> On Fri, Nov 9, 2012 at 3:56 AM, Harald Oehlmann
> <ha...@elmicron.de> wrote:
>>
>> here is my proposal of the functionality.
>> Could you test, if this is ok for you ?
>> The code is already commited in trunk.
>> The result of your test is below.
>>
>
> I've tested this new code and it seems to properly restore the old
> behavior for the specific instance in our site. I'm not currently
> aware of any other differences in behavior remaining to be fixed.
Yery good, thank you.
I am happy, that we managed to get this out.
IMHO the current solution is good.
Thank you all,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Jeff Lawson <je...@bovine.net>.
On Fri, Nov 9, 2012 at 3:56 AM, Harald Oehlmann
<ha...@elmicron.de> wrote:
>
> here is my proposal of the functionality.
> Could you test, if this is ok for you ?
> The code is already commited in trunk.
> The result of your test is below.
>
I've tested this new code and it seems to properly restore the old
behavior for the specific instance in our site. I'm not currently
aware of any other differences in behavior remaining to be fixed.
Thanks,
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 09.11.2012 10:28, schrieb Harald Oehlmann:
> Am 09.11.2012 00:50, schrieb Massimo Manghi:
>> Hi Jeff and Harald
>>
>> On 11/08/2012 09:16 PM, Jeff Lawson wrote:
>>> On Thu, Nov 8, 2012 at 7:58 AM, Harald Oehlmann
>>> <ha...@elmicron.de> wrote:
>>>> Am 07.11.2012 00:10, schrieb Jeff Lawson:
>>>>> On Tue, Nov 6, 2012 at 3:30 AM, Harald Oehlmann
>>>>> <ha...@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
>>>>>
>>>>>
>>
>> I agree that we should preserve the former behavior (form 1.0) to keep
>> form 2.0 compatible with existing code and also because it's rather
>> intuitive and desirable to have default values of checkboxes (like for
>> any other input element) set at the form level instead of setting each
>> input element independently.
>
> Thank you, Jeff and Massimo,
> I propose to solve it in the following way:
> - only for checkboxes (not for radiobutton, where it worked before too):
> If there is a default value and no "-value" defined, only the attribute
> "checked" is set, but not the value.
>
> Why I think, it is a security hole if the default value is inserted in
> the "value" property of the html code:
> Imagine:
> checkbox a
> and the url:
> localhost?a=arbitrary data
> then, the arbitrary data is entered in the html code:
> <type="checkbox value="arbitrary data">
> An attacker may inject a kilobyte of vulnerable code in the html code.
> If method "post" is used, nobody will see the code. A user must just
> click (or must be redirected) to inject the code.
Hello Jeff,
here is my proposal of the functionality.
Could you test, if this is ok for you ?
The code is already commited in trunk.
The result of your test is below.
Massimo, I would propose to change the documentation of the form package.
Compare to http://tcl.apache.org/rivet/manual/form_package.html
:
- -values and -labels is valid for "checkboxes", not for checkbox
Add a small paragraph:
If -value is not given, the browser default is used (normally "ON").
In this case, a existing default value with any value would initially
select the checkbox.
Thank you,
Harald
----
<html>
<head /><body>
<form action="/formtest2.rvt" method="post">
<table><tr>
<td>
<input type="checkbox" name="comnav_V" id="comnav_V" />
<label for="comnav_V">V</label>
</td>
<td>
<input type="checkbox" name="comnav_O" checked="checked" id="comnav_O" />
<label for="comnav_O">O</label>
</td>
<td>
<input type="checkbox" name="comnav_L" checked="checked" id="comnav_L" />
<label for="comnav_L">L</label>
</td>
<td>
<input type="checkbox" name="comnav_D" checked="checked" id="comnav_D" />
<label for="comnav_D">D</label>
</td>
<td>
<input type="checkbox" name="comnav_G" checked="checked" id="comnav_G" />
<label for="comnav_G">G</label>
</td>
<td>
<input type="checkbox" name="comnav_R" checked="checked" id="comnav_R" />
<label for="comnav_R">R</label>
</td>
<td>
<input type="checkbox" name="comnav_W" id="comnav_W" />
<label for="comnav_W">W</label>
</td>
<td>
<input type="checkbox" name="comnav_H" id="comnav_H" />
<label for="comnav_H">H</label>
</td>
<td>
<input type="checkbox" name="comnav_I" id="comnav_I" />
<label for="comnav_I">I</label>
</td>
<td>
<input type="checkbox" name="comnav_J" id="comnav_J" />
<label for="comnav_J">J</label>
</td>
</tr></table>
<input type="submit" name="save_tps" value="Save Report" />
</form>
</body>
</html>
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 09.11.2012 00:50, schrieb Massimo Manghi:
> Hi Jeff and Harald
>
> On 11/08/2012 09:16 PM, Jeff Lawson wrote:
>> On Thu, Nov 8, 2012 at 7:58 AM, Harald Oehlmann
>> <ha...@elmicron.de> wrote:
>>> Am 07.11.2012 00:10, schrieb Jeff Lawson:
>>>> On Tue, Nov 6, 2012 at 3:30 AM, Harald Oehlmann
>>>> <ha...@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
>>>>
>>>>
>
> I agree that we should preserve the former behavior (form 1.0) to keep
> form 2.0 compatible with existing code and also because it's rather
> intuitive and desirable to have default values of checkboxes (like for
> any other input element) set at the form level instead of setting each
> input element independently.
Thank you, Jeff and Massimo,
I propose to solve it in the following way:
- only for checkboxes (not for radiobutton, where it worked before too):
If there is a default value and no "-value" defined, only the attribute
"checked" is set, but not the value.
Why I think, it is a security hole if the default value is inserted in
the "value" property of the html code:
Imagine:
checkbox a
and the url:
localhost?a=arbitrary data
then, the arbitrary data is entered in the html code:
<type="checkbox value="arbitrary data">
An attacker may inject a kilobyte of vulnerable code in the html code.
If method "post" is used, nobody will see the code. A user must just
click (or must be redirected) to inject the code.
Thank you,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Massimo Manghi <mx...@apache.org>.
Hi Jeff and Harald
On 11/08/2012 09:16 PM, Jeff Lawson wrote:
> On Thu, Nov 8, 2012 at 7:58 AM, Harald Oehlmann
> <ha...@elmicron.de> wrote:
>> Am 07.11.2012 00:10, schrieb Jeff Lawson:
>>> On Tue, Nov 6, 2012 at 3:30 AM, Harald Oehlmann
>>> <ha...@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
>>>
>>>
I agree that we should preserve the former behavior (form 1.0) to keep
form 2.0 compatible with existing code and also because it's rather
intuitive and desirable to have default values of checkboxes (like for
any other input element) set at the form level instead of setting each
input element independently.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Jeff Lawson <je...@bovine.net>.
On Thu, Nov 8, 2012 at 7:58 AM, Harald Oehlmann
<ha...@elmicron.de> wrote:
> Am 07.11.2012 00:10, schrieb Jeff Lawson:
>> On Tue, Nov 6, 2012 at 3:30 AM, Harald Oehlmann
>> <ha...@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
>
Chrome, Firefox, and Safari all seem to use "on" as the checked value
if another value isn't explicitly specified.
The HTML5 spec also says "on" is the value that should be used in such cases:
http://dev.w3.org/html5/spec/common-input-element-apis.html#dom-input-value-default-on
It's difficult for me to see how preserving the old behavior would be
a "security hole", especially since its existence is only being
interpreted as a boolean checked/unchecked state.
If you choose to not preserve the old behavior, you should at least
make the absence of the -value option trigger an error at runtime
rather than silently having incorrect behavior. Otherwise this will
potentially impact many users silently and unpredictably.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 07.11.2012 00:10, schrieb Jeff Lawson:
> On Tue, Nov 6, 2012 at 3:30 AM, Harald Oehlmann
> <ha...@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-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Jeff Lawson <je...@bovine.net>.
On Tue, Nov 6, 2012 at 3:30 AM, Harald Oehlmann
<ha...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Jeff Lawson <je...@bovine.net>.
On Tue, Nov 6, 2012 at 1:46 AM, Harald Oehlmann
<ha...@elmicron.de> wrote:
> Am 05.11.2012 18:38, schrieb Jeff Lawson:> As I mentioned in my report,
> "It doesn't seem to affect text or
>> select" so those should be working fine.
>>
>> Did you also test checkbox? I didn't include a test for it in that
>> sample code, but one of my colleagues reported that it was also
>> affecting them. You might want to check all of the input types just
>> to be sure.
>
> I rechecked a couple of them including checkbox(es), radio(buttons) and
> it all works fine.
>
> For, me, it is fixed now.
> Below is my test code, based on your example.
>
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.
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by David Welton <da...@dedasys.com>.
On Tue, Nov 6, 2012 at 9:40 AM, Ronnie Brunner
<ro...@netcetera.com> wrote:
> For me it was a great advantage to always dump all these tests right
> into the Websh test suite. Specifically since you mentioned it's a
> regression issue that worked before. On every bug or improvement: add
> a test to the test suite and then just know that you didn't break
> anything that worked before.
Big +1
Lots and lots of tests give you more confidence to change stuff.
--
David N. Welton
http://www.dedasys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Massimo Manghi <mx...@apache.org>.
On 11/06/2012 10:58 AM, Harald Oehlmann wrote:
>
> I was not aware of automated tests with Rivet, sorry...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
The folder 'tests' has plenty of examples from which you can draw on.
Just take one easy enough to understand and the try to replicate it with
your stuff.
Don't forget to write a Changelog entry for your patch to form2.tcl
ciao
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 06.11.2012 09:40, schrieb Ronnie Brunner:
> Hi guys
>
>> For, me, it is fixed now.
>> Below is my test code, based on your example.
>
> For me it was a great advantage to always dump all these tests right
> into the Websh test suite. Specifically since you mentioned it's a
> regression issue that worked before. On every bug or improvement: add
> a test to the test suite and then just know that you didn't break
> anything that worked before.
>
> I know that you already have a test suite setup so adding this should
> be a piece of cake.
>
> hth and sorry if it sounds like a lecture :-)
> Ronnie
I was not aware of automated tests with Rivet, sorry...
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Ronnie Brunner <ro...@netcetera.com>.
Hi guys
> For, me, it is fixed now.
> Below is my test code, based on your example.
For me it was a great advantage to always dump all these tests right
into the Websh test suite. Specifically since you mentioned it's a
regression issue that worked before. On every bug or improvement: add
a test to the test suite and then just know that you didn't break
anything that worked before.
I know that you already have a test suite setup so adding this should
be a piece of cake.
hth and sorry if it sounds like a lecture :-)
Ronnie
--
Ronnie Brunner | ronnie.brunner@netcetera.com | T +41-44-247 79 79 |
Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com |
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 05.11.2012 18:38, schrieb Jeff Lawson:> As I mentioned in my report,
"It doesn't seem to affect text or
> select" so those should be working fine.
>
> Did you also test checkbox? I didn't include a test for it in that
> sample code, but one of my colleagues reported that it was also
> affecting them. You might want to check all of the input types just
> to be sure.
I rechecked a couple of them including checkbox(es), radio(buttons) and
it all works fine.
For, me, it is fixed now.
Below is my test code, based on your example.
Harald
----
<html>
<head /><body>
<?
package require form
set response(department) "Development"
#parray response
form myform -defaults response -method post
myform start
puts "<table>"
puts "<tr><th>Department:</th><td>"
#myform select department -values {Sales Development Operations}
#myform text department -size 200
#myform textarea department -rows 8 -cols 80
#myform checkboxes department -values {Sales Development Operations}
#myform checkbox department -value Development
#myform radiobuttons department -values {Sales Development Operations}
#myform radio department -value Development
#myform hidden department -value Development
puts "</td></tr>"
myform submit save_tps -value "Save Report"
myform end
myform destroy
?>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Jeff Lawson <je...@bovine.net>.
As I mentioned in my report, "It doesn't seem to affect text or
select" so those should be working fine.
Did you also test checkbox? I didn't include a test for it in that
sample code, but one of my colleagues reported that it was also
affecting them. You might want to check all of the input types just
to be sure.
On Mon, Nov 5, 2012 at 11:34 AM, Harald Oehlmann
<ha...@elmicron.de> wrote:
> Am 02.11.2012 21:49, schrieb Jeff Lawson:
>> I think we're seeing a regression in the form package not honoring the
>> default values for textareas and checkbox. It doesn't seem to affect
>> text or select. Try the following example:
>>
>>
>>
>>
>> package require form
>>
>> set response(department) "Sales"
>>
>> #parray response
>>
>> form myform -defaults response -method post
>> myform start
>>
>> puts "<table>"
>> puts "<tr><th>Department:</th><td>"
>> #myform select department -values {Sales Development Operations}
>> #myform text department -size 200
>> myform textarea department -rows 8 -cols 80
>> puts "</td></tr>"
>>
>> myform submit save_tps -value "Save Report"
>>
>> myform end
>> myform destroy
>
> Jeff,
>
> thank you reporting this.
>
> Indeed, textarea was forgotten. It is now corrected in the trunk.
>
> But I don't see the issue with "select".
> Below is your example and my result.
> The corrected "form2.tcl" is attached.
>
> Could you please double-check ?
>
> Thank you,
> Harald
> ---------------------------------------
> Thus, the file:
> --formtest.rvt--
> <html>
> <head /><body>
> <?
> package require form
>
> set response(department) "Development"
>
> #parray response
>
> form myform -defaults response -method post
> myform start
>
> puts "<table>"
> puts "<tr><th>Department:</th><td>"
> myform select department -values {Sales Development Operations}
> #myform text department -size 200
> #myform textarea department -rows 8 -cols 80
> puts "</td></tr>"
>
> myform submit save_tps -value "Save Report"
>
> myform end
> myform destroy
> ?>
> </body>
> </html>
> --eof--
> returns:
> --html--
> <html>
> <head /><body>
> <form action="/formtest.rvt" method="post">
> <table>
> <tr><th>Department:</th><td>
> <select name="department" >
> <option value="Sales">Sales</option>
> <option value="Development" selected="selected">Development</option>
> <option value="Operations">Operations</option>
> </select>
> </td></tr>
> <input type="submit" name="save_tps" value="Save Report" />
> </form>
>
> </body>
> </html>
> --eof--
> a
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 02.11.2012 21:49, schrieb Jeff Lawson:
> I think we're seeing a regression in the form package not honoring the
> default values for textareas and checkbox. It doesn't seem to affect
> text or select. Try the following example:
>
>
>
>
> package require form
>
> set response(department) "Sales"
>
> #parray response
>
> form myform -defaults response -method post
> myform start
>
> puts "<table>"
> puts "<tr><th>Department:</th><td>"
> #myform select department -values {Sales Development Operations}
> #myform text department -size 200
> myform textarea department -rows 8 -cols 80
> puts "</td></tr>"
>
> myform submit save_tps -value "Save Report"
>
> myform end
> myform destroy
Jeff,
thank you reporting this.
Indeed, textarea was forgotten. It is now corrected in the trunk.
But I don't see the issue with "select".
Below is your example and my result.
The corrected "form2.tcl" is attached.
Could you please double-check ?
Thank you,
Harald
---------------------------------------
Thus, the file:
--formtest.rvt--
<html>
<head /><body>
<?
package require form
set response(department) "Development"
#parray response
form myform -defaults response -method post
myform start
puts "<table>"
puts "<tr><th>Department:</th><td>"
myform select department -values {Sales Development Operations}
#myform text department -size 200
#myform textarea department -rows 8 -cols 80
puts "</td></tr>"
myform submit save_tps -value "Save Report"
myform end
myform destroy
?>
</body>
</html>
--eof--
returns:
--html--
<html>
<head /><body>
<form action="/formtest.rvt" method="post">
<table>
<tr><th>Department:</th><td>
<select name="department" >
<option value="Sales">Sales</option>
<option value="Development" selected="selected">Development</option>
<option value="Operations">Operations</option>
</select>
</td></tr>
<input type="submit" name="save_tps" value="Save Report" />
</form>
</body>
</html>
--eof--
a
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Massimo Manghi <mx...@apache.org>.
Hi Harald
When you have figured it out please commit the bugfix in trunk, I will
merge it into branches/2.1 and prepare a new tarball
thanks
-- Massimo
On 11/03/2012 03:54 PM, Harald Oehlmann wrote:
>>
>> thanks, this what I wanted to ask.
>
> I caused this propably. May look to it on monday.
>
> Sorry,
> Harald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 02.11.2012 23:16, schrieb Massimo Manghi:
>
>
> On 11/02/2012 11:11 PM, Jeff Lawson wrote:
>> This definitely seems to only occur in the 2.1.0rc and not in the
>> 2.0.6rc.
>>
>> Additionally, doing "package require form 1.0" restores the correct
>> behavior, so this is isolated to the form 2.0 implementation in
>> 2.1.0rc
>>
>>
>
> thanks, this what I wanted to ask.
I caused this propably. May look to it on monday.
Sorry,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Massimo Manghi <mx...@apache.org>.
On 11/02/2012 11:11 PM, Jeff Lawson wrote:
> This definitely seems to only occur in the 2.1.0rc and not in the 2.0.6rc.
>
> Additionally, doing "package require form 1.0" restores the correct
> behavior, so this is isolated to the form 2.0 implementation in
> 2.1.0rc
>
>
thanks, this what I wanted to ask.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Jeff Lawson <je...@bovine.net>.
This definitely seems to only occur in the 2.1.0rc and not in the 2.0.6rc.
Additionally, doing "package require form 1.0" restores the correct
behavior, so this is isolated to the form 2.0 implementation in
2.1.0rc
On Fri, Nov 2, 2012 at 3:49 PM, Jeff Lawson <je...@bovine.net> wrote:
>
> I think we're seeing a regression in the form package not honoring the
> default values for textareas and checkbox. It doesn't seem to affect
> text or select. Try the following example:
>
>
>
>
> package require form
>
> set response(department) "Sales"
>
> #parray response
>
> form myform -defaults response -method post
> myform start
>
> puts "<table>"
> puts "<tr><th>Department:</th><td>"
> #myform select department -values {Sales Development Operations}
> #myform text department -size 200
> myform textarea department -rows 8 -cols 80
> puts "</td></tr>"
>
> myform submit save_tps -value "Save Report"
>
> myform end
> myform destroy
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Jeff Lawson <je...@bovine.net>.
On Mon, Oct 29, 2012 at 6:33 PM, Massimo Manghi <mx...@apache.org> wrote:
> New tar balls shipping Rivet 2.0.6 and 2.1.0 are available for download from
>
> http://people.apache.org/~mxmanghi/
>
> feedback will be appreciated.
>
> -- Massimo
>
I think we're seeing a regression in the form package not honoring the
default values for textareas and checkbox. It doesn't seem to affect
text or select. Try the following example:
package require form
set response(department) "Sales"
#parray response
form myform -defaults response -method post
myform start
puts "<table>"
puts "<tr><th>Department:</th><td>"
#myform select department -values {Sales Development Operations}
#myform text department -size 200
myform textarea department -rows 8 -cols 80
puts "</td></tr>"
myform submit save_tps -value "Save Report"
myform end
myform destroy
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Massimo Manghi <ma...@unipr.it>.
On 10/30/2012 04:49 AM, Harald Oehlmann wrote:
> Am 30.10.2012 00:33, schrieb Massimo Manghi:
>> New tar balls shipping Rivet 2.0.6 and 2.1.0 are available for download
>> from
>>
>> http://people.apache.org/~mxmanghi/
>>
>> feedback will be appreciated.
>
> Could you give a small sentence what changed ?
>
> Thank you,
> Harald
>
* update of manual page for command 'makeurl'
* session database support for Mysql and Sqlite had a bug since a
incomplete unique key was created in table rivet_session_cache
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.1.0rc2 and 2.0.6rc2
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 30.10.2012 00:33, schrieb Massimo Manghi:
> New tar balls shipping Rivet 2.0.6 and 2.1.0 are available for download
> from
>
> http://people.apache.org/~mxmanghi/
>
> feedback will be appreciated.
Could you give a small sentence what changed ?
Thank you,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org