> -----Original Message----- > From: Marco Tedone [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 07, 2004 12:04 PM > To: Struts Users Mailing List > Subject: Re: A couple of questions > > > 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.
ActionForms aren't perfect. However, what they buy you in terms of everything else, usually make them well worth it. Where they tend to be a bit of a pain is in trying to model complex object models in one form. One of the things to look at with Struts, or any MVC is not just how they do things.. but what they do with those things. What's built on top of the structure. In the ActionForm case, there's so much else being done, on top of it that it makes it a really nice platform for leveraging code. Action classes are an example. All by themselves they're nice. Add in the struts handling of exceptions, the local and global forwards and being able to use the same action class for one or more mappings... now you have something to leverage. Take for instance our earlier mini-discussion on wizards. My base wizard action is 100 lines of code (nicely formatted, not actual lines). Fully functional as is, for just walking the user through the pages of the wizard. Makes a couple of assumptions: the final page returns done when submit is clicked, and every page has forward name like step1, step2 etc which it builds dynamically. Forward, backward navigation, full validation available if you want it on a page by page basis, courtesy of the ValidatorActionForm. Not bad for 2 hours of work. Final forward should forward to the action class that will actualy do something to the collected data. Since the forwards are dynamic, and in the struts-config, for a different wizard I add a different mapping, and a different set of forwards. Add in an ActionForm inherited from the base WizardActionForm, and voila! whole new wizard. Just change the struts-config file for each new wizard. Each form completely validated, and ready to go without coding anything other then the jsp pages themselves, and the Form bean. You could almost train a web person to develop a complete wizard while you work on the hard part of saving/processing the data if you use Dynamic Forms. But wait, I want to leverage even more! Subclass the action... ovverride the right methods, combine with above.. and now you have wizards that can branch to different pages etc. If you look around you'll find even better examples of how to leverage the basic Action and ActionForm classes, along with the rest of struts that can be extended. That's the true power of struts. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
