You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Paul Benedict (JIRA)" <ji...@apache.org> on 2007/07/07 07:06:26 UTC
[jira] Issue Comment Edited: (STR-1674) Cancellation does not work
as intended without form
[ https://issues.apache.org/struts/browse/STR-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41387 ]
Paul Benedict edited comment on STR-1674 at 7/6/07 10:05 PM:
-------------------------------------------------------------
I am attaching my proposal for the change based on Niall's feedback, plus some other enhancements.
First, I have pushed isReset and isPopulate into the abstract class because ActionConfig has "reset" and "populate" properties. These properties are Struts-proper and should have identical effect for any servlet or portlet or other implementation. Otherwise the conditional would have to be included in every subclass.
Second, I have added an "populateOnCancel" property to the command that is configured for the entire app. It's an optional property which allows the form to be not populated if cancellation occurs. However, I find myself not liking this implementation and don't know how to resolve it. It is not clear when this property applies. Right now, it can apply if reset/populate are correct for the action, and then the cancellation property is checked.
Third, I have a difficult time accepting that setting the MULTIPART_KEY into the request scope belongs in reset(). Since it's relied upon in populate(), I believe the proper place is in the latter method. If reset() is not called, but populate() is, the key should still be set.
Opinions regarded necessary :)
was:
I am attaching my proposal for the change based on Niall's feedback, plus some other enhancements.
First, I have pushed isReset and isPopulate into the abstract class because ActionConfig has "reset" and "populate" properties. These properties are Struts-proper and should have identical effect for any servlet or portlet or other implementation. Otherwise the conditional would have to be included in every subclass.
Second, I have added an "populateOnCancel" property to the command that is configured for the entire app. It's an optional property which allows the form to be not populated if cancellation occurs. However, I find myself not liking this implementation and don't know how to resolve it.
It is not clear when this property applies. Right now, it can apply if reset/populate are correct for the action, and then the cancellation property is checked.
Opinions regarded necessary :)
> Cancellation does not work as intended without form
> ---------------------------------------------------
>
> Key: STR-1674
> URL: https://issues.apache.org/struts/browse/STR-1674
> Project: Struts 1
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1 Final
> Environment: Operating System: All
> Platform: All
> Reporter: Patrick Dumontel
> Assignee: Paul Benedict
> Fix For: 1.4.0
>
> Attachments: populateaction.zip
>
>
> If the action mapping does not contain a form bean name, e.g.:
> <action path="/this/action"
> type="action.class.name"/>
> using isCancelled() in that action will always return false. The code in
> org.apache.struts.action.RequestProcessor.processPopulate returns if the form
> is null before setting the Globals.CANCEL_KEY attribute.
> It seems to me that since a request parameter is used to detect the cancel
> button (the return request.getParameter(Constants.CANCEL_KEY) != null line),
> the setting of the request attribute should not depend on whether the action
> mapping uses a form.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.