You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <Gi...@pwr.ch> on 2000/04/03 09:48:36 UTC
Re: XSP and Cocoon2 Generators
Ricardo Rocha wrote:
>
> http://www.casewaresa.com/~ricardo/dynamic-generators.html
>
> 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
machinery.
There has also been discussions about putting the XSP engine into a
sub-pipeline.
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 -->
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.
Giacomo
--
PWR Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: XSP and Cocoon2 Generators
Posted by Giacomo Pati <Gi...@pwr.ch>.
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
machinery.
Ricardo Rocha wrote:
>
<snip/>
>
> 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.
>
<snip/>
>
> (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
pipeline,
2) this (sub) pipeline has to take into account that specific
translations
(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.
>
<snip>
>
> 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!
Giacomo
Re: XSP and Cocoon2 Generators
Posted by Stefano Mazzocchi <st...@apache.org>.
Ricardo Rocha wrote:
> 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...
I totally agree.
> 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.
yes, but keep questioning yourself about FS.... I see great dangers
here: the more paths you give to people to more trouble you have to
explain them and understand which one is the best.
Altought, I agree that we cannot possibly limit XInclude capabilities to
non-cocoon URIs and the internal Cocoon URIs should be dealt with
inside, not going back to the web server.
> 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...
yes, but, instead of scattering the cache hooks across all the pipeline,
the system knows it must cache only the result of an appropriate
pipeline.
Small point, but, to me, it appears very design-significant.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: XSP and Cocoon2 Generators
Posted by Donald Ball <ba...@webslingerZ.com>.
> Likewise, Donald's XInclude filter may well provide an optimization to
> determine whether a given inclusion can be satisfied by the current
> Cocoon instance.
Indeed, this is just what Zisch was proposing a few days ago. There's not
support in the Sitemap for internal requests for a URI request to be
serialized as SAX events, but I hope that I can convince Pier that it'd be
worthwhile to add it.
- donald
Re: XSP and Cocoon2 Generators
Posted by Ricardo Rocha <ri...@apache.org>.
On Mon, 03 Apr 2000, Giacomo Pati wrote:
> 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.
> 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.
On Mon, 03 Apr 2000, Stefano Mazzocchi wrote:
> 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.
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
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.
On Mon, 03 Apr 2000, Ben Laurie wrote:
> Then a generator is just a degenerate filter. You feed it <go/> and it
> spits its events.
This seems to imply that XML _files_ are the _only_ legitimate source of
SAX events... just kidding :-)
I'd say that only DynamicGenerators (not generators at large) are subject to
this interpretation, but I disagree it's a degenerate case: XSP pages, for
instance, are first-class generators where some or all of the event sources
are logic-based.
(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...)
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.
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.
Of course, this is not the only possible mechanism for code generation. In
my proposal for Cocoon2 dynamic generators, I define a "SourceCodeGenerator"
abstraction that is not tied to this or any other plausible implementation strategy.
Castor (http://castor.exolab.org), for instance, uses a purely object-oriented
approach in which the target Java class is explicitly represented as an object,
with properties representing superclasses, methods, fields and the like. This
approach shines when used for a specific target language and a "stable"
object type. It can be a bit expensive, though, when you intend to support
multiple programming languages as well as multiple target object types.
XSP, on the other hand, has followed a pattern rooted in the old Unix tradition
of using preprocessors for source code generation (e.g. m4). This approach
is also fully consistent with xml's own layered transformation philosophy as
embodied in xslt...
Here, dynamic tags are expanded to equivalent source codelets by using xslt's
regular template matching mechanism. While some perceive this sort of
transformation as a degenerate case yielding a big text node enclosed in a
single root element, I think it's a valid general approach for markup-to-text
transformations (e.g. generating RTF from xml).
Returning to our subject, it's this in area (namely, xslt-based code generation)
and in this area alone where we could see XSP implemented as a filter: a
sequence of zero or more xslt stylesheets are applied to a source xml document
(in a well-defined order) to yield a source program that is to be subsequently
instantiated.
Right after this stage, the filter similitude vanishes: once the program is ready
for execution, it becomes a first-class generator "spitting events" (as Stefano
puts it) to be consumed by the remaining pipeline and without depending on
any preceding xml input.
Granted, one might rephrase the logicsheet-applying process as a sequence
of pipeline xslt filters preceding "true" XSP processing. This is, afaiu, what
Giacomo proposes.
However, this necessarily calls for a more granular pipeline-step caching
mechanism where the result of each step is cached and made dependent on the
underlying resources (xml source document, xslt logicsheet) so that whenever
any of them changes, the pipeline is restarted from that point on:
On Mon, 03 Apr 2000, Giacomo Pati wrote:
> 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.
On Mon, 03 Apr 2000, Stefano Mazzocchi wrote:
> Yes, but maybe _very_ expensive in terms of memory usage. The use of
> thedouble pipeline is to store _only_ the result of each pipeline and forget
> about the rest (of course, stylesheets are different and _will_ be cached).
[Hmmm... Let's keep in mind that logicsheets _are_ stylesheets...]
I agree with Stefano that the cost of keeping intermediate results can be way
higher than that of rebuilding the XSP program when needed.
Besides, the XSP engine must be able to reload generated programs _across
Cocoon invocations_, a scenario in which we don't care so much about
intermediate results as we care about the end product (e.g. a compiled Java
class) being current.
So far, our question has been: "should the XSP engine be implemented as a
generator or as a filter?".
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
Re: XSP and Cocoon2 Generators
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Ben Laurie wrote:
>
> Stefano Mazzocchi wrote:
> > 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.
>
> Then a generator is just a degenerate filter. You feed it <go/> and it
> spits its events.
Well... More or less it is... In the vision of XML data
production/consumption (the basic interfaces used by Cocoon to deal w/
SAX events, the first indicating a source of XML events, and the second
indicating the target of those), the three components are:
- Generator extends XMLProducer
- Filter extends XMLProducer, XMLConsumer
- Serializer extends XMLConsumer
I'd still prefer, anyway, to see filters as "degenerate generators", and
not all the way around...
Pier :)
--
----------------------------------------------------------------------
pier: stable structure erected over water to allow docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
----------------------------------------------------------------------
Re: XSP and Cocoon2 Generators
Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
>
> On Tue, 4 Apr 2000, Ben Laurie wrote:
>
> > Stefano Mazzocchi wrote:
> > > 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.
> >
> > Then a generator is just a degenerate filter. You feed it <go/> and it
> > spits its events.
>
> Ha! Everyone loves a smart aleck. :) Good point though.
Of course. I draw the design patterns one again:
- producer
- consumer
then
- generator = producer
- filter = producer + consumer
- serializer = consumer
what "degenerate filter" means is that "filter extends producer" and
you're totally right.
Small point, I concur, but we should try to separate the design patterns
as much as we can and enforce them with java interfaces whenever
possible.
Using something as "degenerate something-else" is not good practice,
IMO.
Even if I agree that from a development point of view it may not change
anything.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: XSP and Cocoon2 Generators
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 4 Apr 2000, Ben Laurie wrote:
> Stefano Mazzocchi wrote:
> > 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.
>
> Then a generator is just a degenerate filter. You feed it <go/> and it
> spits its events.
Ha! Everyone loves a smart aleck. :) Good point though.
- donald
Re: XSP and Cocoon2 Generators
Posted by Ben Laurie <be...@algroup.co.uk>.
Stefano Mazzocchi wrote:
> 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.
Then a generator is just a degenerate filter. You feed it <go/> and it
spits its events.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Re: XSP and Cocoon2 Generators
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 5 Apr 2000, Ben Laurie wrote:
> Stefano Mazzocchi wrote:
> > Flexibilty Syndrome, an anti-pattern that I defined to express the
> > dangerous idea that "if you do '1', '2' and '3', you should do 'n'"
>
> Isn't that just feature creep?
Naw, it's more the idea that if you have a hammer, everything looks like a
nail. or a pane of glass, depending on your personality.
- donald
Re: XSP and Cocoon2 Generators
Posted by Ben Laurie <be...@algroup.co.uk>.
Stefano Mazzocchi wrote:
> Flexibilty Syndrome, an anti-pattern that I defined to express the
> dangerous idea that "if you do '1', '2' and '3', you should do 'n'"
Isn't that just feature creep?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Re: XSP and Cocoon2 Generators
Posted by Mike Engelhart <me...@earthtrip.com>.
Eric SCHAEFFER wrote:
> In Perl, there's no interface but you can (really) use regular expressions...
>
> Eric.
> ( Perl is beautiful :-p )
Therefore, PerlTools from (www.savarese.org) is even better
:-)
Mike
Re: XSP and Cocoon2 Generators
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
----- Original Message -----
From: Giacomo Pati <Gi...@pwr.ch>
To: <co...@xml.apache.org>
Sent: Tuesday, April 04, 2000 9:56 PM
Subject: Re: XSP and Cocoon2 Generators
> >
> > Guess why I don't like Perl :)
>
> Sometimes it's good enought for doing quick hacks, you know (scripts you
> only use once or twice)!
>
> Giacomo
In Perl, there's no interface but you can (really) use regular expressions...
Eric.
( Perl is beautiful :-p )
Re: XSP and Cocoon2 Generators
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi wrote:
>
> Giacomo Pati wrote:
>
> > There is always a balance between used resources and achieved
> > performance. You do database denormalization because of performance as
> > well but it costs you disk space and managment efforts. And a cache
> > system as I've mentioned below will end up serving static pages most of
> > the time.
>
> Absolutely correct. In fact Cocoon has a cache even if both the web
> server and a proxy down the road should/would perform better caching.
> And does indeed help. But you don't create a thousands of index keys on
> your tables for every possible unique row, don't you? This is my point.
Yes I know (sigh). You're absolutly right! :-)
>
> > > > 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.
> >
> > I can't verify that so you might have probably right ?-)
>
> I can't either, so I might be wrong :) But it appears as a reasonable
> guess to me.
Ok.
>
> > > 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.
> >
> > [What's FS]
>
> Flexibilty Syndrome, an anti-pattern that I defined to express the
> dangerous idea that "if you do '1', '2' and '3', you should do 'n'"
Ok, now I'm up to date and it make sense to me too.
>
> Guess why I don't like Perl :)
Sometimes it's good enought for doing quick hacks, you know (scripts you
only use once or twice)!
Giacomo
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
--
PWR Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: XSP and Cocoon2 Generators
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
> There is always a balance between used resources and achieved
> performance. You do database denormalization because of performance as
> well but it costs you disk space and managment efforts. And a cache
> system as I've mentioned below will end up serving static pages most of
> the time.
Absolutely correct. In fact Cocoon has a cache even if both the web
server and a proxy down the road should/would perform better caching.
And does indeed help. But you don't create a thousands of index keys on
your tables for every possible unique row, don't you? This is my point.
> > > 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.
>
> I can't verify that so you might have probably right ?-)
I can't either, so I might be wrong :) But it appears as a reasonable
guess to me.
> > 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.
>
> [What's FS]
Flexibilty Syndrome, an anti-pattern that I defined to express the
dangerous idea that "if you do '1', '2' and '3', you should do 'n'"
Guess why I don't like Perl :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: XSP and Cocoon2 Generators
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi wrote:
>
> Giacomo Pati wrote:
> >
> > Ricardo Rocha wrote:
> > >
> > > http://www.casewaresa.com/~ricardo/dynamic-generators.html
> > >
> > > 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
> visions)
I was fixated at the Cocoon 1 mechanics!! (clean-page.xml):-! (see reply
to Ricardos answer)
>
> > 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).
There is always a balance between used resources and achieved
performance. You do database denormalization because of performance as
well but it costs you disk space and managment efforts. And a cache
system as I've mentioned below will end up serving static pages most of
the time.
>
> > 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.
I can't verify that so you might have probably right ?-)
>
> > 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.
[What's FS]
>
> 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
> performance.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
--
PWR Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: XSP and Cocoon2 Generators
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
>
> Ricardo Rocha wrote:
> >
> > http://www.casewaresa.com/~ricardo/dynamic-generators.html
> >
> > 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
visions)
> 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
performance.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------