You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2004/01/31 23:30:20 UTC
multipart requests in struts-chain
It seems that struts-chain's AbstractPopulateActionForm was
implemented with its own strategy for moving values from the context
to the form. Unfortunately, this strategy doesn't support multipart
forms (file uploads).
I've hacked to make it work, but I thought I should understand the
design decisions before committing any changes. Or rather, let me
explain how I fixed it -- trying to fit within the existing design --
and see if anyone (Craig?) has feedback.
I refactored the "execute" method of AbstractPopulateActionForm to this:
ActionForm actionForm = ...
if (actionForm == null) {
return (false);
}
ActionConfig actionConfig = ...
reset(context, actionConfig, actionForm);
populate(context, actionConfig, actionForm);
handleCancel(context, actionConfig, actionForm);
return (false);
I moved the behavior which was there before into the two protected
methods, "populate" and "handleCancel". Then, in
...servlet.PopulateActionForm, I overrode populate() to extract the
suffix and prefix and call RequestUtils.populate(Object, prefix,
suffix, request), which does handle file uploads.
I'm assuming the goal was to keep HttpServletRequest out of the base
implementation. Therefore, I'm assuming that these changes are in
line with the design goals. But I'd like a nod before I commit them.
The extraction of "handleCancel" was just to make the base "execute"
read more clearly, and that method is not overridden in
...servlet.PopulateActionForm.
Thanks
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: multipart requests in struts-chain
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:33 PM -0800 2/1/04, Craig R. McClanahan wrote:
>The original design in struts-chain did not contemplate the complexities
>required to support file upload at all. If you can refactor the existing code
>to support that gracefully support both use cases, that's awesome ... if it
>requires separate chains for the two use cases, that's ok (indeed, that's part
>of the reason that refactoring the request processor into a chain makes things
>easier to customize).
I went ahead and committed my changes, which don't use subchains, so
that people who are looking to switch to using the Chain processor
will have working file uploads. We can always refactor later.
I'm extremely happy with where struts-chain is going. I'd encourage
anyone with the hacking spirit to start trying it sooner than later
and help us figure out if there are any other major features missing.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: multipart requests in struts-chain
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Joe Germuska <Jo...@Germuska.com>:
> It seems that struts-chain's AbstractPopulateActionForm was
> implemented with its own strategy for moving values from the context
> to the form. Unfortunately, this strategy doesn't support multipart
> forms (file uploads).
>
> I've hacked to make it work, but I thought I should understand the
> design decisions before committing any changes. Or rather, let me
> explain how I fixed it -- trying to fit within the existing design --
> and see if anyone (Craig?) has feedback.
>
> I refactored the "execute" method of AbstractPopulateActionForm to this:
>
> ActionForm actionForm = ...
> if (actionForm == null) {
> return (false);
> }
>
> ActionConfig actionConfig = ...
>
> reset(context, actionConfig, actionForm);
> populate(context, actionConfig, actionForm);
> handleCancel(context, actionConfig, actionForm);
>
> return (false);
>
> I moved the behavior which was there before into the two protected
> methods, "populate" and "handleCancel". Then, in
> ...servlet.PopulateActionForm, I overrode populate() to extract the
> suffix and prefix and call RequestUtils.populate(Object, prefix,
> suffix, request), which does handle file uploads.
>
> I'm assuming the goal was to keep HttpServletRequest out of the base
> implementation. Therefore, I'm assuming that these changes are in
> line with the design goals. But I'd like a nod before I commit them.
>
> The extraction of "handleCancel" was just to make the base "execute"
> read more clearly, and that method is not overridden in
> ...servlet.PopulateActionForm.
>
> Thanks
> Joe
>
The original design in struts-chain did not contemplate the complexities
required to support file upload at all. If you can refactor the existing code
to support that gracefully support both use cases, that's awesome ... if it
requires separate chains for the two use cases, that's ok (indeed, that's part
of the reason that refactoring the request processor into a chain makes things
easier to customize).
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org