You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Simon Oldeboershuis <so...@outermedia.de> on 2000/10/06 14:55:07 UTC

checkboxes

Hi there,

we have a problem with checkboxes. If I understood it right, the setter
won't be called if the checkbox is not checked. I do know that http
forms do not submit unchecked checkboxes, but there must be a workaround
for struts!

My suggestion is to add an special init method to the ValidatingForm
which is ALWAYS called BEFORE the parameters are set. In that method one
could set ALL the checkbox parameters to false... the checkboxes which
are checked will override this when the parameters are evaluated! The
developer has to watch the type of input of the form closely for
changes!

A more transparent approach would be better. The checkbox-Tag would have
to write something into the session for later evaluation by the
ActionServlet.

Please let me know if something like this is planned for the next
version or how one could help!

thanx!
	simon

Re: checkboxes

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Chris Miller wrote:

> Hi Simon,
>
> I agree that support for improved checkbox handling needs to be incorporated
> into struts. However the approach you have suggested below does have a
> flaw - namely that if you try to implement a multi-part form (ie wizard)
> using this approach, some extra care is required to ensure that only the
> current page's checkboxes are reset.
> There have however been several submissions from myself and others that take
> a variety of different approaches to the checkbox problem, so hopefully
> we'll see something included soon.
>

The strategy I'm currently testing to deal with this is adding a reset()
method
to ActionForm, which is called before the bean's properties are
populated.  In a
simple (single-form) case, you would just reset the boolean representing
a
checkbox to false, and it will be set to true if included in the request
parameters.  For a multi-part form case, the bean will need to be smart
and only
reset the properties coming from this page -- but reset() will have
access to
the current request so that it can make this decision.

So far, this seems to work pretty well -- look for a checkin this week.

Craig

====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat



Re: checkboxes

Posted by Chris Miller <ch...@hotmail.com>.
Hi Simon,

I agree that support for improved checkbox handling needs to be incorporated
into struts. However the approach you have suggested below does have a
flaw - namely that if you try to implement a multi-part form (ie wizard)
using this approach, some extra care is required to ensure that only the
current page's checkboxes are reset.
There have however been several submissions from myself and others that take
a variety of different approaches to the checkbox problem, so hopefully
we'll see something included soon.

----- Original Message -----
From: "Simon Oldeboershuis" <so...@outermedia.de>
To: <st...@jakarta.apache.org>
Sent: Friday, October 06, 2000 1:55 PM
Subject: checkboxes


> Hi there,
>
> we have a problem with checkboxes. If I understood it right, the setter
> won't be called if the checkbox is not checked. I do know that http
> forms do not submit unchecked checkboxes, but there must be a workaround
> for struts!
>
> My suggestion is to add an special init method to the ValidatingForm
> which is ALWAYS called BEFORE the parameters are set. In that method one
> could set ALL the checkbox parameters to false... the checkboxes which
> are checked will override this when the parameters are evaluated! The
> developer has to watch the type of input of the form closely for
> changes!
>
> A more transparent approach would be better. The checkbox-Tag would have
> to write something into the session for later evaluation by the
> ActionServlet.
>
> Please let me know if something like this is planned for the next
> version or how one could help!
>
> thanx!
> simon
>