On 10/30/06, Konstantin Priblouda <[EMAIL PROTECTED]> wrote:
... and struts2 action being xwork action does just
this - no more or less. it performed business logic
and determined outcome as string result name.
Agreed. The Action class should focus on business logic, and return a
result code that would map to a top-level box on a flow chart, marked
with labels like "success", "failure", and "exception".
> Then, the Action returns a code that indicates
> logical outcome. In
> practice, the result code maps to a result that
> encapsulates a path.
it maps to some kind of result - it just happens that
there are results now (mostly) which encapsulate a
path.
Yes, but they map to a single path. A business result, like "success",
"failure", and "exception", might map to a cluster of paths, depending
on concerns like security role, locale, browser type, ajax mode, and
so forth.
We can use "presentation logic" in the server page or template, but if
there are multiple concerns, the template becomes messy, and it starts
to look like a hack.
If we are willing to resolve all these concerns in the Action, the
problem goes away. But, I think we agree that some of these concerns
are outside the scope of the Action.
> But, what if there are flavors of success or
> failure?.
... they are kind of different results.
Yes, and the difference is based on concerns that might be outside the
scope of a business-orientated Action, so the Action has no clean way
to select the correct result.
>As Don points
> out, we might want to present different pages based
> on the browser.
What action got to do with it?
The Action class itself should have nothing to do with it. But, the
action element, which, in effect, encapsulates the paths, should be
able to select from a cluster of paths, based on concerns outside the
scope of the Action class.
> Or, we might want to present different pages based
> on locale?
... not an action business. result shall take care of
this ( like rewrite rules in httpd - call it
LocalAwareResult which pulls locale and , say, adds
proper suffix )
> Or based on security role?
... again result could take this over. or even
template itself.>
> Do we want to cram all this into a single result
> code?
yep. with proper results and maybe kind of
interceptors
OK, the Result takes it over. But where do we encapsulate the paths,
if not in the action element?
> return findResult("success");
Congratulation. You are describing ( somehow )
situation of struts-1 - action has to be aware of
servlet environment and take decisions based on it.
And how are you going to sumulate this in tests?
Yes, this is a straw argument to illustrate the need to keep this code
in the scope of a Result. But, if we do this in the scope of a Result,
then we need a way to encapsulate the paths utilized by the Result.
> But, in practice, this has proven to be a very
> common use case.
> There's the browser-agent case, the ajax-case, the
> localization-case,
> the security-roles case, to name a few. We often
> want to select a
> specialized result for the same general outcome
> ("success", "failure",
> "error", "exception", "login") .
Why do it in action?
Exactly. Better to do it in a type of Result that can be configured to
accept a cluster of paths, like an Action, but focused on a different
concern or set of concerns.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
