cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <>
Subject Re: SQLTransformer
Date Sun, 04 Sep 2005 23:12:52 GMT
Daniel Fagerstrom wrote:

> Torsten Schlabach wrote:
>> Hi all,
>> I have done some work with and on SQLTransformer recently and came 
>> across
>> one fundamental question, that I would appreciate some views on.
> ...
>> In situations, where you would want to build a more generic data 
>> browsing
>> application that makes use of the database metadata to extract 
>> information
>> about the data (in ohther words: you don't know the fieldnames 
>> upfront) it
>> would be much cleaner if the XML generated would read:
> ...
> This have been discussed for years but not resulted in much code. What
> you ask for can rather easily be done in ESQL (an XSP library), IIRC.
> But XSP is hard to maintain and develop new functionality in due to 
> its design, so we don't recomend people to use it anymore.
> There have also been various proposals to move ESQL functionality to the
> SQLTransformer, but no action.
> One camp have been so entusiastic about OR tools that they don't think
> that there is a need for things like the SQLTransformer at all,
> Hibernate should be used instead.

I will suggest OJB instead -
I was working on a hibernate the last weeks and I need to say that I 
prefer OJB. Here 2 samples:

1-When using a java List for a collection inside a bean, in Hibernate 
the table need an additional field to manage the order of the table 
rows! What is that?
2-I don't want in my database more fields than what I need, so let 
replace the Java List witth a Java Set --> then I meet a new problem: 
cforms binding use jxpath and jxpath don't work with Sets. jxpath throws 
an Unsupported Operation Exception! Boom!

I wonder how people using hibernate deal with this situations. The 1st 
shows me a poor database desing and the second a restriction to use 
cforms at all! In my case I prefer to stay on the OJB side and stayt 
away of this silly problems.

> When we refactored JXTG, I designed it in such a way so that it should
> be easy to add new sets of instructions to it, I did this in particular
> to be able to reimplement ESQL as instruction tags usable within JXTG.
> Then we had a long debate where some people where strongly against
> allowing such things in JXTG, see

> for links to the discussions.

Yep. We believe JXTG is not XSP. ;-)

> In
> Sylvain give some ideas about how to replace ESQL and in
> Stefano gives his view. Both suggest, from somewhat different
> perspectives that the query should be prepared in the controler (e.g.
> flowscripts) and that the result set should be itereated through in the
> view (e.g. JXTG).

I agree with the Stefano POV. This is the way I an working and believe 
me my

> Now, having written plenty of webapps that use tons of queries performed
> in the SQLTransformer, I'm of the opinion that the SQLTransformer is a
> rather convenient way of handling low to intermediate compleity SQL
> applications. And it would be even more convenient to embed the queries
> in JXTG. And it would be fairly easy to implement the needed 
> instructions.

See the Stefano's solution above.

I have been developing applications with Cocoon and OJB for 2 years now. 
IMO O/R mapping offer far more features than SQLTransformer and . I hear 
people telling there is too much work to create and O/R mapping. IMO 
this is FUD. In fact a O/R mapping need less work or at least the same 
amount of work or less in more complex applications. here I explained 
how easy is to work with this an OR mapping:

More on this here:

>                        --- o0o ---
> To sum up, I find it rather unsatisfying that we don't have "modern" and
> convenient solution for simple SQL reporting. I'm certain that OR tools
> are fantastic in some cases, but they are IMO overkill for simple
> reporting applications. Both ESQL and the SQLTransformer are somewhat
> unconvenient to use, although in different ways.

Please, never understimate the power of a O/R mapping tool! ;-)

> IMO we should either provide JXTG instructions for SQL reporting or give
> some kind of support and examples on how to use SQL with query
> preparation in the controler and report construction in the view layer,
> (following Sylvain's or Stefano's sugestions).

The 1st option is not a solution is only a workaround. The worse is that 
I see that as a return to the old complexity and mix of concerns. Seems 
to be not a good idea.

I prefer the 2nd option: give some kind of support and examples on how 
to use SQL with query
preparation in the controler and report construction in the view layer. 
Maybe someone in GT2005 can do a presentation on this topic. I remember 
that Bertrand showed some of his work related to this way of doing 

Best Regards,

Antonio Gallardo.

View raw message