On 10/30/06, Konstantin Priblouda <[EMAIL PROTECTED]> wrote:
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> On 10/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
> > Well, my original purpose is to find a way to best
> handle the case where
> > we want to generate multiple types of output
> without the Action being
> > aware of it. Foremost in my mind is the ability
> to have an action be
> > called and expect HTML, partial HTML, or JSON
> without affecting the
> > Action.
In current situation action is not aware of result
type. It just returns string result code.
Yes, ideally the Action should be able to focus on the top-level
outcome of the business logic. Did the request success or fail? Was
there a recoverable error? A fatal exception?
Then, the Action returns a code that indicates logical outcome. In
practice, the result code maps to a result that encapsulates a path.
But, what if there are flavors of success or failure?. As Don points
out, we might want to present different pages based on the browser.
Or, we might want to present different pages based on locale? Or based
on security role?
Do we want to cram all this into a single result code?
Of course, we _could_. One alternative would be to have codes like
<action name="ViewFoo" class="mypackage.ViewFoo">
<result name=""success.modern-browser">ViewFoo.jsp</result>
<result name="success.netscape4">ViewFoo-netscape4.jsp</result>
<result name="failure.modern-browser">ViewFoo-failure.jsp</result>
<result name="failure.netscape4">ViewFoo-netscape4-failure.jsp</result>
<action>
And, the selection logic would be delegated to a helper method that
generated the token
return findResult("success");
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") .
If we bury this logic in the Action, as I expect many of us do now,
then it's harder to share the code. But, if we elevate the use case to
a first-class feature, then we can share result selectors that solve
common use cases.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
