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 previoustransformer (template match='/') - serializeNow 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 placeholders.
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 ;-) )
Joerg
