struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Jacobs <>
Subject Re: changing ActionForm to be a Java interface
Date Thu, 16 Jan 2003 03:18:09 GMT
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: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message