I'll de-lurk for a minute to say - sounds good to me. Better than what we have now.
If you're looking to consider alternatives as well, IIRC there was some discussion of implementing a delayed wrapper around the multipart parsing to allow finer-grained control of when, how, and if the parts were actually parsed. The problem with the pre-parsing of the upload as it is now is that it is all or nothing - you have to turn on multipart uploads for every uri in cocoon's space (which is infinite). Since I can't really produce code on this now personally, I'll just toss it out as a helpful reminder of past discussions. Geoff On 8/18/05, Sylvain Wallez <[EMAIL PROTECTED]> wrote: > Hi all, > > Uploads in Cocoon are handled at the servlet level, including a check of > the maximum upload size which raises an exception. This exception is a > major pain because it gives no chance to the application to warn the > user that she exceeded the allowed limit. All we get is an ugly servlet > engine-generated error page. > > Rather than throwing an exception, the multipart parser could store in > the request a special implementation of the Part interface, > "InvalidPart" that allows the application to know about it and react > accordingly. For example, the CForms upload widget could show a > validation error in such occasions. > > All methods of the Part interface (getInputStream, getName, etc) would > of course throw an exception in InvalidPart, but that exception would > have a chance to be handled cleanly by a <map:handle-errors> > > WDYT? > > Sylvain > > -- > Sylvain Wallez Anyware Technologies > http://people.apache.org/~sylvain http://www.anyware-tech.com > Apache Software Foundation Member Research & Technology Director > >
