cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: AW: cvs commit: xml-cocoon2/src/org/apache/cocoon/serialization BlockingSerializer.java
Date Tue, 22 May 2001 05:10:49 GMT


On Mon, 21 May 2001, Sylvain Wallez wrote:

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

It's as simple as I've already told.  Each <map:pipeline> can have a
<map:hadle-error> element. Nothing more and nothing less (except the
internal-only attribute). It's up to you if you use one big
<map:pipeline> block or several little ones to separate it.

Giacomo

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


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


Mime
View raw message