struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangeetha Nagarjunan" <>
Subject Re: changing ActionForm to be a Java interface
Date Thu, 16 Jan 2003 12:30:45 GMT

Would you  please tell me where i coudl find sample code for :
validate() method?

Sangeetha Nagarjunan
IT Solutions India Pvt. Ltd.
080 - 6655122 X 2119

                    Dan Jacobs                                                           
                    <djacobs@modelob       To:     Struts Users Mailing List <>
          >             cc:                                        
                                           Subject:     Re: changing ActionForm to be a Java
                    01/16/03 05:47                                                       
                    Please respond                                                       
                    to "Struts Users                                                     
                    Mailing List"                                                        

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

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

View raw message