cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Widdershoven <>
Subject Re: OT: [RT] Use of flowscript or the pyramid of contracts
Date Mon, 19 Apr 2004 10:32:38 GMT

To me, hibernate is overkill and yet another thing to manage. The
advantage of esql is that it is simple, and has a single layer access
to the database.

Hibernate is more complicated to set up, and then has to be maintained.
If you use plain SQL, only the queries have to be maintained. If you
use hibernate, it also has to be maintained.

For plain old statements like select * from foo where bla=<xsp:request.../>
it's just overkill to me.

I do think hibernate is very good - for advanced usage. I think it
is a shame that people are forced to either use xsp or use plain
java.sql access to the database in flowscript.

the combination Javascript and SQL is hard enough for beginners -
starting out with yet another component that needs to be
configured is IMHO just too much.

Please note that I do not undervalue Hibernate, or OJB. But they
are both powerfull tools, and powerfull tools tend to be harder
to initialize that simple stuff (sql) for simple work. That this
is not suppurted is the reason that I only use flowscript where
I really need a multi-stage flow. XSP is still better suited
(easier to read, modify and maintain, debug) for simple SQL queries
and updates. A shame as flowscript is more powerfull and better suited
to development.


Antonio Gallardo wrote:
> Leszek Gawron dijo:
>>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
>>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
>>me to handle at once. After some prototypes I switched to Hibernate and
>>never go back to ESQL.
> Not using Hibernate. I use OJB. And I agree that there is no way to go back.
>>but still I recommend to all my friends to start simple with esql.
> You are cruel! :-D
> We are trying to show people the right things from the beginning:
> Last week, we training our new coworker with PHP background. We started to
> show the Cocoon world with OJB+JXTG+CForms+Flow. After 2 days of intensive
> training (8 hours each day and BTW, I cannot speak anymore) + Carlos the
> day after guiding in a sample of a contact DB webapp (cca. 5 tables) in 1
> day.
> Our coworker, realized how good Cocoon is and the nice approach. I hope to
> see the progress this week. while start working "real life" projects. I am
> aware there are even more things to improve in our development approach,
> but the current archievement show us we are going in the right path.
>>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
>>a lot harder in the business layer!
> Looking for SQL support in javascript? ... What about Groovy:
> Best Regards,
> Antonio Gallardo

View raw message