You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Andrew Hill <an...@gridnode.com> on 2002/07/18 07:23:02 UTC
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!
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.
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?
<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.
Very confused :-(
</detail>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Arrgh!!! my property has been cursed and my bean doesnt like the field on my farm , uhh form I mean
Posted by Mark Nichols <st...@partitionsoftware.com>.
+1
</mark>
> -----Original Message-----
> From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
> Sent: Saturday, July 20, 2002 5:36 AM
> To: Struts Users Mailing List
> Subject: RE: Arrgh!!! my property has been cursed and my bean doesnt
> like the field on my farm , uhh form I mean
>
>
> Old McAndrew put down the chainsaw and wiped the sweat from his brow.
> It had been a hard ten minutes work, but his bean fields were now clear of
> illegal
> getters.
>
> Had it been anyone other than old man McClanahan he would have
> given them a
> good
> scolding for talking such obvious nonsense. "Cant grow extra
> getters indeed!
> Whos going to know anyway!".
>
> Indeed he hadnt heard such nonsense since some young upstart
> named Bill had
> come out from the city
> talking about using .nets as though he was some kind of fisherman!
>
> But he knew that Mc Clanahan had been around long enough to know
> what he was
> talking
> about and had decided to give his advice a go. Nevertheless it was with
> somewhat of a cynical eye
> that he looked over his bean fields before retiring for the night.
>
> Next morning old Mc Andrew got up and went to see how his fields were
> getting() along.
> "Well b***** me with a barge pole!" he exclaimed. "That McClanahan fellow
> was right after all!".
> Yep. Sure enough, his setHeaderTransformation() field was being called!
>
> cheers Craig!
>
> -Andrew
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Friday, July 19, 2002 00:20
> To: Struts Users Mailing List; andrew.david.hill@gridnode.com
> 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 14:29:22 +0800
> > From: Andrew Hill <an...@gridnode.com>
> > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> > andrew.david.hill@gridnode.com
> > To: Struts Users Mailing List <st...@jakarta.apache.org>
> > Subject: RE: Arrgh!!! my property has been cursed and my bean doesnt
> > like the field on my farm , uhh form I mean
> >
> > 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.)
> >
>
> Despite their protestations to the contrary, having two getters like this
> is also a violation of the rules (the JavaBeans rules, that is). It would
> also be improper to have a getter that returns one type, and a setter that
> accepts a different one.
>
> "So where are these rules?" you might ask. "How can I avoid such faux pas
> in the future?"
>
> http://java.sun.com/products/javabeans/
>
> has a link that gets you to the JavaBeans specification, which includes a
> whole chapter on how well mannered JavaBeans properties expose themselves
> to the world.
>
> Craig
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: Thursday, July 18, 2002 14:05
> > To: Struts Users Mailing List; andrew.david.hill@gridnode.com
> > 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 <an...@gridnode.com>
> > > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> > > andrew.david.hill@gridnode.com
> > > To: Struts Users Mailing List <st...@jakarta.apache.org>
> > > 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:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Arrgh!!! my property has been cursed and my bean doesnt like the field on my farm , uhh form I mean
Posted by Andrew Hill <an...@gridnode.com>.
Old McAndrew put down the chainsaw and wiped the sweat from his brow.
It had been a hard ten minutes work, but his bean fields were now clear of
illegal
getters.
Had it been anyone other than old man McClanahan he would have given them a
good
scolding for talking such obvious nonsense. "Cant grow extra getters indeed!
Whos going to know anyway!".
Indeed he hadnt heard such nonsense since some young upstart named Bill had
come out from the city
talking about using .nets as though he was some kind of fisherman!
But he knew that Mc Clanahan had been around long enough to know what he was
talking
about and had decided to give his advice a go. Nevertheless it was with
somewhat of a cynical eye
that he looked over his bean fields before retiring for the night.
Next morning old Mc Andrew got up and went to see how his fields were
getting() along.
"Well b***** me with a barge pole!" he exclaimed. "That McClanahan fellow
was right after all!".
Yep. Sure enough, his setHeaderTransformation() field was being called!
cheers Craig!
-Andrew
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Friday, July 19, 2002 00:20
To: Struts Users Mailing List; andrew.david.hill@gridnode.com
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 14:29:22 +0800
> From: Andrew Hill <an...@gridnode.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> andrew.david.hill@gridnode.com
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: RE: Arrgh!!! my property has been cursed and my bean doesnt
> like the field on my farm , uhh form I mean
>
> 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.)
>
Despite their protestations to the contrary, having two getters like this
is also a violation of the rules (the JavaBeans rules, that is). It would
also be improper to have a getter that returns one type, and a setter that
accepts a different one.
"So where are these rules?" you might ask. "How can I avoid such faux pas
in the future?"
http://java.sun.com/products/javabeans/
has a link that gets you to the JavaBeans specification, which includes a
whole chapter on how well mannered JavaBeans properties expose themselves
to the world.
Craig
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Thursday, July 18, 2002 14:05
> To: Struts Users Mailing List; andrew.david.hill@gridnode.com
> 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 <an...@gridnode.com>
> > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> > andrew.david.hill@gridnode.com
> > To: Struts Users Mailing List <st...@jakarta.apache.org>
> > 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Arrgh!!! my property has been cursed and my bean doesnt like
the field on my farm , uhh form I mean
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 18 Jul 2002, Andrew Hill wrote:
> Date: Thu, 18 Jul 2002 14:29:22 +0800
> From: Andrew Hill <an...@gridnode.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> andrew.david.hill@gridnode.com
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: RE: Arrgh!!! my property has been cursed and my bean doesnt
> like the field on my farm , uhh form I mean
>
> 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.)
>
Despite their protestations to the contrary, having two getters like this
is also a violation of the rules (the JavaBeans rules, that is). It would
also be improper to have a getter that returns one type, and a setter that
accepts a different one.
"So where are these rules?" you might ask. "How can I avoid such faux pas
in the future?"
http://java.sun.com/products/javabeans/
has a link that gets you to the JavaBeans specification, which includes a
whole chapter on how well mannered JavaBeans properties expose themselves
to the world.
Craig
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Thursday, July 18, 2002 14:05
> To: Struts Users Mailing List; andrew.david.hill@gridnode.com
> 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 <an...@gridnode.com>
> > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> > andrew.david.hill@gridnode.com
> > To: Struts Users Mailing List <st...@jakarta.apache.org>
> > 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Arrgh!!! my property has been cursed and my bean doesnt like the field on my farm , uhh form I mean
Posted by Andrew Hill <an...@gridnode.com>.
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:craigmcc@apache.org]
Sent: Thursday, July 18, 2002 14:05
To: Struts Users Mailing List; andrew.david.hill@gridnode.com
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 <an...@gridnode.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> andrew.david.hill@gridnode.com
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Arrgh!!! my property has been cursed and my bean doesnt like
the field on my farm , uhh form I mean
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 18 Jul 2002, Andrew Hill wrote:
> Date: Thu, 18 Jul 2002 13:23:02 +0800
> From: Andrew Hill <an...@gridnode.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> andrew.david.hill@gridnode.com
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Arrgh!!! my property has been cursed and my bean doesnt like the field on my farm , uhh form I mean
Posted by Andrew Hill <an...@gridnode.com>.
Sigh. Still no closer to figuring it out!
Did find a problem in my code to output all the parameters of a request,
fixed it, but it didnt help me pin down the problem. :-(
Ive resorted to adding code to the effect of:
form.setHeaderTransformation( request.getParameter("headerTransformation" );
to my action, which allows me to continue working for now, but I would
really like to know what the actual problem is.
-----Original Message-----
From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
Sent: Thursday, July 18, 2002 13:23
To: Struts Users Mailing List
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!
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.
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?
<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.
Very confused :-(
</detail>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>