You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agssa.net> on 2004/04/19 10:51:16 UTC

Re: Modular database component (was: OT: [RT] Use of flowscript or the pyramid of contracts)

Bertrand Delacretaz dijo:
> Le 19 avr. 04, à 10:17, Reinhard Poetz a écrit :
>> ...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 ;-)

Yep. In short: "Let the force be with you!" ;-)

I must tell I am a big Groovy fan too.

As told before we will need to improve the Groovy support. What I did i
the BSF block was just a proof of concept. I will be glad to propose a
Groovy block that will use BSF more oriented to Groovy needs. Something
like precompiling support of classes, then if the source don't change we
will be able to run the class as a generator (as XSP do now).

Best Regards,

Antonio Gallardo


Re: Modular database component (was: OT: [RT] Use of flowscript or the pyramid of contracts)

Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 19 avr. 04, à 10:51, Antonio Gallardo a écrit :

> ...I will be glad to propose a
> Groovy block that will use BSF more oriented to Groovy needs. Something
> like precompiling support of classes, then if the source don't change 
> we
> will be able to run the class as a generator (as XSP do now)....

Of course, the interface with Groovy can be optimized, probably by 
embedding it directly instead of going through BSF, and later 
precompiling, etc.

OTOH, a ScriptableDatabaseComponent (or any scriptable component for 
that matter) could be created fairly easily based on the existing 
ScriptGenerator (or a refactoring of it), and once the interface of the 
ScriptableDatabaseComponent is defined the implementation can be 
optimized later on.

So for me the question is: what interface would such a component need 
to be useful from within Flow.

-Bertrand