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.
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:<CONTROVERSIAL-CLAIM> 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. </CONTROVERSIAL-CLAIM>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 those. Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
