Bug 12189 - Setting default values for the <input:checkbox> Tag
Summary: Setting default values for the <input:checkbox> Tag
Status: RESOLVED FIXED
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Input Taglib (show other bugs)
Version: 1.0
Hardware: PC other
: P3 critical with 1 vote (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-08-30 13:10 UTC by bigjuju4
Modified: 2007-04-21 23:20 UTC (History)
0 users



Attachments
patch for Checkbox.java (664 bytes, patch)
2002-09-16 15:59 UTC, Curt Wilhelm
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description bigjuju4 2002-08-30 13:10:07 UTC
Hi!
I have read the code for the implementation of the Checkbox tag and found out 
that the defaults attibute is only considered if the request has some 
parameters. 

See: if (!req.getParameterNames().hasMoreElements()) in the code.
It means that if the request has any parameters, the defaults attribute of the 
tag will not be considered, although the name attribute of the tag is not in 
the request.

I' would rather propose to consider the defaults attribute of the tag if there 
is no param in the request with the name of the tag, and not if the request has 
no params.

i.e with the following code: 

String[] checked = req.getParameterValues(name);
if (checked==null){
  // The request does not contains a param with the name of the tag
  / Consider the default(s) attribute of the tag
  ...
}
else{
  // The request has a param with the name of the tag
  // Ignore the default(s) attribute of the tag
  ...
}

Actually the code looks like this:

String[] checked = req.getParameterValues(name);
          if (!req.getParameterNames().hasMoreElements()) {


Hope this helps...
Thanx...
Comment 1 Curt Wilhelm 2002-09-16 15:59:59 UTC
Created attachment 3083 [details]
patch for Checkbox.java
Comment 2 Karl von Randow 2003-03-29 23:09:24 UTC
This implementation is because when a checkbox is unchecked, nothing is 
included in the request with the name of the checkbox. Therefore it is 
impossible to tell whether a request.getParameter( "checkboxname" ) == null 
whether the checkbox should use its default value or whether we're previously 
chosen to uncheck it.

I'm considering a method whereby another field in the form (a non-checkbox 
field that doesn't suffer from this problem) can be tested to see if it is 
null or not null, so that we can determine whether to use default or not in a 
checkbox. This field could be a hidden field that we generate automatically or 
just another nominated field on the form. It seems like a bit of a hack... 
does anyone want to discuss this?

Alternatively, use the JavaBean support and then you can manage checkbox 
default values etc in the bean.
Comment 3 Michael Weigand 2005-10-20 14:32:10 UTC
Solution for default value could be:

Define a inputfield with the same name right after the checkbox. If checkbox 
is checked then the value of checkbox will be read, otherwise the value of the 
hidden field.

<input type="checkbox" name="testchk" value="true"/>
<input name="testchk" type="hidden" value="false" />

for the struts development i would suggest to extend the checkboxtag to have 
an property uncheckedValue and if this property is set, automatically add the 
hiddenfield.

Greetings,

michael.weigand@michaelweigand.de
Comment 4 Karl von Randow 2005-10-20 21:53:51 UTC
That could work, however adding another field to the form changes the nature 
of what's generated in the HTML, and I think the input taglib has always been 
a 1-1 type of library. It could cause difficulty for people iterating over a 
form at runtime (eg Javascript); it would post either a single (the hidden) or 
multiple values depending upon the check state, which might be misinterpreted 
on the server; finally in a situation where there are multiple checkboxes with 
the same name it would cause all of the off values to be sent with any on 
values which would require special treatment on the server side.

I've had long enough to think about this! I think the real issue is knowing 
whether this is a redisplay of the form or the initial display. In the case of 
a redisplay we want to use the information in the request, in the case of an 
initial display we want to use the default.

In comment 2 I suggested using another field in the form (a non checkbox) to 
indicate whether this was a redisplay or not. The only problem with that is 
that some fields will possibly be on multiple pages in a sequence of forms so 
we could be steered wrong.

How about this for a solution? We add an "indicator" (or better name) 
attribute to the form tag, if the request parameter with the name given in 
indicator is set then we assume this is a redisplay, and use the appropriate 
default logic on checkboxes in the form. Also we add an indicator attribute to 
the checkbox tag so that it can be controlled at a closer level (say different 
parts of the same form appear each time you submit so there is no one 
indicator to say if the whole form is a redisplay).

I think this could work quite nicely; it will be 100% backwards compatible (no 
changes in generated code) and I think should work for all situations (except 
where there are only checkboxes in a form in which case you would need to 
artificially introduce a hidden indicator field).

What are your thoughts?
Comment 5 Karl von Randow 2007-04-21 23:20:51 UTC
This bug is resolved in my latest commit. Checkboxes can now detect whether to use default values, or 
not, based on whether any other fields in the form (before the checkboxes) have matching parameters in 
the request. If there are no other such fields to do the detection with then the Checkbox reverts to its 
original behaviour.