struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alfredo Manuel Osorio Martinez" <>
Subject RE: Have you ever used InputConfig annotation?
Date Mon, 08 Nov 2010 18:54:45 GMT
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.


Alfredo Osorio

-----Mensaje original-----
De: Dave Newton [] 
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
> 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

My acid test for determining what's appropriate in a method:


Q: What does getInputResultNameDo?
A: Returns the name of the input result.


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...


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message