I am trying to use overloaded methods because I am looping through XML to populate forms. I don't always know exactly which elements will be returned, so I have a "map" of the possible elements that can be returned which points to the proper property of the Form. I then use PropertyUtils.setNestedProperty() to populate my Form.
I was not up to speed on the conversion utilities when I started this project, so I created a DateForm. This DateForm is nested into almost all of my other Forms. So, when I am looping through the XML and I happen upon a date, I want to do setDateProperty(String) instead of setDateProperty(DateForm). I will start looking at the problem again on Thursday. Craig, thank you for clearing this up! Carl -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 24, 2002 1:26 PM To: Struts Developers List Subject: RE: Overloaded Setters in Form On Tue, 24 Dec 2002, Carl Fyffe wrote: > Date: Tue, 24 Dec 2002 13:12:48 -0500 > From: Carl Fyffe <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: 'Struts Developers List' <[EMAIL PROTECTED]> > Subject: RE: Overloaded Setters in Form > > Edgar does have a point, the spec doesn't say beans *bad joke* about > overloading. It actually does, but by omission, not comission :-). See below. > I gave it another go after reading (AGAIN) Craig's first post on this > topic (12/14/2002) and this time, instead of using a null getter, I > provided a getter for the overloaded setter. Still does not work. > Introspector only returns one PropertyDescriptor for the property. > Edgar and Craig both lead me to believe that this is possible, but I > am starting to think that I am trying to put a square peg in a round > hole. > Please give up now :-). Consider the fact that trying to create overloaded setters will actually compile: public void setProp(Foo foo) { ... } public void setProp(Bar bar) { ... } (even though Java won't recognize "prop" as a valid JavaBeans property), but trying to create overloaded getters will give you a compile error: public Foo getProp() { ... } public Bar getProp() { ... } The bottom line is that the design pattern for JavaBeans properties talks about a getter *method* (singular) and/or a setter *method* (singular) with no mention of *methods* (plural) in either scenario. This is also reflected in the introspection APIs -- consider for example the following methods on java.beans.PropertyDescriptor (which is what beanutils is using under the covers to call the getter and setter dynamically): public Method getReadMethod(); public Method getWriteMethod(); Even assuming you tried to create a write-only property with just the two set methods, there is no reaonable rule for Java to choose which one to return via getWriteMethod(). So, the language punts and decides that you have not defined a property at all. > Edgar: Would you be willing to share some of your implementation > details? > > Architectural Gurus: The problem I am trying to solve is that I have a > data source that returns Strings only (xml file), should I create > Beans specifically for that data source and then convert over to my > Form? > ActionForm beans should generally use String properties for anything that is going to be updatable (by the user) via a text input field. What kind of conversion do you need to do? (Or, more broadly, why are you trying to use overloaded property methods in the first place?) > Thanks for all of your help, > > Carl 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]>
