[Struts Wiki] Update of StrutsMultipleActionForms by MichaelJouravlev
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/StrutsMultipleActionForms
--
Simon Matic Langford
+
+
+ Two actions, two forms
+
+ I found action chaining with redirection to be the best solution. Chaining
allows to have more fine-grained actions which are less dependent on each
other. Redirection allows to get rid of POSTDATA situation.
+
+ attachment:twoacttwoformsredir.gif
+
+ {{{
+ action path = /inputAction
+ type = com.acme.struts.InputAction
+ name = inputForm
+ input = /WEB-INF/jsp/inputError.jsp
+ forward name=OK path=/outputAction.do redirect=true/
+ /action
+
+ action path = /outputAction
+ type = com.acme.struts.OutputAction
+ name = outputForm
+ input = /WEB-INF/jsp/outputError.jsp
+ forward name=OK path=/WEB-INF/jsp/viewOutput.jsp/
+ /action
+ }}}
+
+ This design can be used to handle input and output of web applications. The
source action receives the request, the source form validates the input data.
If input is valid, the control is redirected to output action. Output action
loads output data into output form and forwards to JSP.
+
+ The control flow in detail:
+
+* Struts calls reset() on the input form bean (1)
+* Struts populates the fields of input form bean using setters (2). Input
form bean does not have to define the getters.
+* Struts calls validate() on input form bean (3)
+* If validate() returns non-empty !ActionErrors object, control is
forwarded (or redirected) to an error page identified by input attribute of
the action mapping (4a) Before returning, validate() needs to store error
messages in the session-scoped object, so errors would be available in the
output action.
+* if validate() returns empty !ActionErrors object or null, Struts calls
execute() method of the input action class (4b)
+* execute() updates business and persistent objects.
+* in most cases, execute() cannot simply redirect to a static URL defined
in struts-config.file. Input action must tell output action which object to
show. The object ID can be passed either through session-scoped object or as
parameter of redirected request. If ID is passed as request parameter, then
execute() creates new !ActionForward instance with modified URI of the target
action, adding to it the ID of an object which must be displayed.
+* When execute() returns OK, Struts redirects to the output action (5)
+* Struts does its usual reset()/populate/validate() sequence on output
bean. Actually there is no populate phase, since request contains no data,
except object ID, which is set in the output bean. And validate() has nothing
to validate in the output form, so it returns null.
+* execute() method of the action class locates business object, using ID
passed with the request, and fills out the fields of the output form.
+* output action returns OK and Struts displays the result page (8)
+
+ A great side effect of this solution is that output page can be reloaded
without processing the request in input action again. This helps to prevent
double submission of input data.
+
+ Choosing between passing object ID in redirected request or in the session
+ Passing parameter through the session-scoped object is less flexible. First,
if different form beans are used, this cannot be done through a form bean, thus
ID would have to be stored in the session. Consequently, output action must
know about this session parameter. On the other hand, if output action were
called directly, the ID would be in the request. Thus, output action would have
to check session first to verify if it was redirected to, and if not, read ID
from the request.
+
+ This is too complex for my tastes. Passing parameter in the redirected
request makes output action simpler and universal, it just picks the parameter
from the request and uses it. It does not know or care, how exactly it was
called.
+
+ Follows the example from a working CRUD application.
+
+ {{{
+ !--
+ Create Item. Creates new object with random ID, temporarily
+ saves it in the session, attaches item ID to redirected URL
+ and redirects to editing.
+ Input: none
+ validation: none
+ --
+ action path = /createItem
+ type = com.superinterface.items.CreateItemAction
+ validate = false
+ forward name=itemCreated path=/editItem.do redirect=true/
+ /action
+
+ !--
+ Edit Item. Presents new or existing item for editing.
+ Item is looked up by ID.
+ Input: item id
+ validation: item must exist in the item list
+ --
+ action path = /editItem
+ type = org.apache.struts.actions.ForwardAction
+ name = itemFormOutput
+ input = itemError
+ parameter = /WEB-INF/items/editItem.jsp
+ forward name=itemError
Re: AJAX and Struts -- Cocoon Use of Zammetti's ideas
+1 On 4/21/05, Niall Pemberton [EMAIL PROTECTED] wrote: Jack I find your continuous sarcasm, insults and generally rude manner in your posts to these lists unacceptable. I would appreciate it if you could please stop posting all this type of rubbish and stick to the purpose of these lists. Thank You. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 5739] - Struts fails silently in too many places
You might open a wiki page where we could start collecting more information, and perhaps develop a strategy. IMHO, this is a valid issue. But, it's also an enhancement, and won't block a release. Marking it invalid doesn't seem appropriate. -Ted. On 4/21/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=5739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=5739 --- Additional Comments From [EMAIL PROTECTED] 2005-04-21 16:55 --- My concern with this bug is that it started out with a broad scope, and in the course of its life, became even more so. I wouldn't be opposed to reopening the more specific ones, and either marking this as invalid or renaming it to limit its scope to checking struts-config declarations. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 5739] - Struts fails silently in too many places
It may be a valid issue, but so is Make Struts Faster. My point is this ticket is so broad its long life is a testament to its validity or lack thereof. I suppose it gets down to how each developer views tickets, but I personally see enhancements tickets as requesting a specific feature that can measurably be addressed. If this ticket was broken up into its specific examples, they'd be fine tickets I'd even recommend be marked bugs. I don't feel strongly enough to make a big deal of this, but it is another symptom of a general paralysis I feel affects Struts development. Sure, we need to be careful for backwards compatibility and we want to encourage participation, but there is also value in having a strong direction and making tough decisions to move the project forward. Three year old bugs so general they remain unaddressed, I feel, need to either be fixed or resolved in another manner. If we can't come to grips with our past, how can we lead in the future? /sermon :) Don Ted Husted wrote: You might open a wiki page where we could start collecting more information, and perhaps develop a strategy. IMHO, this is a valid issue. But, it's also an enhancement, and won't block a release. Marking it invalid doesn't seem appropriate. -Ted. On 4/21/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=5739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=5739 --- Additional Comments From [EMAIL PROTECTED] 2005-04-21 16:55 --- My concern with this bug is that it started out with a broad scope, and in the course of its life, became even more so. I wouldn't be opposed to reopening the more specific ones, and either marking this as invalid or renaming it to limit its scope to checking struts-config declarations. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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]
DO NOT REPLY [Bug 34559] - DownloadAction enhancements
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34559. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34559 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement OS/Version|other |All Platform|Other |All Summary|[FEATURE REQUEST] |DownloadAction enhancements |DownloadAction enhancement | Version|Unknown |Nightly Build -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34445] - use charsets given by browser for form field encodings
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34445. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34445 --- Additional Comments From [EMAIL PROTECTED] 2005-04-22 05:35 --- I'd prefer not to use FileUpload's ParameterParser to handle this in Struts, since that class isn't intended to be public / used by packages other than FileUpload itself. Let me give it some thought. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33122] - unchecked exception when paramId value already in the params map
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33122. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33122 --- Additional Comments From [EMAIL PROTECTED] 2005-04-22 07:02 --- Ok, that code was not copied from a running example, but the following is a complete jsp that does compile and run: %@ taglib uri=/tags/struts-bean prefix=bean% %@ taglib uri=/tags/struts-html prefix=html % %@ taglib uri=/tags/struts-logic prefix=logic % Hello % pageContext.setAttribute(bean, ); % % java.util.Map map = new java.util.HashMap(); % % map.put(id, new Integer(2)); % % pageContext.setAttribute(map, map); % html:link action=/doIt name=map paramId=id paramName=bean paramProperty=bytesLink/html:link ... There is the expected exception which is correctly traced when used without the portalStruts framework: [java/lang/Integer incompatible with [L]: java.lang.ClassCastException: java/lang/Integer incompatible with [L at java.lang.Throwable.init(Throwable.java) at java.lang.Throwable.init(Throwable.java) at java.lang.ClassCastException.init(ClassCastException.java:56) at ... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
