Hello Dave, > you can trivially avoid unnecessary prepare calls.
How can I avoid unnecessary prepare calls? I mean how can I avoid the prepare method won't be called if there are not validation errors. Thanks in advance Alfredo Osorio -----Mensaje original----- De: Dave Newton [mailto:davelnew...@gmail.com] Enviado el: Monday, November 08, 2010 1:30 PM Para: Struts Users Mailing List Asunto: Re: RE: Have you ever used InputConfig annotation? And I'm saying #1 that a testable action is worth a lot and #2 you can trivially avoid unnecessary prepare calls. Dave On Nov 8, 2010 1:54 PM, "Alfredo Manuel Osorio Martinez" < alfredo.oso...@afirme.com> wrote: > Hello Dave and thanks for your response, > > I think I didn't explain myself what I tried to say is whenever you > submit to the action that will process the input data that action's > prepare (or prepareXXX) needs to know how to populate the data needed > for the input result and that's because if validation fails the result > will be the input result (where the data came from) and needs that data > for the repopulation of some controls (list, etc). So whether the > validation passed or failed that logic is always called. So is that the > price you have to pay for a cleaner testable action? My point is the > overhead of calling that method (prepare) for input repopulation even > though sometimes (successful validation) you won't need it. > > Thanks > > Alfredo Osorio > > -----Mensaje original----- > De: Dave Newton [mailto:davelnew...@gmail.com] > Enviado el: Monday, November 08, 2010 10:47 AM > Para: Struts Users Mailing List > Asunto: Re: Have you ever used InputConfig annotation? > > On Mon, Nov 8, 2010 at 10:07 AM, Alfredo Manuel Osorio Martinez wrote: >> Are you saying that input methods shouldn't have any logic in and just >> return the string of the result. If that's the case where should you >> retrieve those list values? What other alternatives do I have? The > only >> other one that comes to my mind is Preparable and action tag. > > Preparable; I have issues with using <s:action> tag for that as well; > it puts too much responsibility into the view layer, and means you > *must* integration-test the entire flow, including page rendering, in > order to know if the action works, rather than testing the action in > isolation. > > My acid test for determining what's appropriate in a method: > > Pass: > > Q: What does getInputResultNameDo? > A: Returns the name of the input result. > > Fail: > > Q: What does getInputResultNameDo? > A: It gets the name to use for the input result. And goes to the > database, retrieves a bunch of values, handles persistence-layer > Texceptions, and may populate error messages to return to the user. > >> So in the cases where the validation is going to be >> successful why would you want to retrieve the input lists values or >> other stuff for the input result if you are not even going to use it. >> Isn't that unnecessary overhead? > > Don't submit to the same action. Or use prepare{methodName}. Or take > advantage of it being a MethodFilterInterceptor and configure it to > run only for the methods you want. Or extend it to default to your > desired application-specific behavior. Or... > > Dave > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org