cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <o...@wlkp.org>
Subject Re: OT: [RT] Use of flowscript or the pyramid of contracts
Date Mon, 19 Apr 2004 07:53:18 GMT
On Mon, Apr 19, 2004 at 09:01:28AM +0200, Leon Widdershoven wrote:
> Hi,
> 
> 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!

	lg
-- 
            __
         | /  \ |        Leszek Gawron            //  \\
        \_\\  //_/       ouzo@wlkp.org           _\\()//_
         .'/()\'.     Phone: +48(501)720812     / //  \\ \
          \\  //  recursive: adj; see recursive  | \__/ |


Mime
View raw message