Ah well now, its funny you should be mentioning that. As it happens Old Mc Andrew did once have a method to set the field with a boolean, but changed it to take a string instead as he is quite set in his ways and has never liked booleans (as he learnt from a young age that providing a certain true or false answer instead of 'maybe' tends to create a few too many expectations in folk not wise to the ways of software development...).
He has looked at his ActionForm code to try and determine is there is a second setter somewhere (he even looked behind the grassyKnoll() method) but found nothing. Old McAndrew has been known to occasionally miss things that are right under his nose however, and will continue to look. There ARE however multiple getter methods, or to be precise there is a method getHeaderTransform() and an isHeaderTransform() the latter of the two returning a boolean. (The other similar fields also have these but they still work.) -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 18, 2002 14:05 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: Arrgh!!! my property has been cursed and my bean doesnt like the field on my farm , uhh form I mean On Thu, 18 Jul 2002, Andrew Hill wrote: > Date: Thu, 18 Jul 2002 13:23:02 +0800 > From: Andrew Hill <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: Arrgh!!! my property has been cursed and my bean doesnt like > the field on my farm , uhh form I mean > > Or to be a little bit more specific... > > Old Mc Andrew had a form > and on that form he had a field > with the name "headerTransformation" > but naughty Mr Struts simply would NOT call the method > setHeaderTransformation in his ActionForm > even though it had not been a problem yesterday! > I hope old McAndrew isn't trying to have his cake and eat it too, by having more than one mistress, err, setHeaderTransformation() method that takes a different type of argument :-). Such things violate the JavaBeans specification's design patterns, and will cause the JVM to think your property doesn't have any setter method at all. > No matter what Andrew looked at everything still seemed fine but it just > > didnt work! > He tried changing the field from a checkbox to a boring old text field > He tried dumping the request parameters to see if anything was dodgy there > - maybe multiple values were being submitted for that property? > but no - it all checked out ok, no matter where he looked. > Poor Andrew was getting VERY alarmed. > > Then he had a clever idea! > He changed the name of the field on his html form to "headerTransformationx" > , > he also added a second setter named setHeaderTransformationx to his > actionform and then tried again. > Amazing! This time it worked! > Mr Struts went right ahead and called the setHeaderTransformationx method. > Andrew couldnt believe his eyes. > Makes it even more likely that old McAndrew is trying to double dip :-). After all, a property named "headerTransformationx" is completely naive and innocent about the existence of any property named "headerTransformation". > Just to test he renamed the field back to "headerTransformation" > and sure enough nasty Mr Struts gave it the cold shoulder again. > > Now Andrew is very confused. He hasnt the slightest clue why a parameter > named > "headerTransformation" is completely ignored by Mr Struts, while a parameter > named "headerTransformationx" is welcomed with open arms! > > Well boys and girls, perhaps you can help poor Andrew with his problem? > Can anyone give him a reason why silly Mr Struts has a bad attitude towards > his fieldnames? > Mr. Struts is like Miss Manners -- he frowns on trying to have serious relationships with two property setters at the same time :-). > > <details> > Ive looked at the request parameters (dumping them from processPopulate() in > the request processor just before the form is populated. > headerTransformation=xxx is in there alright, and its not multiple values. > So it fine there, > but the setter in the actionForm is not getting called. > > The code in my actionform is: > > public void setHeaderTransformationx(String value) > { > System.out.println("Setting headerTransformationx to " + value); > _headerTransformation = value; > } > > public void setHeaderTransformation(String value) > { > System.out.println("Setting headerTransformation to " + value); > _headerTransformation = value; > } > > public String getHeaderTransformation() > { > return _headerTransformation; > } > > I also set _headerTransformation to null in the reset() method (it used to > be a checkbox before I started trying to diagnose the problem). > > And my html form has a field with the code: > > <input type="text" name="headerTransformationx" > onchange="submitWithMethod('update');"/> > (or > <input type="text" name="headerTransformation" > onchange="submitWithMethod('update');"/> > depending on which of the two setters Im testing) > > When I use the headerTransformationx name it works, but headerTransformation > does not. > > I have several other fields on the form that are specified in an almost > identical manner , the only difference being their name, and they all work > sweet. > Well, Mr. Struts may be perverse, but at least he is *consistently* perverse :-). > Very confused :-( > </detail> Please check for having more than one setter method with the same name but different argument types. That is the 99.9%-of-the-time cause for this sort of difficulties. Craig -- 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]>
