cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Widdershoven <>
Subject Re: Modular database component
Date Thu, 22 Apr 2004 15:08:00 GMT
Joerg Heinicke wrote:

> On 20.04.2004 07:49, Reinhard Poetz wrote:
>>>> Following this I don't see the need for
>>>> a. calling DB from within Flowscripts
>>> You mean direct JDBC? Hmm.. I don't like the idea, but here Groovy can
>>> take the role a lot better than Javascript. Note, Groovy has built 
>>> in SQL
>>> support and that is good.
> From Antonio's comment I guess he just misread your comment. To 
> restate it: Reinhard does not want flow scripts calling DB.
>> Yes, I don't like the idea too. It's good for prototyping but I 
>> wouldn't write my applications with direct DB calls from within the 
>> flow layer. I don't want direct DB calls from within Groovy as Flow 
>> language *also* because this mixes concerns!!!
> Same here. DB should not be called from flow script - neither 
> JavaScript nor Groovy nor XYZ. The thing is about page flow.
>>>> b. code CRUD in templates (Groovy, JXTemplate, ...) and XSP
>>> I will use this combination for (2) it is more powerful than the 
>>> proposed.
>>> Also note, JXTG is useful in combination with CForms. It allow you 
>>> to easy
>>> make a dynamic listbox or show a simple list report for users. It is
>>> really useful have JXTG at hand.
>> I really like JXTG but for now it has *no* direct DB access. You have 
>> to pass the objects to the pipeline within cocoon.sendPage*() and 
>> this is good!
> Same here again. I wonder why templating languages shall be featured 
> up with db access.
>> 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. IMO the same is true for 
>> Groovy scripts.
> +1 (to avoid writing "same here" again :) )
> Joerg

For beginning cocoon/flowscript users one should, if not providing 
direct SQL access, provide a well documented and above all
for simple scenarions EASY way. Setting up and integrating either OJB 
and Hibernate do nut fullfill that condition yet.

I also think that requiring Java classes to be pre-generated (and then 
included in the classpath) for even the simplest queries is not
a problem for developers and advanced users, but is to much to ask for a 
user just starting who just wants to display his
address data or something alike. I think it is unclean, classes should 
be put in the application. A way to describe/map the database
using XML (as done by Hibernate and OJB both) should suffice - the rest 
should be done on the fly like with  xsp. That is by far
the easiest. For advanced uses where those classes are extended one 
could think of precompiled classes.

The way to gain acceptance for a superior framework is to make it just 
as easy as using plain SQL IMHO. Nothing beats the
simplicity at present of pure SQL access - for simple apps. Let's not 
make any new framework/component difficult to start
with. Power should be available on demand, complexity postponed (Yes - 
someone told me it's an on demand world nowadays:)


View raw message