Date: 2005-03-17T11:01:01 Editor: DakotaJack Wiki: Apache Struts Wiki Page: StrutsMultipleActionForms URL: http://wiki.apache.org/struts/StrutsMultipleActionForms
no comment New Page: ##language:en == Multiple ActionForms in ActionMapping == There is no way in Struts to handle the most common use case and a huge percentage of the discussions on the Struts user and developer lists is about various hacks we build to do so. The answer, I would suggest, is multiple ActionForms. This is intended to be a forum for discussing that option in an intelligent way. Please add your comments at the end, so that the main problem is readable as defined, unless you want to redefine the problem. Please also feel free to offer different solutions to the most common use case problem, hacks allowed. Dakota Jack === Most Common Use Case Described/Defined === The most common use case that I know of is when we go from one page to another page on the browser, sending the server certain request values from the first page and getting from the server certain response values on the second page. Most pages have both input data (setup) and output data (request name/value pairs). I presume that we are using Struts, so the first page and the second page will each have different <html:form> values. === Problem Handling the Most Common Use Case Described/Defined === We are going go from firstPage.jsp to secondPage.jsp. Each of these pages has its own <html:form>. We need to process the input data from firstPage.jsp and to setup the output data for secondPage.jsp. We need to both process input values and to provide setup values. I assume this is a given for the most common use case and, if this is wrong (which is sort of inconceivable to me), then I invite with open arms any statement showing how this is so. Until then, we will assume that no matter what we are going to have to do both of these things: Process data from FirstPageActionForm Setup data for SecondPageActionForm How can we do this intelligently? === Limitation of ActionMappings in Struts Described/Defined with Respect to the Most Common Use Case === The obvious answer would be to have an Action (MyAction, say) process data from FirstPageActionForm and setup data for SecondPageActionForm. This would allow us to have a page oriented ActionForm, which makes sense, without having to use page-centric solutions. But, we cannot! ActionMappings allow us to have only one ActionForm per Action. Since the <html:form> in firstPage.jsp and the <html:form> in secondPage.jsp logically would have different related ActionForms (FirstPageActionForm and SecondPageActionForm, say) this provides a difficulty because we have process data from FirstPageActionForm and setup data in SecondPageActionForm. === How We Do It Now === There is in fact no way, without subverting the basic framework, to handle the Most Common Use Case. And, there are only hacks available. There is no way at present to handle the Most Common Use Case without subverting the general way Struts is intended to process requests. The hacks are: ==== AVOID the Problem by Using One Page Only ==== We can create one JSP page doing the work of two which AVOIDs the problem with a "quasi-Portlet" response. There is only one ActionForm in this case, so the processing and setup can be done with This is a solution that will work in certain situations but really is a hack in most situations. ==== AVOID the Problem by Using One ActionForm Only ==== This is a common solution which is the one I usually use. I really hate this solution. This solution really has to misuse the ActionForm because it is setup to represent the <html:form> on a page. The result is that the application architecture is not that sensible. ==== AVOID the Problem by Chaining Actions ==== This is the worst in my opinion. Why would we want to use two actions and two action mappings to do one thing? There are lots of reasons to not like this. === CONCLUSION === The result, I think, is that there is no way to handle the most common use case in Struts. How weird is that? Dakota Jack --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
