Return-Path: <ate@iwise1.demon.nl>
Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list struts-dev@jakarta.apache.org
Received: (qmail 5730 invoked from network); 9 Oct 2000 20:52:36 -0000
Received: from post-11.mail.nl.demon.net (HELO post.mail.nl.demon.net)
 (194.159.73.21)
  by locus.apache.org with SMTP; 9 Oct 2000 20:52:36 -0000
Received: from [212.238.62.45] (helo=hellraiser1)
	by post.mail.nl.demon.net with smtp (Exim 3.14 #4)
	id 13ijuU-000I7Y-00
	for struts-dev@jakarta.apache.org; Mon, 09 Oct 2000 20:52:34 +0000
Message-ID: <003501c03232$c7115790$2d3eeed4@hellraiser1>
From: "Ate Douma" <ate@iwise1.demon.nl>
To: <struts-dev@jakarta.apache.org>
References: <2D90C2075E27D4118960000629A832E5CE93FA@scooby.corp.bspark.com>
 <02c901c0321c$395d41e0$c201a8c0@kiwi>
Subject: Re: checkboxes
Date: Mon, 9 Oct 2000 22:52:03 +0200
Organization: iWise BV
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

Aside from generic solutions handled by the action form bean another
solution can be used from the checkbox definition itself.
We use an adapted checkbox tag which logically renders something like:

    <input name="aCheckbox" id="aCheckboxId" type="hidden" value="<%=
bean.getACheckbox() %>" >
    <input type="checkbox" value="true" <%= bean.aCheckbox() ? "checked" :
"" %> onClick="if (this.checked) aCheckboxId.value='true'; else
aCheckboxId.value='false';">

This effectively makes sure a value is submitted even for a checkbox with
value false as not the checbox itself but a extra hidden input item is used
to submit its value.
No need for special handling by the action form bean.

Ate

----- Original Message -----
From: "Chris Miller" <kiwi@vardus.co.uk>
To: <struts-dev@jakarta.apache.org>
Sent: Monday, October 09, 2000 8:10 PM
Subject: Re: checkboxes


> Colin,
>
> I also submitted a solution that took this approach, and I think someone
> else did at about the same time as well (I'm not sure if that was you?). I
> think their approach had some benefits over mine - I can't remember off
the
> top of my head but it might have been something to do with the indexed
> properties as you mention
> I'm not sure exactly what approach Craig is taking, and perhaps there are
> good reasons for it, but I would agree that if the handling can be made
> transparent (and I don't see why it shouldn't be able to) then that would
be
> a *much* nicer solution.
>
> ----- Original Message -----
> From: "Colin Sampaleanu" <colin@Bspark.com>
> To: <struts-dev@jakarta.apache.org>
> Sent: Monday, October 09, 2000 6:17 PM
> Subject: RE: checkboxes
>
>
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> > > Sent: October 9, 2000 11:43 AM
> > > To: struts-dev@jakarta.apache.org
> > > Subject: Re: checkboxes
> > >
> > > 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.
> >
> > The only problem I have with this is that it requires (essentially
> duplicate
> > in terms of logic) extra code for every form, as opposed to a generic
> > mechanism. I don't know if you saw a suggestion from me (about a month
> ago)
> > to have processActionForm check for a special parameter containing the
> names
> > of attributes which should be considered false if missing. I can upload
> the
> > modification again if needed... The one limitation of that approach is
> that
> > it didn't deal with indexed properties, but it could be extended.
> >
> > Colin
> >
>