Hi all,
We have seen some very interesting discussions about XSL as serializer.
Probably most of you are tired of another architectural discussion. But
for those who love some 'verbal action' I will tell you my experiences
with Cocoon. Sorry for the lengthy story.
I am an experienced Cocoon user and also created some complicated new
Transformers for our XML Server product. There were two major problems
with Cocoon I encountered:
1. only one generator allowed per pipeline
2. selectors are evaluated before the pipeline is executed
1. only one generator allowed per pipeline
At forehand I want to make clear that I agree with the basic components
of a pipeline: Generator, Transformer and Serializer.
Think about the following very common pattern with Web requests:
- do something in a backend system (e.g. insert a record in a database)
and on success return a new unrelated piece of HTML
Suppose the data of the client does not have XML but only request
parameters. Now map this to Cocoon:
- generator that builds the SQL query using request parameters
- SQL transformer (adjusted to throw an exception on error)
- XSLT that creates a new piece of HTML unrelated to the previous
transformer (template match='/')
- serialize
Now to me the first generator is already a farce. I made an SQL
transformer that simply accepts the query as parameter in stead of using
the XML stream. Now if you look at this pattern from a higher
perspective you want to code this as follows:
- SQL transformer
- XML generator (no need to use an XSLT file)
- serialize
So this means we should allow:
- not to have a generator at all (yes I thought about the consequences)
- and allow for a generator after a transformer which will simply close
the previous stream and open a new one
In other words: the concept of a NOP generator and the concept of more
than one serializer-transformer stream in one pipeline. This will still
keep the definition of the three concepts in place but makes them less
rigid:
- 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
Related to this issue is the Cocoon Aggregate statement. It is very
limiting that in Cocoon you must start with the aggregate. Why is the
following patterns not allowed:
- start a stream (e.g. document plus metadata)
- aggregate
- part 1: transforms the stream (e.g. index based on metadata +
document title)
- part 2: transforms the stream (e.g. document itself where links
became HTML anchors)
- serialize
I know this is a separate issue. If the Aggregate concept was mapped to
the Transformer concept, it could work. But also here you can see the
rigid implementation of the three basic concepts. Because a Part points
to another pipeline, and a pipeline always starts a stream, the
aggregate cannot take the existing stream into account.
People solve these limitations by using multiple pipelines, most of the
time with xinclude of cinclude. In that case the transformer basically
becomes a generator. It is clear that this is a workaround. Also note
that you will loose the {0}, {1} values of the orignal URI when you call
another pipeline.
My solution for our product is that all components are transformers and
I have a standard NOP generator (if the client does not send XML). But I
would like to use the standard Cocoon generators...
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.
In short: I want to be able to choose different transformers depending
on the elements/attributes placed in the stream by the previous
transformer.
Thanks for your patience.
Kees
