cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [rfc] commons fileupload replacement
Date Tue, 09 Nov 2004 01:44:52 GMT
On Mon, 8 Nov 2004 14:16:45 -0600 (CST), Luigi Bai
<> wrote:
> On Mon, 8 Nov 2004, Geoff Howard wrote:
> > On Mon, 8 Nov 2004 08:20:56 -0600 (CST), Luigi Bai
> > <> wrote:

> 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?

Well, not really.  While sitemap statements are often also components
I don't think they always are or need to be IIUC.  At the end of the
day, they are nodes recognized by the tree processor.  We have no
construct (including actions) which allow the raw request object
(besides attributes) to be modified, or re-interpreted in any way.  To
grant this power to existing sitemap elements would be dangerous (in
the sense of ripe for abuse or confusion).

> 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.

To clarify, once the proposed "adapt request" support exists, we would
almost certainly bundle and configure by default the very few
capabilities which would require it - multipart file handling would
almost certainly be part of this.  So, users wouldn't have to
implement PipelineNodes unless they had some unique new requirement or
wanted to write an alternative.  Further, this would likely be a
fairly simple contract anyway.

> 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.

:) Most would say that the problem is that Actions have access to too much!

I think though that we're just on some semantics based on the way you
have mentally categorized actions.

Again, the problem as I understand it with actions is that they: 
1) Can perform back-end "actions".
2) Can decide between alternate paths/steps in the sitemap.  
3) Can also completely redirect the request
4) Can also return values back to the sitemap which can trigger later
decision points using any other sitemap directive.

None of these are bad in them selves - it's the mixing of all of them.
 Adding the ability to modify the way in which the request is made
available to later steps in processing would only muddy things

> 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.

I think this is why this needs to be handled deeper in the core (the
request adapting, not necessarily the multipart parsing).  And to
reiterate, would then not need to be re-done by people (just as it is
not now re-done by everyone needing to use multipart uploads) but
rather just utilized.

Anyone care to chip in with a path forward?  Can we do "adapt-request" now?


> >> 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.

View raw message