struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: Would like more flexibility in Result
Date Sun, 30 Dec 2007 20:56:30 GMT
Brian Pontarelli on 29/12/07 05:34, wrote:
> 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.

I'm very much in favour of a KISS approach, don't get me wrong. I think I was 
not seeing the wood for the trees.

I take your point that perhaps messing with Result is not the way to go, but I 
can't appreciate the <s:action> tag.

I'll ditch this thread and reformulate what I'm trying to communicate.

Adam

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message