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.
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]
