Now to me the first generator is already a farce. I made an SQLtransformer that simply accepts the query as parameter in stead of usingthe XML stream.
I always thought it would be better to have a sql query being executed *before* the transformation starts. So from that point of view this does makes sense. Altough... having sql statements inside the sitemap! *shiver*
So this means we should allow:- not to have a generator at all (yes I thought about the consequences)
? <snip/>
- generator: starts a new stream (thus ignoring previous stream if present)- transformer: changes a stream (which could be empty at the beginning)- serializer: ends the stream
And what about the root tag? You want to keep the pipeline well-formed. Sorry, not excited here.
Related to this issue is the Cocoon Aggregate statement
Have a look into the cinclude transformer <snip/>
2. selectors are evaluated before the pipeline is executed This basically means you can select on global, request and session fields because these are already set. But of course you also want to react on XML values in the stream. That is what you expect from an XML pipeline architecture.
Cocoon is *streaming* the XML through the pipelines. That's what you would expect from a today's XML pipeline architecture ...which is also the reason why you cannot react on XML values inside the stream from the sitemap level without buffering the whole process.
In short: I want to be able to choose different transformers depending on the elements/attributes placed in the stream by the previous transformer.
Maybe you want to have a look into cocoon 1 :-P cheers -- Torsten
PGP.sig
Description: This is a digitally signed message part
