cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: AW: cvs commit: xml-cocoon2/src/org/apache/cocoon/serialization BlockingSerializer.java
Date Mon, 21 May 2001 13:31:15 GMT


Carsten Ziegeler a écrit :
> 
> Hi,
> 
> I am not quiet sure if this BlockingSerializer is really needed.
> We already have the "internal pipelines" which work very well
> for "hiding resources" together with the content aggregation.
> 
> The BlockingSerializer comes into action a step later, which
> means the pipeline for the resource is build and all components
> for this pipeline are invoked. This includes all actions for this
> pipeline are called, the generator and the transformers are
> setup etc. And after that all has already happened an exception
> is thrown. So the behaviour you get for those pipelines is
> that some code of the pipeline is executed and some not. Imagine
> an action which puts data into a database. This is executed
> also you have the blocking serializer. You really don't want
> that.
> 
Mmmh... you're right. I didn't test it on pipelines with actions.
Content generation is disabled, but actions are executed, which I admit
is bad. I thought to have found a simple way of specifying internal URIs
at the matcher level (see below).

> I think this not the right way to go, sorry.
> We should remove it as we already have the working internal
> pipelines which prevent the whole pipeline from being executed.
> 
> Comments?
> 
> Carsten
> 
Well, I still have problems understanding the exact role of
map:pipeline...

Basically, I understand map:pipeline as set of URI (defined by the
matchers) that define an "area" of the application. With this meaning
(am I wrong ?), having internal-only on map:pipeline means you have to
split an application area in 2 pipelines : one for externally accessible
URIs and one for internal URIs, used by external ones (or else they're
useless). Then comes a readability problem when you have a large sitemap
: related matchers are spread across the file and that's why I wanted to
be able to restrict access at the matcher level.

So, several questions come out :
- is map:pipeline intended to define an application area, or is it more
the role of sub-sitemaps ?
- in C2 samples, why are subsitemaps mount points placed in separate
pipelines, since subsitemaps have their own pipelines ?
- wouldn't it make sense to specify the internal-only flag at matcher
level (which is what I wanted to achieve with this BlockingSerializer) ?
- is an error-handler useful for internal-only pipelines ?
- what's the cost of a pipeline in the sitemap? Is it just a try/catch
block ?

Thanks for clarifying all this. It may become the starting point of the
sitemap FAQ :)

Cheers
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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


Mime
View raw message