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.
Leon
Antonio Gallardo wrote:
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
