The logic validate method is so closely coupled with the form-bean properties that it wouldn't help to look at a sample. What I do in form-bean-X's validate() is nothing like the validate() for form-bean-Y. If you still want to look at sample code you should be able to find it in the sample applications that ship with Struts as Mark pointed out.
Also, please create a new thread when asking a new question. Not only is it impolite to piggy-back on an existing thread you are more likely to get responses with a new thread with an appropriately titled subject line. Sri -----Original Message----- From: Sangeetha Nagarjunan [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 7:31 AM To: Struts Users Mailing List Subject: Re: changing ActionForm to be a Java interface Hi, Would you please tell me where i coudl find sample code for : validate() method? Thanks Regards Sangeetha Nagarjunan IT Solutions India Pvt. Ltd. Bangalore 080 - 6655122 X 2119 Dan Jacobs <djacobs@modelob To: Struts Users Mailing List <[EMAIL PROTECTED]> jects.com> cc: Subject: Re: changing ActionForm to be a Java interface 01/16/03 05:47 PM 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 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 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:[EMAIL PROTECTED]> >For additional commands, e-mail: < mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
