cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Modular database component (was: OT: [RT] Use of flowscript or the pyramid of contracts)
Date Mon, 19 Apr 2004 08:17:24 GMT
Leszek Gawron wrote:

>On Mon, Apr 19, 2004 at 09:01:28AM +0200, Leon Widdershoven wrote:
>>I, as a user, do not differentiate between Components and utility
>>classes and functions. I think that when a cocoon developer hears
>>Component, (s)he thinks of classes which obey some sort of contract
>>by implementing an interface.
>>If I, as a user, think of a component it is a part that does
>>something and is easily integrated into the flowscript.
>>And example for Javascript flowscript is of course woody.js. This
>>integrates fabulously with flowscript.
>>Unfortunately, the same does not hold for database actions. As
>>I user, I could not find a way to access databases without
>>just using the classes from java.sql, though I did manage
>>to get a Connection from the pool from the manager.
>>As a *hacker* I used parts of the samples plock (PetStore);
>>the sample block contains an excellent module, part of the
>>petstore, to access databases and represent resultsets.
>>And what I'm wondering is why such a usefull component
>>for an example is part of -of all things - an example
>>block in stead of an optional JavaScript/Database block.
>>I have the feeling that people might be more willing to make
>>components for flowscript (and the same would probably hold
>>for other flow languages) if components did not look so
>>application specific. I use Dababase.js; but the sources
>>are part of the samples, so I for one have the feeling
>>it is a totally unsupported module.
>because it is a totally unsupported module. Long time ago it was considered a
>bad practice to call actions from flow so the new FOM does not have it. It
>results in the fact that you are not able to use ESQL if you use a flow
>application. ESQL is lost and you do not have any substitute (the database.js
>you mention is considered a prototype only). And though all developers say :
>use O/R tools I started from simple xsps because cocoon itself was to much for
>me to handle at once. After some prototypes I switched to Hibernate and would
>never go back to ESQL but still I recommend to all my friends to start simple
>with esql.
>As I have written in some previous post: with flowscript you gain a lot of
>freedom and make development much simpler but because of lack of database
>abstraction language you have to use components with pure JDBC which makes it
>a lot harder in the business layer!

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. To get them we could make the ModularDatabaseActions 
more general and create a ModulareDatabaseComponent which can either be 
integrated into your applications using Actions (being completly 
backwards compatible with the existing actions) or Flowscript. I think 
it shouldn't be too complicated to create those components (at least 
with the help of Chris H. ;-)

WDOT, is it worth doing the refactoring?


View raw message