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? Or, if not then perhaps SQL transformer itself should be eliminated. At any rate, shouldn't it be a generator rather than a transformer?
I think the question is what you need it for: I believe that people writing *applications* using Cocoon shouldn't have to write SQL statements in their code. There are easier, and *more maintainable* solutions (O/R-mapper). If people use Cocoon for *publishing*, I think the situation is different and your proposal makes perfect sense.
It will be very interesting in the next months with all those efforts to generate XML (Groovy, Tempo, ...).
- o -
Pls, don't get me wrong. I don't want to prevent anybody from developing any new way to generate XML in Cocoon. I _only_ want to find a clear statement within the Cocoon community which is the *recommended* way doing it and *why* we think so because at the moment we have to many options accessing DBs and generating XML without clear statements.
-- Reinhard
