Actually I just realized, if the Multipart stuff was all done in its own Command, the point in the process it gets executed can be adjusted just by the position in the Chain config - as long as its before the populate Command. So that shouldn't be an issue, and theres no real reason for having the request wrapped until the multipart processing starts.
Niall ----- Original Message ----- From: "Niall Pemberton" <[EMAIL PROTECTED]> To: "Struts Developers List" <dev@struts.apache.org> Sent: Friday, February 25, 2005 2:00 AM Subject: Re: multipart requests -- suggesting things be rethought and that the hardwiring be pulled > I agree with you in general that the multipart functionality should be > re-factored so that it could be more easily overriden. IMO though one of the > issues is that the key multipart processing is in the RequestUtils's > populate() method and as thats a "static" utils method its not possible to > override its default behaviour. In fact if it wasn't for the multipart > processing there is no real reason for the RequestUtils's populate() method > to exist. In the Struts 1.3 environment, I believe we should move the > RequestUtils multipart processing into a Command of its own, then it would > just be a case of someone plugging in their own Command to replace that > behaviour. > > I don't agree with you on getting rid of the MutipartRequestWrapper for the > "standard struts" multipart flavour though. The main benefit I see is that > by using a request "wrapper" and adding in any "text" parameters from the > multipart request, those are made available like "normal" parameters - so if > someone wants/needs to access Request parameters directly from an Action or > someplace they can do so - whether its multipart or not. Take for example if > you wanted to use a custom "dispatch" flavour Action (with a multipart > request) that determined the method to execute directly from the request > parameters, like in your buttons solution. Making "text" parameters > available by "wrapping" the request means that there is no need for special > multi part solution. > > Another issue that has come up in the past is the fact that the multi-part > handling isn't done until the populate step. I vaguely remember someone > wanting to check a parameter earlier in the process in a custom > RequestProcessor (e.g. processMapping) - but the parameters were not > available then. > > The one part of the Struts 1.2 RequestProcessor that hasn't made it into a > Command is the processMultipart() method. In Struts 1.2, all that does is > "wrap" the Request. I think in Struts 1.3 we should have a "Multipart" > Command which should wrap the request and also do the multi-part processing > that's currently done in RequestUtils populate() method. In order for this > to work though, the "File" items processed by the multipart request handler > would need to be stored somewhere - not with the other parameters as > parameters can only have String values - but they could be added as a new > property in the MultipartRequestWrapper. Then the populate Command would > need to pick up those file items and merge them with the request parameters > to call BeanUtils populate - or alternatively call BeanUtils populate > twice - maybe have an additional populateMultipart() method in the > PopulateActionForm Command. Does anyone know of a reason(s) for not moving > the multipart processing to that point in the process? > > If we did this, then all you would need to do is replace the new Multipart > command and possibly override part of the populate Command (if you wanted > the file items populated into the form bean). > > Niall > > P.S. I agree with you - the code in ConfigHelper's > getMultipartRequestWrapper() method is wrong and should be removed - it will > return the multipart handler, not the request wrapper. > > ----- Original Message ----- > From: "Dakota Jack" <[EMAIL PROTECTED]> > Sent: Thursday, February 24, 2005 9:13 PM > > > <snip> > > I am not sure what you are thinking but the wrappers really are just > > decorations and are not necessary. The only tricky part is in > > RequestUtils' populate method vis-a-vis ActionForm. > > </snip> > > <snip> > > All in all, if the > > wrapper were just completely dumped and the wrapping code put into > > RequestUtils everything would immediately be better with no real > > changes. Something probably should be done with the mistaken > > identification, unless, as I said, I somehow have something wrong > > about that. But, since the same key is used for > > MultipartRequestHandler, I don't see how I can be wrong about that. I > > assume you would not use the same key under Globals for two different > > and inconsistent class types. > > </snip> > > <snip> > > I use the same commons based multipart classes that Martin does with > > Struts upload, but just do it a lot differently. I have used Hunter's > > as well. And, I have tried various combinations that I have created > > on my own. I like commons a lot. > > </snip> > > > > --------------------------------------------------------------------- > 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]
