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 Tue, 04 Apr 2000 18:10:57 GMT
Dear Ricardo. Thank you very much. This reply has opened my eyes to what
the system will do. I think I was too much fixated on the Cocoon 1

Ricardo Rocha wrote:
> Yes: during page generation, the XSP engine acts as a filter in that it
> applies one or more transformations (stylesheet-based code generation)
> to the input source document. Once the resulting source program has

Yes, now I can follow the discussion clearly. I was so blind ¦~/

> been compiled and loaded, though, the engine acts as a generator in
> that it doesn't use any preceding input from the pipeline and, instead,
> generates events directly from the compiled program.

Yeah, totaly clear.

> (Btw, the scenario presented by Giacomo, where XML writers use German
> tags that must be transformed into XSP taglibs, can be satisfied by XSP as
> a generator and even with the current Cocoon1 XSP implementation: it
> would suffice to append a final  "German-to-XSP" logicsheet that takes
> care of this particular transformation...)

I thought of an initial stylesheet transformation before the XSP taglib
to java transformation takes place.

> Let's provide some context to our discussion:
> Like any other server pages language, XSP processing has 2 phases:
> code generation and request delegation. During the "code generation"
> stage, XSP transforms the input xml document into an equivalent source
> program that is subsequently stored, compiled and loaded. During the
> "request delegation" stage, XSP simply passes the request to the
> generated program which will then produce the actual xml content.

This implies that
1) there is only one XSP (sub) pipeline at the very beginning of a
2) this (sub) pipeline has to take into account that specific
   (by the means of Italian/German/Spain->XSP) will be done before the 
   XSP->java translation stage and
3) this (sub) pipeline must be cached as a hole

> So far, XSP code generation has been achieved by means of a sequence
> of xslt transformations yielding a text-only root node containing a suitable
> source program.
> So far, our question has been: "should the XSP engine be implemented as a
> generator or as a filter?".

If the XSP engine is the proces of transforming a xml document to a java
object, then as a (sub) pipeline.

> Let's extend this question to include: "what component type does a generated
> XSP page implement?"
> Is a generated XSP page a filter? Clearly not: it does not process any incoming
> input. On the contrary, it's meant to be the source of a pipeline because it's
> directly derived from the source xml document and is guaranteed to encode all
> of such document's content (as augmented by its embedded logic-based tags)
> Clearly, a generated XSP page is a generator. More specifically, it's a
> _dynamic_ generator, meaning that it's not statically defined in Cocoon's
> sitemap, but rather dynamically located and instantiated at request time.
> Independently of their dynamic nature, XSP pages are generators and, as
> such, must come first in the processing pipeline.
> Which leads us to the second stage: request delegation.
> During request delegation, the XSP engine necessarily acts as a generator:
> a generator capable of locating/generating and subsequently transferring
> control to another (dynamic) generator which actually feeds the pipeline with
> XML data. This is what in my proposal I call a DynamicGeneratorLoader.
> Now, all this does not invalidate what I believe to be Giacomo's main (and
> valid) point: xslt-based code generation is clearly a case of filtering...
> Here's where sub-pipelining comes into play: we can (and should) reuse
> Cocoon's machinery to perform an otherwise regular xslt transformation of
> the input XSP document in order to yield a source program implementing
> DynamicGenerator.
> [A bit of self-criticism is in order here: something I dislike about the current
> XSP implementation is that  instead of reusing Cocoon's machinery for its
> code generation purposes, it applies logicsheets using its own pipelining
> caching and reloading. This sucks!]
> A better approach is the proposed sub-pipeline mechanism where a dynamic
> generator loader (among other possible candidate users) can recursively
> invoke Cocoon's request handling machinery to delegate the task of
> generating source code.
> This isn't the only case in which such a mechanism is called for; we also
> have what Stefano has dubbed "the old tune" of Cocoon sub-requests:
> the ability to embed the result of another Cocoon request into the current
> pipeline.
> The current XSP implementation provides [very] limited support for this: you
> can embed any well-formed XML fragment coming from any url. This
> mechanism, though, incurrs in  the potentially unacceptable overhead of
> generating another Http request...
> XSP in Cocoon2 should provide a "native" mechanism to perform such
> recursive inclusion without incurring in additional Http request overhead.
> This inclusion mechanism should come in 2 flavors: compile-time (to aid
> in the compilation process) and request-time (to provide for "normal"
> runtime inclusion). Of course, both variants should relay on xinclude...
> Likewise, Donald's XInclude filter may well provide an optimization to
> determine whether a given inclusion can be satisfied by the current
> Cocoon instance.
> Given this optimization, sub-pipelining could always be seen simply as
> a case of XInclusion.
> A desirable side-effect of this approach is that Cocoon would cache
> the intervening logicsheets thus resulting in something similar to what
> Giacomo would like to see: restarting the code generation [sub]pipeline
> only at the proper changeable point...
> Regards,
> Ricardo

Yes, now that the light has been turn on for me, I've swallowed the
explanaitions Ricardo has given above.

Ok, where do we start implementing it? I've still some spare time to
invest here!


View raw message