Thank you for your emails. I feel I've got a better understanding of the reasons behind ActionForms. Don't misunderstand me. I want to choose the best solution, not to convince you that ActionForms are wrong. I'm starting a new project from scratch, the company is investing in people with Struts knowledge, I want to be sure to obtain the best from this framework (and any other frameworks we're using). Your experience and testimoniance has been really usefull.
Marco ----- Original Message ----- From: "Jim Barrows" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, September 07, 2004 7:15 PM Subject: RE: A couple of questions > -----Original Message----- > From: Marco Tedone [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 07, 2004 10:51 AM > To: Struts Users Mailing List > Subject: Re: A couple of questions > > > > >Not really... your way you have to add the code to the > action to do the > validation and extraction as well as the JSP, model and SQL. > > Model and SQL is not necessarily (and often) true: if I used > course grained > strategy, it may be that I've already got the field in my > model, and if I > use CMP EJB, I don't have to touch the SQL, because what it > is returned to > me is a local interface reference, rather than a ResultSet. And if I > designed carefully my EJBs, and the field is already in the > database, I > wouldn't change a comma of my business model. So, resuming: I > need another > field in my presentation view (supposed I've got it already > in my business > model...): I add it to the JSP page, check it with Javascript, add its > management to the servlet and I'm done. With Struts Actions: > I add a field > to the JSP, to the form object, dynamic or not (in case of an > Action object > getter/setter, reset() and validate() method), to the > validation framework, > to the Action (for its management)... Okay... ActionForm way Your Way 1)Add it to jsp form ditto 2)Add it to Form Object No 3)Add it to validation.xml Write validation for both JS _and_ server side. (JS and server side validation done) 4)Treat it as object immediately, Write and maintain all the conversion stuff yourself. and use other peoples code to This includes all the parsing etc by hand. transfer the Strings to VO. So, yeah I get to add an extra field to my form class. right click and tell eclipse to generate the getter/setters for it. OMG, that's hard. You on the other hand get to write lots more code then I do to accomplish the same task. Now if you never validate your code, and never have to worry about a user entering text when they should be entering numbers, then your way is definitily easier. BUT if you have to make a field required, ActionFormas are easier. If you have to make sure that it's a float, ActionForm is easier. If you have to do both... hands down, ActionForms are easier. Anecdotal: I have a little DyanForm I use for links, where sometimes I want to show everything, sometimes I want to show just a summary. Typically this link looks like <html:link aciont="showData?detail=Summary">Link</html:link>. With the action form I validate this like this: <form name="DetailForm"> <field property="detail" depends="required,mask"> <arg0 key="DetailForm.detail" /> <var> <var-name>mask</var-name> <var-value>(^full$)|(^summary$)</var-value> </var> </field> </form> Now this is a silly example, except that I can use DetailForm for as many actions as I want, with no changes. Oh.. wait... now I want to add page ranges! <form name="DetailForm"> <field property="detail" depends="required,mask"> <arg0 key="DetailForm.detail" /> <var> <var-name>mask</var-name> <var-value>(^full$)|(^summary$)</var-value> </var> </field> <field property="startpage" depends="int"> <arg0 key="DetailForm.startPage"/> </field> <field property="startpage" depends="int"> <arg0 key="DetailForm.endPage"/> </field> </form> Now, I've just moderately protected myself from some idget trying to tinker with the links to some degree. I could also make sure they were all positive numbers etc. I could even rather easily say that the page ranges are only valid for full, and not summary detail pages. The question again is.... what would you rather do... code what I just did by hand for every action where you have summar/full options? or cobble up a quick configuration bit? Which is going to get more usage? I copy and paste the above between customers a lot. > > > The ActionForm way. I >change the JSP, the Form, The model > and the SQL. If > I'm using Dyna Forms then the only code I touch is the VO. > Everything else > is handled in config files. If >I'm using Hibernate then I > only have to > worry about the field being in the database. > > >Which would you rather maintain, 1-20 lines of code , or 2-3 > config files? > > I can't see how my solution could lead to 20 lines of code > against 2-3 > config files? Validation. Transferring the strings to their VO counterparts. Try/catch blocks for each field if you want to show all the errors at once. Struts validation allows me to validate the whole form at once, rather then one field at a time. With no extra coding. Just a configuration file. Add in javascript on top of that. Making sure the JS is cross browser... All of which the ActionForm gives you for free. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
