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?
In my personal opinion, we absolutely must have both a SQL Transformer and SQL Generator with basic scripting (be it JXTG, ESQL, USQL, Groovy, whatever) which is the recommended method in situation 2 above and others like it.
We have PHP, ColdFusion, ASP developers coming over to Cocoon because they've heard it's the greatest thing since sliced bread and adding O/R tools to the list of things they have to learn just to produce their first page displaying data from a database would send them running more than we already do. There is a huge LAMP (linux, apache, MySQL, PHP) world out there and convincing them to become LAMCXmlXslSitemapMVCContinuationsFOMOJBJavaAvalonExcaliburSoCGoF people in one step is completely unrealistic.
I also think and have thought for some time that repackaging the ModDBActions as generalized components accessible from flow would be a great step forward for these types of users, and for anyone with relatively simple needs. We need this to keep people with script template backgrounds from doing data manipulation in the view layer (generator or transformer). The only way to avoid that now is to point them back to actions or complicate the issue with OJB. It may be that a scriptable component rather than the declarative moddb approach would be a better starting point for people - all the better.
Geoff
