I still do not see why putting your VO on your action form is a bad thing. 1) It gives you a super-easy way to map strings (bean.propName) 2) It gives you an easy way to perform string->type conversions 3) It does not couple your VO to your form 4) While it does couple your form to your VO, who cares? 5) When your Action gets the form, it also has the VO, with strongly typed and named values ready to go to the business tier.
So, what is the down side? Larry On 7/12/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > I would say no, it's no more acceptable (acceptable being a relative term > of course!). > > An EmployeeVO, presuming that is an object passed form the control layer > to the model layer, still needs to know about something in the view layer, > the ActionForm. Hence, it's not really any better. > > In reply to Rick's original post, I echo the thoughts of others that > passing an ActionForm out of an Action to a delegate is generally a bad > idea, and certainly is not in keeping with the original intent of an > ActionForm, nor in what are generally seen as the best practices of the > time. > > Passing the request is kind of a separate question, but just as > undesirable in my opinion because it ties your model to the presentation > mechanism. What if someone comes along and wants to take your web-based > application and create a Swing front-end for it? > > Another good reason to not pass request around is that your business > delegates become harder to unit test because now you have to deal with > mock request objects, or maybe even a whole mock servlet setup (I've seen > session passed to business delegates too). > > I believe Rick knows when he is breaking the "rules" and consciously > chooses to do so :) That's acceptable because he understands the > consequences and can intelligently make the decision. It's important > though that new developers understand not only what things are frowned > upon, but also WHY they are frowned upon. I can speak from experience > when I say I haven't always followed best practices, sometimes because the > situation warranted, but also sometimes because I didn't understand the > reasoning behind the practices and hence wasn't convinced to follow them. > Best practices are best practices because people tend to agree they have > more benefit than other approaches in most cases, and that is the case > here. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > On Tue, July 12, 2005 12:37 pm, Brady Hegberg said: > > Rick sent the example code below to an user earlier and I was just > > wondering. Would it be acceptable to generate the EmployeeVO using a > > constructor like: > > > > EmployeeVO emp = new EmployeeVO( eForm ); > > > > Would that be considered tying the view to the business layer? It seems > > like it would work nicely especially since you could use polymorphism if > > you needed to generate VOs from other Forms (ie > > AnotherEmployeeActionForm). > > > > Thanks, > > Brady > > > >> //In Action method: > >> execute(...) //or dispatchMethod update(..) { > >> //cast to your ActionForm of String properties > >> EmployeeActionForm eForm = (EmployeeActionForm)form; > >> > >> //business POJO with correct Data types > >> EmployeeVO emp = new EmployeeVO(); > >> > >> //easy to take the stuff from ActionForm to VO > >> BeanUtils.copyProperties( emp, eForm ); > >> > >> //Do the update > >> yourEmployeeDAO.updateEmployee( emp ); > >> } > > > > > > --------------------------------------------------------------------- > > 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]