Le 19 avr. 04, � 10:17, 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:
...The best way integrating database support in Flowscript is using an *O/R-mapper*. If this is too complicated I would recommend a general database component....
I don't know much about the ModularDatabaseActions, but would a ModularDatabaseComponent be much more powerful or much easier to use than a ScriptableDatabaseComponent?
I'm thinking of something similar to the existing ScriptGenerator in the BSF block, using Groovy scripts to let the user implement the details of database queries and result set formatting. I don't know about what kind of interface you're thinking about for the database component though, did you think about it already?
I hope I'm not being too loud about Groovy, but when I see the absolute coolness of the GroovySql syntax [1], combined with the responsiveness of the Groovy developers, it is hard for me to refrain from pushing it as hard as I can ;-)
-Bertrand
[1] http://groovy.codehaus.org/sql.html - look at the GroovyMarkup example down the page, we're very close to having this in the BSF block
1. Enterprise Level
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.
The question is, how do we deal with scenario two if the user is _not_ familiar with e.g. OJB. I think O/R-mapping is rather straight forward but 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?'.
I don't think writing the database access layer in Groovy (or any other procedural programming language) helps them but maybe I'm wrong here.
Another point is the (often discussed) CocoonForms-database binding for this user group.
WDOT? Maybe we should collect some proposals and then poll our users?
-- Reinhard
