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.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
