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 12:17:14 GMT
Hi Craig,

Based on the oft misunderstood property of contravariance, I *do* 
conclude that form-beans should not be subtyped from Java Beans, for the 
reason that subtypes are never supposed to have fewer behaviors than 
their supertypes.  It's customary in good object-oriented design to use 
delegation rather than subclassing to use only a selected subset of 
behaviors from another kind of thing.  If Struts is saying that a 
form-bean should never act like a bean in such-and-such manners, then it 
follows that form-beans should not be beans.  This *is* an architecture 

I don't dispute the popularity of Struts, and I congratulate you on 
that.  But that's not grounds for justifying any and every aspect of its 
implementation approaches.  Windows 98 was popular too.  I think most of 
Struts is very well done, and I also think there's this specific problem 
with form-beans, long indicated by the persistent and ongoing level of 
misunderstanding surrounding them.

As for the beans introspector, you can still use that in your 
implementation if you want to go that route, and you can additionally 
ignore non-String beans properties, or any of a number of things like 
that to rein in misuse.  But as long as you call form-beans java-beans 
but intend somethimg more restrictive, there will be confusion.

A similar situation I ran into recently was one where a client 
implemented a ClassLoader solely for the purpose of being able to locate 
resources using a directory path.  But it wasn't actually able to load 
classes.  It was probably convenient to implement it as a subclass in 
order to inherit certain methods directly, but that didn't help when the 
next person actually attempted to use the thing as ClassLoader.

-- Dan

Craig R. McClanahan wrote:

>On Wed, 15 Jan 2003, Dan Jacobs wrote:
>>Date: Wed, 15 Jan 2003 22:18:09 -0500
>>From: Dan Jacobs <>
>>Reply-To: Struts Users Mailing List <>
>>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
>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
>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
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

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