cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: Modular database component
Date Tue, 20 Apr 2004 11:40:11 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? 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.


View raw message