cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Architectural concerns
Date Wed, 10 Aug 2005 22:28:52 GMT
On 10.08.2005 11:18, Kees Broenink wrote:

> 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

This shows exactly that the SQLTransformer is "problematic" or in other 
words "not best practice". Try to map Cocoon to a MVC scenario and you 
see that you should first build your model and retrieve it in a 
generator. The SQLTransformer breaks this concept. But IMO it is not 
showing that Cocoon's pipeline concept as it is now has limitations. 
Jens already pointed to flow, that makes it easier to see Cocoon as 
player in a MVC concept.

> Related to this issue is the Cocoon Aggregate statement.


> If the Aggregate concept was mapped to the Transformer concept, it
> could work.

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

I don't agree with you. It's neither a generator nor a workaround. IMO 
the concept of an aggregating aka including transformer id really clear. 
The cleanness or "rigid implementation" is the most simple concept and 
allows highest reuse.

> Also note that you will loose the {0}, {1} values of the orignal URI
> when you call another pipeline.

On the one hand you can pass them (which is more effort than just having 
them of course), on the other hand you need more than just these 

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

Besides the streaming mentioned by Torsten: This is even worse than the 
proposed TraxSerializer, the pipeline would be not predictable at all. 
And from the point that even biggest systems work quite well with Cocoon 
it's probably only FS.
(These systems might work (and be maintainable) only because Cocoon 
pipelines are based on clean and simple concepts ;-) )


View raw message