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?
Hmmm...it 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 Component3. 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.setMapping("mappingFile.xml");
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 ...
Comments?
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
-- Reinhard
