cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Modular database component
Date Tue, 20 Apr 2004 05:49:27 GMT
Antonio Gallardo wrote:

>Reinhard Poetz dijo:
>>I'm aware of the fact that there are many ways in Cocoon. I think that
>>we as community should give clear advice what's in our opinion the best
>>way. If I'm asked I say:
>> 1. Enterprise Level  --->  O/R-mapping, EJB
>> 2. Simple Database Applications  with CRUD (create/update/delete)
>>                      --->  Flowscript and Database Component
>With Groovy the (2) will be easier.
>> 3. Publishing        --->  SQLTransformer
>I think (2) can be also be used with O/R mapping tool. Not sure what the
>DB component is. In fact (and with my respect to ESQL developers) why
>Cocoon will need to build another layer when there is OJB. Remeber OJB
>allow you to play at 4 levels:
>A-PersistenceBroker - A very simple API to deal with DB. With DB
>transactions, but not object transactions
>B-OTM - Object Transaction Manager. The same as above + Object Transaction.
>In this way OJB is not exclusive for big leaguers. You can use OJB in
>minor applications too.

I'm aware of that. But do we give this our users as advise for *all* 
cases? Don't forget what a user has to learn in order to implement an 
application with Cocoon:

 - Setting up Cocoon
 - learn about the concepts of sitemap & pipelines
 - learn XSLT
 - learn Flowscript (Javascript)
 - learn how to mange a DB
 - learn how to manage an O/R-Mapper + learn Java (for the objects)
 - learn CocoonForms and how to bind them to Java objects

In my opinion this is the way to go but it's *not* an easy way.

>>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.

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!!!

>> 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!

>>and not sure about
>> c. DatabaseActions. There might be reasons to use them if people don't
>>    to learn Flowscript but I'm not sure if we should recommend it.
>And let the user base start ranting us? I think is our obligation to
>support "stable" blocks. The same apply to Avalon components. I think
>there is a lot of people that use this Actions and we cannot drop support
>from one day to another. The worse is that this APIs are considered
>stables. Then we need to live with them for a while. This is the same case
>as XSP.

I *don't* want to *drop* support for things we declared stable but what 
I want is clear *recommendations* - nothing more.

I already said in several mails that we should reduce the recommended 

 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. IMO the same is true for Groovy scripts.

>>You also asked how the DatabaseComponent which I'm thinking of could
>>work - here an example:
>>function myDBFunc() {
>>    var myDBComp = cocoon.getComponent("myDBComp");
>>    myDBComp.setMapping("mappingFile.xml");
>>    myDBComp.add("tableSet-A"); // tell the component which tableset to
>>    cocoon.sendPageAndWait("blabla", {});
>I will prefer OJB people to make what they do the best. Is worth to make
>another DB support in Cocoon anothe propietary API? AFAIK, Cocoon is the
>"glue" for webapp needs. And here we will go to another area. Also, why
>reinvent the wheel again?

This wheel has already been invented using the *DatabaseActions. Don't 
forget that they have one big advantage compared to O/R-mapper: You 
don't have to learn Java to use them!!! (see comments on learning 
curve). Therefore I think they are an interesting canditate.

>>Maybe the DatabaseComponent should support reading operations too.
>>The question is whether we don't duplicate the efforts of e.g. OJB with
>>this approach? The only difference is that you don't need Java objects ...


View raw message