What I had to do is to read the parameter out of the request. If the parameter is there, the value is 'true' and I call the setter to set the value to 'true'. If the parameter does not exist (the request.getParameter(...) returns null) then I call the setter and set the value to 'false'.
On wizard type forms, I have a method which holds the values which were originally used to populate the form. For instance I read an row for the the database, my business delegate hands me a value object. This value object I store in the form bean. Should the user select and I use can use the to 'reset' the form to the original values. Kind regards, -- Marc -----Original Message----- From: Takhar, Sandeep [mailto:[EMAIL PROTECTED] Sent: 21 April 2004 14:29 To: Struts Users Mailing List Subject: RE: Problem with <html:checkbox> I think reset because you may change validation at some point as well. reset -> populate -> validate -> action. sandeep -----Original Message----- From: Guillermo Meyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 21, 2004 8:15 AM To: 'Struts Users Mailing List' Subject: RE: Problem with <html:checkbox> And what happens when you are using a DispatchAction and a session scoped form? If you are in a wizard use case, where you go forwards and backwards in a screen sequence using Dispatch action and session scoped form, if in the first screen you set the checkbox on and then you want to go back and unset it, you should check in the request.getParameter() if it is null to set it to false (according to Rajani's reply), because the ActionForm getter for the boolean property won't be populated. Am I right? Should it be placed in thge reset method of that ActionForm? -----Original Message----- From: Takhar, Sandeep [mailto:[EMAIL PROTECTED] Sent: Miércoles, 21 de Abril de 2004 09:11 a.m. To: Struts Users Mailing List Subject: RE: Problem with <html:checkbox> Hmmm... That is interesting because I was always under the assumption that the setter is never called when there is no value and the only read world use of reset() is to set checkboxes to false? Am I wrong? sandeep -----Original Message----- From: Marc L. Veary [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 21, 2004 4:51 AM To: 'Struts Users Mailing List' Subject: RE: Problem with <html:checkbox> Brilliant. Thanks for the help. Kind regards, -- Marc -----Original Message----- From: Rajani [mailto:[EMAIL PROTECTED] Sent: 21 April 2004 09:43 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: Problem with <html:checkbox> Hi, The problem is, when the checkbox is unchecked, the value passed is null and not false. So in the action class you should check if the form bean checbox property is null...then set it to false explicitly. Regards Rajani -----Original Message----- From: Marc L. Veary [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 21, 2004 1:53 PM To: 'Struts Users Mailing List' Subject: Problem with <html:checkbox> Hi All, I have a JSP with the following: <html:checkbox name="<%=formBean%>" property="regulated" value="true"><bean:message key="product.prompt.regulated"/></html:checkbox> <html:checkbox name="<%=formBean%>" property="certRequired" value="true"><bean:message key="product.prompt.cert_required"/></html:checkbox> The problem is this: The appropriate Form Bean setters are called when setting the checkboxes (i.e. when ticking them), but not with unsetting them and I can't seem to figure out why. The setters/getters in Form Bean take and return 'boolean'. Does anyone have any thoughts on this? Many thanks in advance. Kind regards, -- Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] NOTA DE CONFIDENCIALIDAD Este mensaje (y sus anexos) es confidencial, esta dirigido exclusivamente a las personas direccionadas en el mail y puede contener informacion (i)de propiedad exclusiva de Interbanking S.A. o (ii) amparada por el secreto profesional. Cualquier opinion en el contenido, es exclusiva de su autor y no representa necesariamente la opinion de Interbanking S.A. El acceso no autorizado, uso, reproduccion, o divulgacion esta prohibido. Interbanking S.A no asumira responsabilidad ni obligacion legal alguna por cualquier informacion incorrecta o alterada contenida en este mensaje. Si usted ha recibido este mensaje por error, le rogamos tenga la amabilidad de destruirlo inmediatamente junto con todas las copias del mismo, notificando al remitente. No debera utilizar, revelar, distribuir, imprimir o copiar este mensaje ni ninguna de sus partes si usted no es el destinatario. Muchas gracias. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
