Hello!
Craig McClanahan wrote:
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote:
I think of the state information represented by an ActionForm (in
Struts 1.x) or potentially as properties of an "action" class (per the
current discussion) to be part of the *view* tier. Further, I see the
role of the execute method on an action as being an Adapter Pattern
link between the web tier (HTTP-centric) and the model tier
(HTTP-agnostic). Therefore, I don't feel any pain at the idea of
combining the two together.
It sounds like what your saying is that there really is no need for a
control layer, we're coming down to view-adapter-model now. Am I
understanding that correctly?
Not completely, but amost.
There are reasons to have an "application scoped" front controller.
There are reasons to have a "view-scoped" front controller. There is
*no* reason I am aware of that requires these controllers to be the
same :-).
(The question is below but here I only wonder: what is a "view-scoped"
front controller? :) what are the differences between a "view-scoped"
and an "application-scoped" (a "normal" one as I can guess) front
controller?)
In Shale, the application-scoped functions are performed by a Commons
Chain pipeline that is configured and processed by Shale's filter.
This is the right place to put things like "if the user isn't logged
on, redirect to the login page" and "log every request" type
functions. But it is not the right place for "execute this expensive
SQL query, but *only* if I am the view that needs it.".
In Struts 1.x, you get around the latter case, typically, by having a
setup action before the view, and a process action after the view.
Shale simply combines those two bits of code into a single class (and,
along the way, combining the form bean too), resulting in a little
less code, but a lot fewer classes.
In Struts 1.x I do use setupAction->jsp->processAction technique and was
thinking all the time how can I put together the setupAction and
processAction into one class. The best way I could think of was to make
a "downgraded" DispatchAction, that dispatches based on mapping's
parameter (in the latest version of Struts just the same thing appeared
named MappingDispatchAction) and to put both setup and precess
actions-methods into one class.
(p.s. this technique made it also possible to automate token-based
protection - every prepare calls saveToken and before every process
token is checked)
So please tell, in what way does Shale do this?
Should I pay more attention to shale? Is it ready to try it out on some
small test projects?
Yaroslav Novytskyy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
