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 issue.
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 <[EMAIL PROTECTED]> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> To: Struts Users Mailing List <[EMAIL PROTECTED]> Subject: Re: changing ActionForm to be a Java interfaceHi 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.-- DanCraig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
