Craig, that was the most excellent explanation. What currently IS available
for use regarding the automatic properties, and how may I use them? I
download the nightly builds ;^>
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, May 30, 2001 4:14 PM
Subject: RE: Bean philosophy
>
>
> 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/
> > >
> >
> >
>
