cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Architectural concerns
Date Wed, 10 Aug 2005 22:47:21 GMT
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

Mime
View raw message