cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: OT: [RT] Use of flowscript or the pyramid of contracts
Date Mon, 19 Apr 2004 08:44:11 GMT
Leszek Gawron dijo:
> 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.

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
> it
> a lot harder in the business layer!

Looking for SQL support in javascript? ... What about Groovy:

http://groovy.codehaus.org/sql.html

Best Regards,

Antonio Gallardo


Mime
View raw message