Shouldn't this be modified to be "all accessed NON-CHECKBOX properties..."? From doing some tests with String properties representing checkbox values, as long as you either default the checkbox value, or it's set to one of "on", "yes", or "true" then you're ok, but should you set the value explicitly:
<html:checkbox property="testCheck" value="testing"/> you will lose if you display the checkbox on a subsequent page, even if you specify the value as "testing", because the logic which decides to emit the "checked" input attribute only looks for "on", "yes", or "true"; anything else is false. Steve > -----Original Message----- > From: James Mitchell [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 28, 2002 8:18 PM > To: Struts Users Mailing List > Subject: RE: Use of custom convertors > > > I think that what Jerome meant is "all accessed > properties"....meaning if > nested or even recursively nested, the same applies. the getXXX() and > setXXX() should always be String. > > James Mitchell > > > -----Original Message----- > > From: Don Saxton [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, May 28, 2002 10:49 PM > > To: Struts Users Mailing List; [EMAIL PROTECTED] > > Subject: Re: Use of custom convertors > > > > > > Actually I don't think that is sufficient. Consider an > object which is a > > recursive tree. > > > > ----- Original Message ----- > > From: "Jerome Jacobsen" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > Sent: Tuesday, May 28, 2002 10:25 AM > > Subject: RE: Use of custom convertors > > > > > > > The "best practice" for form beans is that all properties > be Strings. > > Your > > > Action can do the conversion both ways. For the request > it converts the > > > String to the type expected by the business object. For > the response it > > > converts the business object's type to the String to be > set on the form > > > bean. BeanUtils can be used by the Action to do both types of > > conversion. > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, May 28, 2002 1:10 PM > > > To: Struts Users Mailing List > > > Subject: Re: Use of custom convertors > > > > > > > > > > > > Ok I may be missing something as I am brand new to > struts. Why would we > > not > > > want to use the same mechanism for "getting" properties > as we do for > > > "setting" properties? Why wouldn't the framework determine the > > type of the > > > source and call the appropriate converter in order to create the > > > appropriate string representation for display? > > > > > > Thanks. > > > > > > Keith Nielsen > > > > > > > > > > > > > > > > > > Ted Husted > > > <husted@apach To: Struts Users > > Mailing List > > > <[EMAIL PROTECTED]> > > > e.org> cc: > > > Subject: Re: > Use of custom > > > convertors > > > 05/28/2002 > > > 10:23 AM > > > Please > > > respond to > > > "Struts Users > > > Mailing List" > > > > > > > > > > > > > > > > > > > > > Personally, I'd do the conversions in the JavaBean and > leave the tags > > > out of it. > > > > > > -- Ted Husted, Husted dot Com, Fairport NY US > > > -- Developing Java Web Applications with Struts > > > -- Tel: +1 585 737-3463 > > > -- Web: http://husted.com/about/services > > > > > > [EMAIL PROTECTED] wrote: > > > > > > > > I am writing custom converters which BeanUtils will use to do > > conversions > > > > from request data to form bean. It appears however that > on the return > > > path > > > > that none of the tags actually use BeanUtils, and as > such my converter > > is > > > > only used in one direction. Is my understanding of this > correct? If so > > > how > > > > do I avoid having to rip apart my nested beans in order > to get right > > > > conversions on the subsequent generation of the next page. > > > > > > > > Thanks. > > > > > > > > Keith > > > > > > > > -- > > > > To unsubscribe, e-mail: < > > > mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: < > > > mailto:[EMAIL PROTECTED]> > > > > > > -- > > > To unsubscribe, e-mail: < > > > mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: < > > > mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
