cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: XSP and Cocoon2 Generators
Date Mon, 03 Apr 2000 07:48:36 GMT
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. 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

There has also been discussions about putting the XSP engine into a

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


PWR Organisation & Entwicklung            Tel:   +41 (0)1 856 2202
Giacomo Pati                              Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7           
CH-8166 Niederweningen                    Web:

View raw message