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
