cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luigi Bai <lpb+coc...@focalpoint.com>
Subject Re: [rfc] commons fileupload replacement
Date Mon, 08 Nov 2004 20:16:45 GMT


On Mon, 8 Nov 2004, Geoff Howard wrote:

> On Mon, 8 Nov 2004 08:20:56 -0600 (CST), Luigi Bai
> <lpb+cocoon@focalpoint.com> 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.

Mime
View raw message