Although you get basic type conversion with the getter/setter methods, it is
not a convincing argument. The price you pay for getting something that is
rather simple, is that 1) you have to always extend ActionForm 2) often use
reflection / PropertyUtils to get the information out.
Wouldn't it be more logical if the ActionForm did the type conversion when
validating rather than the Struts controller? This would be possible if the
interface had separate
String get(String name) and
Object getAttribute(String name)
methods.
Jonas
> -----Original Message-----
> From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 30, 2001 5:32 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bean philosophy
>
>
> I wanted to crank out a prototype of something and
> didn't want to make all of the setter/getter methods
> so I modified PropertyUtils to handle java.util.Map.
> I posted some source, but other people have cleaner OO
> implementation ideas that they have posted. Something
> along this idea is scheduled in the Struts 1.1 To Do
> list.
>
> The thread is:
> "PropertyUtils Enhancement Source Code"
>
> The line blurs a little with web pages because
> everything you get from the client are strings, but
> setters/getters provide type checking and a standard
> way to access methods. Struts does do basic type
> conversions for you so you can have boolean, int,
> double, etc. types set and it will convert the string
> from the request object. So for checkboxes and radio
> buttons I would use boolean and int because I know the
> user can't enter bad data on the form. For a text
> field that requires an int for input the field should
> be a String in case they enter something that isn't an
> int so you can return the value to the web form with
> an error message. Someone else may give a better
> explanation, but I hope this helps some.
>
> David
>
> --- Jonas_Bjvrnerstedt <[EMAIL PROTECTED]> wrote:
> > Having just switched from Perl to Java web
> > development, perhaps I am missing
> > something fundamental. Being new to the forum, I
> > also don't know if this
> > issue has been discussed before.
> >
> > It strikes me as odd that in beans in general and
> > ActionForm beans in
> > particular that properties are set by setXxx and
> > getXxx methods.
> > Spontaneously you would think that a bean should
> > have a get("name") and a
> > set("name", "value") to retreive or save attributes
> > in a Hashtable in the
> > bean.
> >
> > Reusability is one of the nice things about beans.
> > With the current design
> > however, if I want to retreive the properties set in
> > a bean in a reusable
> > way, I have to go the roundabout way of using
> > reflection. My question is: In
> > what sense is a bean more than than a Hashtable?
> >
> > Here is a simple illustration of the problem. A
> > common task I have is to
> > generate an SQL insert statement to save the
> > properties of a bean. I could
> > for each different form have an Action class that
> > goes through all the
> > getter methods to generate the SQL string. To make
> > life simple, I derive all
> > my beans from a class that uses reflection to
> > examine what fields the
> > derived class has, creating the SQL string in the
> > toString method. From what
> > I understand, I could have used PropertyUtils
> > instead.
> >
> > Given that beans work the way they do, this is a
> > reasonable method. But why
> > do things the hard way? Why not let ActionForm
> > implement an interface with
> > only a get(), a set() and an getPropertyNames()
> > method? With a Hashtable,
> > you could also allow the set method to add a
> > property to the bean, something
> > I would find very useful.
> >
> > Perhaps I have spent too much time with Perl, but to
> > me it seems like there
> > is too much structure here. In looking through the
> > literature, I have not
> > found any discussion of this question.
> >
> > Jonas
>
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
>
