I am currently working on a patch for the RedirectResult that appends
the namespace and servlet context for relative redirects.
This means that your example below, you can use
<result name="success" type="redirect">
<param name="location">edit.action</param>
</result>
And it will execute response.sendRedirect("/gadget/edit.action"))
It also does response URL encoding for URL rewrite based session
tracking (no cookies)
Cameron.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rene Gielen
Sent: Friday, 29 August 2003 4:40 AM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] WW2- Improving ServletRedirectResult
Hi,
we needed some more sophisticated redirection handling and I implemented
it,
based on ServletRedirectResult / ActionChainResult. I was asking if we
are
alone with our need for it. If not (say HERE loud and clearly :-), I
will
send it over...
In our application we have lots of edit->store->edit or
edit->delete->overview
action chains for various business entities. But there is a little
problem
with the chain result type, because when store.action chains go
edit.action
on succes, the current URL remains xyz/store.action. Not very pleasant
for
the lovers of browers reload / back button...
Alternative is to use a redirection, and, of course, there is a suitable
result type redirect, but... it only takes complete http location as
arguments and knows nothing about actions and namespaces. So if you
define a
package with its own namespace, say one namespace for each business
entity,
having nearly almost an edit, store, delete and overview action per
namespace, it would be nice to configure the redirection just like you
do
when using chain.
So I implemented action handling for redirect result type triggered by
the new
parameter actionName, analog to the chain result type. When the
actionName
parameter is given, the namespace will be resolved (if staying in local
namespace), and .action is appended to construct a valid url for
redirection.
If instead the old location parameter is set, nothing changes to former
handling of redirection. To give an example:
<package name="gadget" extends="default" namespace="/gadget">
<action name="edit" class="de.aixcept.foo.GadgetActions" method="edit">
<result name="success" type="dispatcher">
<param name="location">/WEB-INF/jsp/gadget/edit.jsp</param>
</result>
<interceptor-ref name="defaultStack"/>
</action>
<action name="store" class="de.aixcept.foo.GadgetActions"
method="store">
<result name="error" type="dispatcher">
<param name="location">/WEB-INF/jsp/gadget/edit.jsp</param>
</result>
<!-- Redirect to edit ection in same namespace on success -->
<result name="success" type="redirect">
<param name="actionName">edit</param>
</result>
<interceptor-ref name="defaultStack"/>
</action>
<action name="lookup" class="de.aixcept.foo.GadgetActions"
method="lookup">
<result name="success" type="redirect">
<param name="location">http://www.gadgetfarm.org/lookup/</param>
</result>
<interceptor-ref name="defaultStack"/>
</action>
</package>
Anybody else needing it?
Regards,
- Rene
--
Rene Gielen | http://www.aixcept.de/
Aachen | PGP-ID: BECB785A
Germany | gielen at aixcept.de
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
