struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: multipart requests in struts-chain
Date Mon, 02 Feb 2004 07:33:44 GMT
Quoting Joe Germuska <>:

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message