cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Input Pipelines (long)
Date Thu, 09 Jan 2003 19:14:28 GMT
Michael Homeijer wrote:

> Until this thread started I thought about the flowscript layer to be usefull
> for "inter-request" flow (mainly continuations). Not for composing the logic
> that handles a request. 

If you think at input and output as two different stages of the same 
resource, then it makes sense to drive them thru the flow layer... 
instead of complicating the sitemap logic unnecessary.

> I'm still not sure... just a gut feeling. 

I'm not sure either :) but I feel that everything that makes the sitemap 
loose declarativity is actually conflicting with the flow layer.

> The application logic and exceptions I mentioned should be able to influence
> the flow through the pipelines, not be mixed with the content of the
> pipelines, and IMHO certainly not break it in the case of an application
> exception.

Yes, I see that. Do you believe that my proposals don't fit your 
requirements?

> I only meant as a sample that the two pipelines should be logically
> disconnected. Some examples I have seen transform and process input and in
> the process mix output and generate the output html.
> For instance 
> "request generator" - "transform" - "write source" - "transform into output
> (maybe by aggregation)" - "serialize".
> This can be done, but mixes a lot of concerns, and how about a pipeline that
> validates the input, writes to a source, mails a result to the user and
> generates an output message, where the mail is optional and can be
> configured.
> 
> 
>>Wouldn't flow/pipeline and let you assemble them at need suffice?
> 
> 
> I can not oversee the consequences of such a change. This would mean that a
> pipeline consists of flow that glues together a number of
> sub-pipelines/flows? Maybe.
> 
> My main problem is that in the current Cocoon version, a pipeline once setup
> can hardly be influenced by some kind of control flow. 

Yes, we have identified this weak architectural point in the other 
thread about input pipelines and I'm all for solving it... but I still 
have to figure out what this means and hot it impacts the whole picture.

> And that mixing EJB
> input / output, application exceptions and SAX makes things even more
> complicated. Or should I say a challenge :-) 
> 
> I haven't seen a clean solution that made me jump in the air (which the
> pipeline concept and the block concept did when I realised what they meant).
> I'm hoping you have some more up your sleeve ;-)

Hey, don't challenge me, boy :)

No, serious, I don't have a magic clearcut solution to the problem... 
but I have a gut feeling that it's better to add procedural logic to the 
flow on how to use the declarative facilities provided by the sitemap, 
than the other way around.

but I think i need to get my hands dirty and do something to see which 
method fits best.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message