struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: changing ActionForm to be a Java interface
Date Thu, 16 Jan 2003 06:42:14 GMT


On Wed, 15 Jan 2003, Dan Jacobs wrote:

> Date: Wed, 15 Jan 2003 22:18:09 -0500
> From: Dan Jacobs <djacobs@modelobjects.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> 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
> confusing.
>

Just out of curiousity, how do you conclude that an ActionForm not a
JavaBean?  It follows all the requirements of the JavaBeans spec (it's a
*class*, not an interface; zero-args constructor; naming patterns for the
getters and setters; support for BeanInfo overrides if you really want to
use different method names).  In fact, standard form beans wouldn't work
at all if the implementation class's bean properties could not be
introspected correctly by javax.beans.Introspector.
                                ^^^^^

> But come on, this isn't a human factors issue, it's an architecture
> issue.

Good luck succeeding with that attitude :-).  After being a key player in
the two most successful (measured in users) projects at Jakarta -- Struts
and Tomcat -- I can confidently assert that almost *everything* important
about a successful software project is a human factors issue.
Architectural purity is a primary concern only for architects (which is
obviously why you care about this).

>  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.
>

A couple of million downloads since its inception says we didn't do half
bad on the architecture of Struts -- at least from a user perspective :-).

> Anyway, best of luck with the 1.1 release.

Thanks ... and good luck with JPlates as well.

> -- Dan

Craig


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message