struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <>
Subject RE: changing ActionForm to be a Java interface
Date Thu, 16 Jan 2003 03:23:59 GMT
Perhaps you could rename ActionForms to something that conveys its intent a
little better - like:


-----Original Message-----
From: Dan Jacobs []
Sent: Thursday, 16 January 2003 11:18
To: Struts Users Mailing List
Subject: Re: changing ActionForm to be a Java interface

Hi Craig,

Well, I concede that this is not the sort of change to make for the 1.1
release.  But I still think that the underlying problem behind the
chronic misuse of form-beans is that they're described as beans, but
they're not really meant to be beans.  So I do still recommend
revisiting that aspect of the framework design.  What the framework
seems to intend here is a raw-form-data-holder with a little extra
support for validating raw form-data, etc.  What it's providing is a
please-dont-use-all-the-functionality-of-a-java-bean instead, and that's

But come on, this isn't a human factors issue, it's an architecture
issue.  If you imagine the possible causes of chronic and consistent
confusion in traditional building architecture, I'm sure you'll follow
the analogy back again.  I think Struts is a terrific idea, and I'd like
to see it improve.  I'd also like to use more of JPlates functionality
in Struts applications, but JPlates already works much better than JSPs,
so that'll do for now.

Anyway, best of luck with the 1.1 release.
-- Dan

Craig R. McClanahan wrote:

>On Wed, 15 Jan 2003, Dan Jacobs wrote:
>>In effect, by piggy-backing on beans-properties introspection for the
>>sake of convenience, your novice users are lured into thinking that
>>form-beans are beans, but they're really intended to be much more
>>restricted in scope.
>>So, if you were to introduce an interface (say, IActionForm) that more
>>clearly stipulated the intended roles and behavior, and documented the
>>heck out of the default implementation to advise novices not to use the
>>rest of beans capabilities indiscriminately, you might end up with a
>>better framework for all classes of users.
>I wish that documentation of intended roles and behavior, plus more
>documentation, plus talking about it repeatedly on the mailing list, would
>have been enough.  Sadly, that was not my experience during the early
>development of Struts -- too many people were misusing it when ActionForm
>was an interface.
>Sometimes human factors issues have to win out over technical merit in
>making architectural choices.  IMHO, this was -- and still is -- one of
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message