On Mon, 8 Nov 2004, Geoff Howard wrote:
On Mon, 8 Nov 2004 08:20:56 -0600 (CST), Luigi Bai <[EMAIL PROTECTED]> wrote:I'd like to point out that the Multipart support in Cocoon is one of the few things that isn't pluggable or replaceable. I'd like it to be possible to configure web.xml/CocoonServlet to take a class name that implements some MultipartParser interface, and keep Part as an interface (perhaps letting it evolve as different implementations are available).
Some historical/background points (with the caveat that some changes have happened due to CForms that I have not paid full attention to): - We also have tried to avoid anti-patterns like "over componentization" i.e., making things pluggable that really don't need to be, which was probably judged to be the case here (though see below). - There were other grander plans for request handling. In particular, see the "Pluggable Request Factories" of Stefano's RT here: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106131747919501&w=2 - You'll notice a third point in the RT above: our "pluggable" problem extends beyond multipart uploads. It includes things like WebDAV and SOAP.
Good points.
Keeping the integration at the level of Interface means we don't run into the same kind of rigamarole that is going on with ECM etc.
True, although another major lesson learned from ECM was that external communities can also let you down. The last time I monitored the commons list, I didn't get warm fuzzies about the politics and health there, for what that's worth.
That's precisely what I mean...
By the way, I'm not clear on why Multipart support can't be implemented as an Action? If it's an Action, then it's clearly pluggable, and all this goes away. Why is it so early in the process, hard coded in CocoonServlet?
- Actions were a muddy concept that have been or can be at least partially if not fully replaced by other items. - Why so early in the process is another good question. Two reasons I remember are: 1) Cocoon is not only a CocoonServlet but also runs in different environments (Command Line for example) where multipart requests do not have exact parallel if they exist at all. We have tried to avoid dependencies on Servlet specific APIs in part due to this issue. Combined with the fact that Cocoon's uri abstraction (all uris are mapped to the CocoonServlet, making total control in sitemap possible) makes it possible that relying on Commons upload may turn out to be a bad idea in the end: they do not have the same complexity of concerns. In fact, they've had some recent refactoring there to accomodate portlet environments. If someone can give an analysis of whether this helps us or hurts us with respect to our complex needs, that would be a big plus. 2) The cocoon framework as many frameworks pre-parses the request to make all parameters available to the pipeline semantics. The plan of adaptRequest was to allow this to take place for most parameters up front, but the multipart bits later. The work to do this was never done.
Ah, a generic request adaptation framework.
Any patch that addresses all these concerns would probably get some good attention.
Short of that, a patch that provides backwards compatibility by wrapping the commons library is next best in my opinion. Short of full pluggable request adaptors, encapsulation is as good as configurability in this case IMO. In this case, I think people will be fine with one solution for the project, as long as it's easy to rip out and replace if necessary.
That's why I'm suggesting having an Interface and an init-param that allows you to load a class implementing that Interface. Right now if multipart is not fixed/patched (see below) in 2.1.6 then we need to "carry" this patch forward to the new source tree if/when we use 2.1.6. This is in contrast to almost anything else (Generators, Serializers, Transformers) that we just fork off into our own namespace, patch or extend, and pull out of our own jar at run time.
I suppose we could fork the whole CocoonServlet.
Earlier someone noted the comment in the code about multipart/mixed. I am not an expert here, but when I looked into this some time ago, it was not supported by browsers. We do support multiple files per form using multiple input elements, so full conformance with the spec would be academic. Am I wrong here?
Geoff
Not academic; see http://issues.apache.org/bugzilla/show_bug.cgi?id=31067
We are using a script with "curl" to upload multiple files on one input element (this is for a list of images to a slide show style viewer).
