On Wed, 30 May 2001, Jonas Bjornerstedt wrote:
> 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.
>
Hello Jonas,
I think you've really got two threads of questions here, so let me try to
address them separately.
(1) Why use getXxx and setXxx for properties?
This is a general design pattern called JavaBeans, and you will find it
very commonly implemented. There's a specification that documents these
conventions, available at:
http://java.sun.com/products/javabeans/docs/spec.html
but the basic principles revolve around:
* Information hiding (for example, how do *you* know that a
particular getter method returns a simple property value,
and doesn't do some on-the-fly calculations every time?)
* Introspection (so that development tools can recognize the
design patterns and provide a nice GUI user interface for
creating and connecting beans).
Dynamic properties are a very very very heavily requested feature, and
will undoubtedly be addressed early in the Struts 1.1 development
cycle. Supporting them elegantly is more than just a couple of tweaks
here and there, so we want to make sure that we've got all the bases
covered with our design.
In the mean time, though, you'll see the JavaBeans naming patterns used
almost universally in Java programming, so it's well worth your time to
learn them and start using them.
(2) Why ActionForm versus just ordinary beans?
This is a deliberate and fundamental design decision that I made when
first designing Struts. The short answer is that, IMHO, form beans are
part of the View layer in an MVC architecture, not the Model layer. This
is based on the following principles:
* When the user enters invalid data, the application needs to be
able to redisplay what the user last entered (even if it was wrong),
along with the error messages, so that the user doesn't have to
retype everything again. Would *you* ever use a web application
that didn't have this property?
* In order to do this in a web application, there needs to be some
representation of the current input state from the user's last form
submit (again, even if it's wrong). So it doesn't make sense to try
to use the "real" JavaBeans that actually represent your data. Consider
an integer field, where the user typed in "1A3" instead of "123". If
you're using a "real" data object, you get an input conversion error --
and NO WAY to reproduce what the last input again. You need a separate
object anyway.
* In addition, Struts supports the optional concept of calling a
validate() method for you. Thus, there needed to be some Java API
for form beans anyway -- either an interface or a class -- so that
the controller servlet can recognize when to do it. Originally
ActionForm was an interface, but that made every Struts application
fragile in the face of later enhancements -- adding a new public
method to the ActionForm interface would break every single existing
form bean in every single Struts based application, and that would not
be very popular :-). Therefore, we use a base class instead.
* You can, of course, use the underlying BeanUtils.populate() method
yourself to populate any arbitrary object. It's just that Struts won't
give you the other automatic support it does for ActionForm beans.
> Jonas
>
Craig McClanahan
> > -----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/
> >
>
>
