cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Make status code attribute of seriailzers expandable
Date Fri, 30 Mar 2007 12:09:19 GMT
Ard Schrijvers napisaƂ(a):
> Hello,
>> Don't you have two distinct pipelines for rendering pages with forms
>> included and without? I don't details of your use case but IMO it is
>> good practice to have two distinct pipelines and decide in flow which
>> one should be used.
> we rely on repository sources where the customer (the cms user) defines wether or not
a form is on the page, so, no...we cannot know in our main pipeline what the headers should

I see, it's classical example of situation where conditional (condition
based on processed content) pipelines would be very helpful.
Unfortunately, we don't have them (yet?).

>> Nevertheless, if you know in flow how headers should be set, why don't
>> set them there?
> Then they only are set on the pipeline calling this flow, and according [1] these are
lost in the main pipeline

COCOON-1619 is not bug IMO. It's just part of contract that internal
pipelines are serve some data and do not interfere with original
request. I think that was valid design decision at the time whole stuff
was created.

Now, the same problem applies for postable sources and servlet services.
I've been thinking about it for a while and came to conclusion that
information about result of processing (status code, various http
headers) should be collected from all internal requests and even from
pipeline components, prioritized and then information put into HTTP
response should be calculated from these collected parts. Priorities
would be assigned automatically based on simple rules like: when main
pipeline and internal pipeline want to set the same header, main wins;
when pipeline and pipeline's component want to set the same header,
component wins etc.

It's important at design level, see my comment here:

Current situation where all components and pipelines have write access
to whole environment is really bad because leads to the situation
described in comment above. What do you think?

Grzegorz Kossakowski

View raw message