Andy Foster wrote:
Sorry I may have been confusing matters when I named the action redirect.
There is no client side redirect. The form simply posts to an action mapping
of /login_redirect.do but it can be named anything. Each page has one of
these actions if it has more than one submit type. The relay action that is
run does nothing more than look up an action forward using a form
submitaction attribute to pass control onto an action that can process the
actual request. This does work fine as I have used it, my concern is that it
won't work with the bridge due to the request reposnse split being on the
first forward.
Ok, then indeed this will break down in a portlet context.
But you will have problems too in a plain web application I think.
Try refreshing the page after a user action. Does it still work as expected?
This is one of the reasons why I actually like the (enforced) split between
action and render in the portlet context. It forces you to properly separate
your action handling and model processing from the rendering task.
And its not difficult to accieve the same in your case I think.
As I said before, let the relay action invoke plain POJOs which handle your
business requirements (no need to attach that to the Struts infrastructure),
have them update your model (possibly using Session scoped beans if you're
working
with multi page forms), and then (client-side) redirect to your render action.
That way, whatever context (web or portlet), users refreshing the page or
pressing the back button will get the view they expect instead of out-of-sync
"old" content.
Regards,
Ate
Regards
Andy Foster
-----Original Message-----
From: Ate Douma [mailto:[EMAIL PROTECTED]
Sent: 03 July 2006 09:45
To: [email protected]
Cc: 'Struts Users Mailing List'
Subject: Re: Strtus and Portlets
Andy Foster wrote:
Hi all,
I am about to develop a new struts app that will be ported afterwards to
be
used in a portlet and I plan to use the struts bridge support. I want to
try
and ensure that I don't break the bridge with my normal conceptual design
before I start building anything. The pattern I use is to break up
processing of the request from the display of the next page and to handle
a
form that has multiple submit buttons that need to perform different
actions
(yes that good old problem)
I usually implement this pattern in struts-config to separate out
concerns:
1) Page always calls a redirect action that takes the submitaction
attribute
in the form and finds the forward using the submitaction as the key.
2) The process action then processes the request and on success calls a
display action to render the next page
3) The display action finally calls a go action that is the simple
redirect
to the JSP
<action
path="/logon_redirect"
name="logonForm"
type="org.xxx.RelayAction"
scope="request"
validate="false">
<forward name="logon" path="/process_logon.ask"/>
<forward name="cancel" path="/go_welcome.ask"/>
</action>
<action
path="/process_logon"
name="logonForm"
type="org.xxx.LogonAction"
scope="request"
input="/go_logon.ask"
validate="true">
<forward name="success" path="/display_briefcase.ask"/>
</action>
<action
path="/display_briefcase"
name="briefcaseForm"
type="org.xxx.GetBriefcaseAction"
scope="request"
validate="false">
<forward name="success" path="/go_briefcase.ask"/> </action>
<action
path="/ go_briefcase.ask "
forward="/jsp/briefcase.jsp">
</action>
This is obviously action chaining and I'm aware that this can cause issues
in portlets and the bridge due to the separation of ActionRequests and
ActionResponse interfaces.
You probably mean ActionRequests and RenderRequests.
I have read the website and if I'm reading
correctly the bridge would separate ActionRequests from ActionResponse
processing on the first action forward, in this case on my redirect
meaning
the process would be part of the render which is not what I want.
Am I correct or will the above work OK?
You are correct but I think it will not work with the Struts Bridge.
And I'm wondering if it even will work in a non-portlet environment.
If you send a (client-side) redirect from the first received action, how are
you
going to communicate the received action parameters (e.g. the action Form)?
In your example, these are all configured as request scoped, so you would
lose
whatever parameters you received after the redirect.
What changes may I have to make to ensure I integrate with the bridge
seamlessly?
Transform your secondary actions (the one you planned to redirect to after
the
received action parameter) into POJOs you invoke (directly) from the initial
action request.
That way, you can properly process your model/state. And thereafter, send
the client-side
redirect to the target/render action. This will allow your app to run in
both web and portlet
environments (even at the same time if you want).
Regards,
Ate
Regards
Andy Foster
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
