cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Modular database component
Date Tue, 20 Apr 2004 10:29:41 GMT
Christopher Oliver wrote:

> Reinhard Poetz wrote:
>
> <snip>
>
>> I already said in several mails that we should reduce the recommended 
>> options:
>>
>> 1.) Use O/R-mapper if possible
>> 2.) if you only have publishing tasks use the sqlTransformer
>> 3.) If the learning curve for an O/R-mapper is too steep for you take 
>> ????
>>     (In my opinion this is a simple DB-component as described below)
>>
>> What I want to tell all users clearly is that they should avoid 
>> writing SQL-statements. Integrating SQL in applications is the start 
>> of a maintainence nightmare and IMHO we should clearly warn them 
>> using XSP, Groovy or any other templating system requiring you to 
>> write SQL *into* the code. Once again, I really like e.g. JXTG but it 
>> should *never* contain SQL statements.
>
>
> Just wondering, is there any real difference between having say a 
> <for-each-row query="select whatever from whatever"> macro in JXTG and 
> SQL transformer? In fact, wouldn't JXTG be more useful for publishing 
> (since you can perform conditional branching and additional variable 
> substitution) than SQL Transformer?

In many cases JXTG would be more usefull.

> Or, if not then perhaps SQL transformer itself should be eliminated. 
> At any rate, shouldn't it be a generator rather than a transformer? 

We quite often generate SQL queries from configuration files written in 
XML, and in such cases XML->XSLT->SQLTransformer->..., becomes a quite 
convinient way to do things. In earlier discussions about scrapping the 
SQLTransformer it seemed like this is a fairly common use pattern. So I 
would be strongly against not having some kind of SQL transformer in 
Cocoon, I'm open for improvements of the SQL transformer though.

/Daniel



Mime
View raw message