struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: Would like more flexibility in Result
Date Sat, 29 Dec 2007 05:34:03 GMT
Adam Hardy wrote:
> Brian Pontarelli on 28/12/07 18:12, wrote:
>>> In an ideal world I would be happiest to retrieve dropdown lists in 
>>> my Actions, but there is a clear separation between the Actions and 
>>> the JSPs, whose dropdown list requirements don't map one-to-one to 
>>> the Actions.
>>> So I turned to Results to achieve my goal, and it's OK as it is, 
>>> inheriting from TilesResult, but it's cludgey.
>> You can certainly do it that way, I just don't think that Result is a 
>> place for business /model logic. Results are used for the resolution 
>> of the view, which is a bridge between the controller and the view.
>> The model logically belongs elsewhere with MVC 2. In either case, you 
>> have controller/view code calling out to model code. The logic for 
>> the model should be located either in actions or hopefully a services 
>> layer with a little bit of action code for glue. In my case, I'm 
>> placing a call to the business logic it in the JSP (view code). In 
>> your case it is in the Result (controller/view code). In either case, 
>> the logic should be elsewhere and just called from the View or Result.
>> Therefore, I don't think it is a violation because it is still the 
>> business logic is in a separate location without any logic directly 
>> in the JSPs. The logic resides in the model/service layer and the 
>> coupling is very loose. Rails does it this way as do a number of 
>> other frameworks. I also use this method for form preparation instead 
>> of using the Preparable interface or other methods. This seems more 
>> accurate because the form is only prepared when it is displayed.
>> Lastly, unless the Results are modified for chaining or the like, 
>> you'll have a hard time having multiple usages like this in a single 
>> result. My solution allows me to invoke any action from the view and 
>> have the logic executed in a different layer and the results 
>> available in the JSP. This is very reusable in my opinion and much 
>> simpler to code with less configuration. Plus, I could wrap that all 
>> in a .tag file and make it even simpler to reuse. The other solutions 
>> seem to require a decent amount of more work.
> Well I guess I differ from you then in that I would hesitate before 
> allowing anyone on my project to call actions from the JSPs. 
> Admittedly it looks really easy.
This could be very philosophical debate about code hiding and 
protection. But I'll make it simple and just say that I believe that 
Actions are meant to be invoked by anyone. The world will be invoking 
them from a browser or AJAX and they can monkey around with HTTP 
parameters and much more. I tend to make Actions completely accessible. 
If something needs to be protected, I move it back to my service tier.

> I presume that the interceptors surrounding the action do not get 
> invoked? Or do they? Either way, invoking the actions again seems to 
> fold the architecture back in on itself.
I would have to assume so since the parameters interceptor is being 
called in order to pass parameters to the Action. As for the folding, 
this is where we can probably agree to disagree. I don't see any 
difference between this model and a JSP taglib. I've just removed the 
need to write a taglib, which is faster and more testable.

> Hence my original message - it seems there's a place for calls to the 
> model in the position where the Results are at the moment.
How do you configure this? My main point is that this seems like more 
configuration/overhead. I'm heading the opposite direction with no 
configuration and simple handling of as much as possible.


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

View raw message