struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Newton <davelnew...@gmail.com>
Subject Re: RE: Have you ever used InputConfig annotation?
Date Mon, 08 Nov 2010 19:30:15 GMT
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.osorio@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:davelnewton@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message