A word of caution about the BeanUtils.populate() approach -- which, of
course, is what Struts does to populate form beans already ...
One thing you'll see me harp about in the mailing list archives :-) is a
particular feature of the way Struts handles invalid input - for example,
an integer field, rendered as a text entry box, where the user types "1a3"
instead of "123". My contention is that the webapp should redisplay the
page, with an appropriate error message of some type, and the input field
should be redisplayed exactly as the user typed it ("1a3") for repair.
That's the way GUI programs work, and that's the way webapps should work.
In Struts, you make this possible by using String properties in the form
bean for such fields, and do the conversions later (perhaps in the Action,
via a call to something like BeanUtils.copyProperties() from the form
bean into your model bean that does the required conversions -- but you
know they are going to work).
You might also want to take a look at the way WebWorks (on SourceForge)
deals with this whole problem area. They've essentially combined the form
bean and action into a single class, so their version of populate is
calling property setters on the Action itself, rather than having to pass
in a form bean. An advantage of this approach is that their action
class is more easily unit testable outside of a servlet container, because
it doesn't pass in the request and response. A disadvantage (at least
last time I looked at it) is that you can't use headers or cookies from
the request unless you've made provisions to have property setters for
them. (Rickard's a very smart guy -- I would have been tempted to do
things this way if I'd thought of it first :-).
Craig
On Thu, 15 Aug 2002, Joe Cheng wrote:
> Date: Thu, 15 Aug 2002 18:02:25 -0400
> From: Joe Cheng <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: concerns about Struts
>
> Ted,
>
> >> The source for the framework actions and objects I use are available in
> the Scaffold packages. There is a core Scaffold package that was just
> posted to the Commons sandbox and a Struts-specific companion in the
> contrib folder. If anyone is interested, see <http://husted.com/struts>
> for the links. <<
>
> Thanks. Very interesting stuff.
>
> I'm trying to absorb a lot very quickly, so please bear with me... but it
> looks like what you're talking about hinges on a ProcessBean paradigm where
> you call mybean.execute(Object), which first calls BeanUtils.populate() to
> parse/pass Object to its own setters. After that, the rest of the execute
> method does whatever business logic it needs to.
>
> I have to admit, I have mixed feelings about this model. On the one hand,
> you basically lose strong typing to some degree, because you won't know of
> any clashes until the BeanUtils.populate() call. On the other hand, if
> typing conflicts never happen then you've saved yourself quite a lot of
> coding.
>
> I'll have to think on this some more, and maybe build a couple of quick
> Struts/Scaffold sites of my own.
>
> Still interested to hear any more thoughts you might have. Especially on
> the importance of compile-time checking (or whatever you want to call
> "finding as many structural errors as possible before runtime").
>
> Thanks,
>
> -jmc
>
> --
> 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]>
