If someone were to do as you suggest, then Struts would not be adding much
to the Servlet specification, namely an HttpServletRequest. If getting
values from a hashtable is all you want, use HttpServletRequest.
HttpServletRequest is generic enough to handle all values, and like Perl,
turns everything into a String. Requests are basically just big hashtables,
and most Java developers want something a bit more specific to the data they
are receiving from the JSP page.
But the point I'm trying to make is that if you really believe what you are
saying, just forgo the entire Struts Form issue, make use of the action
mappings and forwards, and retrieve all your updates from the request
object. Have fun type casting and trying to remember the exact names of the
<input ..> fields. Be careful...one tiny mistake in capitalization or
spelling will mean you are not getting the correct property.
Taylor
----- Original Message -----
From: "Jonas Bjornerstedt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 30, 2001 2:57 PM
Subject: RE: Bean philosophy
> 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/
> >
