cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: XSP and Cocoon2 Generators
Date Mon, 03 Apr 2000 19:36:59 GMT
Giacomo Pati wrote:
> Ricardo Rocha wrote:
> >
> >
> >
> > Briefly stated:
> >
> > A _dynamic generator_ can be loosely defined as an extension to
> > "ComposerGenerator" that is dynamically created, compiled and
> > instantiated at request time, based on the contents of a source
> > XML document.
> >
> > Generators are loaded and instantiated by _generator loaders_. Class
> > "GeneratorLoader" is an extension to "ComposerGenerator" that loads
> > other generators in order to delegate actual XML data generation.
> > Note that a generator loader may load any class implementing "Generator",
> > not only dynamic generators.
> >
> > "DynamicGeneratorLoader" extends "GeneratorLoader" to specialize in
> > building and instantiating dynamic generators in a language-independent
> > fashion.
> >
> > XSPGeneratorLoader is a concrete implementation of "DynamicGeneratorLoader"
> > that supports the XSP language.
> >
> > For code generation, XSP should use IBM's Bean Scripting Framework (BSF).
> I still have problems with the concept of the hole process. As I
> remember a request is processed as follows:
> request -> generator -+--------------+-> serializer -> response
>                       !-<- filter -<-!
> So, there is always ONE generator and ONE serializer. There are 0-N
> filters. If I look with one eye at the "pyramid model of web contracts"
> and with the other on the pipeline above, I would say that XSP has to be
> implemented as (a) filter(s), not as a generator. 

Why? (not questioning, just curious... it's great to have different

> In the Cocoon 1
> samples directory there is the clean-page.xml samples which I found make
> the correct process clear IMHO.
> request -> XSLT -> XSP -> HTML -> response
> This because if I am a german shop, I will have my XML-writers use
> german tags, transform them to XSP taglibs and then go thru the hole XSP
> machinery.

Makes perfect sense.
> There has also been discussions about putting the XSP engine into a
> sub-pipeline.

This is how it was resolved, AFAIK.
> request -> loader-generator -+--------------+-> serializer -> response
>             /            \   !-<- filter -<-!
>            /              \
>           /                \
>   generator -> xml2xsp_filter -> xsp_compiler        <== sub-pipeline
> But I've didin't checked what is the reason for sub-pipelines. I don't
> think it is for structuring the pipeline (I don't believe we will have a
> dozens of filters in a pipeline). And if it is for caching (a
> sub-pipeline ca be cached as a hole) I beleieve we can come around with
> other approches.
> If we can tell the cocoon system which resource (i.e. file) a part
> (generator/filter/serializer) of a pipeline uses, we can cache every
> intermediate result of the pipeline and restart the pipelining at the
> first step where a resource has changed. 

Yes, but maybe _very_ expensive in terms of memory usage. The use of the
double pipeline is to store _only_ the result of each pipeline and
forget about the rest (of course, stylesheets are different and _will_
be cached).

> If a part is dynamic (i.e.
> SQLFilter) we cannot specify a resource or have to specify a resource
> which changes very often (i.e. TIME) and the system has to restart the
> pipeline at least at this part using the intermediate result that was
> produced prior to this part. 

Normally the most frequently changeable point is the generator. So, you
waste a lot of resources by saving the intermediate points.

> But we can also specify a file resource to
> the SQLFilter part in the pipeline and touch that file in a nightly
> batch to make new results available to the requestors.
> request(URI=X) --> generator ---+--------------+--> serializer -->
> response
>                 !             ! !-<- filter -<-!               !
>                 V             V    V                           V
> CHACHE for X:   i1            i2   i3-iN                       i(N+1)
> I have great respect of the design Ricardo has made and if I've missed
> some discussion about that theme please update me.

Hmmm, I'm not exactly sure if I see your point... you say that you don't
think the use of sub-pipelines is necessary, is that right?

Well, while I agree with you that general sub-pipelining is probably a
bad thing (smells of FS too much), this is a not a subpipeline but a
special generator that reuses the cocoon engine to work.

But my best argument to compile an XSP page into a generator instead of
a filter is runtime performance: a generator spits events directly,
while a filter interprets events generated by something else.

Well, to be quite honest, the XSP Engine is both a filter and a
generator: it's a filter when compiles the XSP page, it's a generator
after the page is compiled.

Since this is the only component that has such different behavior, I
thought about using sub-pipelines as a way to go around the problem...
but I'm wide open to other solutions, as long as we don't loose run-time

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message