cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Rules for adding blocks and functionality?
Date Thu, 03 Nov 2005 15:53:14 GMT
Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>> Now, I find it rather strange to keep the SQLTransformer and ESQL 
>> because some people find them being the best way to do simple 
>> reporting at the same time as the community strongly oppose building 
>> a modern replacement of them in CTemplate, because they represent bad 
>> practice.
>> Anyway, for the time beeing I think it is better to focus on making 
>> it as easy as possible to use SQL from flowscripts and present the 
>> result sets in CTemplate. Then if we don't get it easy enough we can 
>> start to think about doing part of ESQL in CTemplate.
> SQLTransformer has at least three things going for it:
>   * It is declarative, it is not possible to program using
>     JDBC api or some other api in it.

Yes, OTH, it start to get clumsy when you need parameters to your 
queries. And users learn the hard way why updates in the SQLTransformer 
can be a bad idea.

>   * You can't access result set or statement or connection,
>     you are abstracted from database access code.


>   * It is scalable, it does not buffer complete result set
>     in memory.

IIRC, Ibatis and maybe other light weight JDBC embedings, provide lazy 
result sets, so by using such a library you can use a action script and 
JXTG combo without needing to buffer complete result sets.

> These all are good things (dunno how things in ESQL - have not looked 
> into it), and better than passing JDBC result set into the CTemplate.

Agree. My intesion wasn't to leave users with raw JDBC but to embed it 
with some utility functions that makes it easy to use.

> If you are interested in building a modern replacement for it, please 
> go ahead: propose a solution using CTemplate or Flow/CTemplate. I, for 
> one, would like to see a solution which preserves above two points of 
> SQLTransformer and is modern.

I'm interested in building a modern replacement, but blocks is higher on 
my priority list, so don't hold your breath ;)

> ... Seems to me such solution should have some CTemplate tag (unless 
> it is done in Flow) to query database and return a List type live 
> wrappers around ResultSet with limited functionality which can be 
> iterated over in CTemplate. And regarding pure CTemplate vs 
> Flow+CTemplate: "flowless" solution has own advantages in pure 
> publishing/reporting environments, and is the closest thing you can 
> have comparing with SQLTransformer.

I'd like to see an "action script"+CTemplate soultiion as scetched in my 
answer to Upayavira.


View raw message