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.
I read your reference and Stefano's proposal. I agree with the concept of having request interceptors, but I am not sure I agree with his syntactic proposal. In particular, it requires the creation of yet another type of sitemap component, meaning that it is heavily integrated into the Cocoon core. Why is that necessary?
Despite your characterization of Actions (below), I think they are a valid method for providing "cross cutting" functionality in a lightweight fashion. They don't require a user to implement PipelineNodes and all that jazz. And if the functionality proves to be stable and useful, then you can "harden" it into more formal syntax.
The problem with Actions is that while they're flexible and lightweight, they cannot have access to all the parts of a pipeline that a Node can. I lean toward allowing an Action to tell the Environment to replace its Request object, allowing it to do the SOAP/DAV/upload processing in the Action. Yes, this can allow people to shoot themselves in the foot. But I think the benefits outweigh the risk.
Otherwise, a valid "hack" would be to have an Action that processed the multipart stream (like StreamGenerator) but which put its Parts under the RequestAttributes (the only part of the Request it's allowed to manipulate). Downstream components would then have to get the parts from the Attributes, not Params, but that'd be a contract to observe, nothing special.
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.
