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 Mon, 19 Apr 2004 14:40:12 GMT
Bertrand Delacretaz wrote:

> Le 19 avr. 04, à 11:08, Reinhard Poetz a écrit :
>> ...I have to think more about the API of this component but first I 
>> want to talk more about the background of my idea. I had several 
>> discussions with Alex Schatten and we came to the conclusion that, 
>> generally spoken, there are two database usage scenarios:
>> 1. Enterprise Level
> Where you need java code and/or O/R mapping tools, no question about 
> this.
>> 2. Simple database applications
>>    Usually very small projects where you need only a few 
>> 'interactive' pages.
>> If you are familiar with O/R-mapping tools I always recommend them, 
>> also in scenario two...
> Ok, but our users lists shows clearly that many people are doing stuff 
> directly in SQL, for various reasons, including the welcome 
> "transparency" of SQL when doing simple things.
> And I'd add a third category
> 3. Read-only database publishing or mining applications
> Where you do no transactions, only queries, and where O/R mapping does 
> not bring much to the SQL -> XML -> whatever chain.

See below

>> ...IMO there are users who don't want to write programmes at all. 
>> They prefer XML declarations. So the question is 'How can we support 
>> them?'.
> Don't you think many of these users would prefer writing simple 
> scripts rather than XML declarations?
> But I'm thinking more about providing an alternative to the ESQL / 
> SQLTransformer stuff, maybe you're seeing things from a different 
> point of view?

I'm talking if really simple applications like a registration form, a 
simple page filling one table with data, or something like that. As soon 
as you need more I recommend using O/R-mapping tools because they are 
easier to use as many people think!

>> ...WDOT? Maybe we should collect some proposals and then poll our users?
> might be better to come up with examples or use-cases of 
> what you think a ModularDatabaseComponent could be so that people can 
> judge on code. Otherwise I'm afraid a pool could lead to much talk 
> without a concrete outcome.

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

 3. Publishing        --->  SQLTransformer

Following this I don't see the need for

 a. calling DB from within Flowscripts
 b. code CRUD in templates (Groovy, JXTemplate, ...) and XSP

and not sure about
 c. DatabaseActions. There might be reasons to use them if people don't want
    to learn Flowscript but I'm not sure if we should recommend it.

You also asked how the DatabaseComponent which I'm thinking of could 
work - here an example:

function myDBFunc() {
    var myDBComp = cocoon.getComponent("myDBComp");
    myDBComp.add("tableSet-A"); // tell the component which tableset to use
    cocoon.sendPageAndWait("blabla", {});

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


> Unfortunately I currently lack the time to work seriously on the 
> Groovy/DB stuff. I'll try to not talk too much about it until 
> something usable is here ;-)
> -Bertrand


View raw message