Joerg Heinicke wrote:
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.
You should not be using SQLTransformer at all - please take a look at Flow and
ORM tools as others pointed out already.
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.
There are perfectly valid scenarios where SQLTransformer is best tool for the
job, and attemps to use 'model' layer fail (well, unless you consider ResultSet
as a model ;-)). Streaming down large amount of data from the database
(especially exceeding available memory) is one of them. In this case, it's
impossible to process all database results in the model tier and pass it on to
the view tier.
OTOH, trying to do application business logic using SQLTransformer is
anti-pattern, and that's where you must go for MVC architecture.
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.
Yep.
<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.
In short: I want to be able to choose different transformers depending
on the elements/attributes placed in the stream by the previous
transformer.
Forget it - this is another huge anti-pattern.
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 ;-) )
Yep.
Vadim
