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
