Re: OT: [RT] Use of flowscript or the pyramid of contracts
On Apr 19, 2004, at 4:42 PM, Leon Widdershoven wrote: Just curious (also:), how much work is it to set up for a given database? Leon I've been playing with those tools for about a week, then I was ready to start redesigning/refaktoring my old webapps, replacing former ESQL- and ScriptableConnection solutions with OR Mapping. OK, admitted, this seems not to be a very fast start, but you must consider that I'm rather a graphic designer than a programmer, and I'm not just new to DB stuff, I'm new to almost every technology involved, even new to java. The documentation and samples provided with that framework are useful, describing various kinds of connections and scenarios. /leo leo leonid wrote: Hi all, just curious, did ever someone in cocoonland, except me, use the SQL-Maps and DAO-Framework from ibatis ( www.ibatis.com ). This is from where Chris borrowed the Petstore sample, that he ported to flow. And that was the simple reason why I hit upon these tools, that I use since, contently. I never tried something similar before and since, so I can't rate it, or even compare it, with the tools you use (Hibernate OJB,..) so, comments would be very appreciated. For training with these tools, I half backported the petstore flow sample, so that it uses flow only for controller things, but leaving all business logic under the responsibility of SQL-Maps/DAO. If there is an interest, I could finish and contribute this alternative petstore sample. /leo On Apr 19, 2004, at 1:54 PM, Leon Widdershoven wrote: I had a task to write a web interface to a table with 300 columns. The column names were still in flux. I really did not feel to write 300 elaborate column definitions. XML is very readable, but it was too verbose for me at the time. And as you say, it looks a very daunting task and that's what most starting users probably think. And if they, because of that, start with xsp and esql (which admittedly is very easy) the going forth to yet another language and framework can be inconvenient. Especially when you get paid to write applications, not learn frameworks:) But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) Leon Leszek Gawron wrote: On Mon, Apr 19, 2004 at 12:32:38PM +0200, Leon Widdershoven wrote: 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= 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. You are not right. Setting up hibernate and writing first application consisting of 5 tables took me 1 hour. For two weeks I been gathering strength to do that because I've been as scared as you are :) lg
Re: OT: [RT] Use of flowscript or the pyramid of contracts
leo leonid wrote: Hi all, just curious, did ever someone in cocoonland, except me, use the SQL-Maps and DAO-Framework from ibatis ( www.ibatis.com ). This is from where Chris borrowed the Petstore sample, that he ported to flow. And that was the simple reason why I hit upon these tools, that I use since, contently. I never tried something similar before and since, so I can't rate it, or even compare it, with the tools you use (Hibernate OJB,..) so, comments would be very appreciated. For training with these tools, I half backported the petstore flow sample, so that it uses flow only for controller things, but leaving all business logic under the responsibility of SQL-Maps/DAO. If there is an interest, I could finish and contribute this alternative petstore sample. /leo Basically it sounds interessting. But before we add support for another alternative accessing DBs in Cocoon we should discuss which alternatives *we* recommend and which not. (more on this you can find in the "Modular database component" thread) -- Reinhard
Re: OT: [RT] Use of flowscript or the pyramid of contracts
Just curious (also:), how much work is it to set up for a given database? Leon leo leonid wrote: Hi all, just curious, did ever someone in cocoonland, except me, use the SQL-Maps and DAO-Framework from ibatis ( www.ibatis.com ). This is from where Chris borrowed the Petstore sample, that he ported to flow. And that was the simple reason why I hit upon these tools, that I use since, contently. I never tried something similar before and since, so I can't rate it, or even compare it, with the tools you use (Hibernate OJB,..) so, comments would be very appreciated. For training with these tools, I half backported the petstore flow sample, so that it uses flow only for controller things, but leaving all business logic under the responsibility of SQL-Maps/DAO. If there is an interest, I could finish and contribute this alternative petstore sample. /leo On Apr 19, 2004, at 1:54 PM, Leon Widdershoven wrote: I had a task to write a web interface to a table with 300 columns. The column names were still in flux. I really did not feel to write 300 elaborate column definitions. XML is very readable, but it was too verbose for me at the time. And as you say, it looks a very daunting task and that's what most starting users probably think. And if they, because of that, start with xsp and esql (which admittedly is very easy) the going forth to yet another language and framework can be inconvenient. Especially when you get paid to write applications, not learn frameworks:) But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) Leon Leszek Gawron wrote: On Mon, Apr 19, 2004 at 12:32:38PM +0200, Leon Widdershoven wrote: 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= 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. You are not right. Setting up hibernate and writing first application consisting of 5 tables took me 1 hour. For two weeks I been gathering strength to do that because I've been as scared as you are :) lg
Re: OT: [RT] Use of flowscript or the pyramid of contracts
Hi all, just curious, did ever someone in cocoonland, except me, use the SQL-Maps and DAO-Framework from ibatis ( www.ibatis.com ). This is from where Chris borrowed the Petstore sample, that he ported to flow. And that was the simple reason why I hit upon these tools, that I use since, contently. I never tried something similar before and since, so I can't rate it, or even compare it, with the tools you use (Hibernate OJB,..) so, comments would be very appreciated. For training with these tools, I half backported the petstore flow sample, so that it uses flow only for controller things, but leaving all business logic under the responsibility of SQL-Maps/DAO. If there is an interest, I could finish and contribute this alternative petstore sample. /leo On Apr 19, 2004, at 1:54 PM, Leon Widdershoven wrote: I had a task to write a web interface to a table with 300 columns. The column names were still in flux. I really did not feel to write 300 elaborate column definitions. XML is very readable, but it was too verbose for me at the time. And as you say, it looks a very daunting task and that's what most starting users probably think. And if they, because of that, start with xsp and esql (which admittedly is very easy) the going forth to yet another language and framework can be inconvenient. Especially when you get paid to write applications, not learn frameworks:) But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) Leon Leszek Gawron wrote: On Mon, Apr 19, 2004 at 12:32:38PM +0200, Leon Widdershoven wrote: 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= 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. You are not right. Setting up hibernate and writing first application consisting of 5 tables took me 1 hour. For two weeks I been gathering strength to do that because I've been as scared as you are :) lg
Re: OT: [RT] Use of flowscript or the pyramid of contracts
Leszek Gawron wrote: On Mon, Apr 19, 2004 at 03:24:50PM +0200, Ugo Cei wrote: Leon Widdershoven wrote: But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) There is a middle ground between a full-fledged O/R mapping layer and raw JDBC calls. You could, for instance, try Spring's JDBC template classes [1], as they take care of the tedious, repetitive and error-prone, like setting up a connection, managing transactions, handling errors and properly releasing resources. An advantage of using Spring is also that it supports Hibernate and JDO out-of-the-box, so graduating from JDBC to an O/R persistence layer might be easier. DISCLAIMER: I've never used Spring, just read its documentation and I really like what I've seen so far. Might be using it for a future project, though. Ugo http://www.springframework.org/docs/reference/jdbc.html There is also a library called DbUtils at Jakarta (http://jakarta.apache.org/commons/dbutils/). DISCLAIMER: I've never used DbUtils, just read its documentation :) quote: DbUtils is a small set of classes designed to make working with JDBC easier. JDBC resource cleanup code is mundane, error prone work so these classes abstract out all of the cleanup tasks from your code leaving you with what you really wanted to do with JDBC in the first place: query and update data. lg I also read the docs for that. As it happens I already had a home grown mini library to do just that before I saw this. There are quite a lot Java packages that work more comfortable if you just wrap them in some exception-catching auto-initialisation classes:) The original topic was, though, that there is no easy default for database access within flowscript. And I think a "light" and "advanced" "recommended" way for database access from within flowscript would do a lot of good. This is, though, not going to happen if I've followed the discussion right:) Leon
Re: OT: [RT] Use of flowscript or the pyramid of contracts
On Mon, Apr 19, 2004 at 03:24:50PM +0200, Ugo Cei wrote: > Leon Widdershoven wrote: > >But I'm glad to hear that Hibernate is quite easy to start with. > >The moment I get some time off I will certainly jump in the > >deep and try to survive:) > > There is a middle ground between a full-fledged O/R mapping layer and > raw JDBC calls. You could, for instance, try Spring's JDBC template > classes [1], as they take care of the tedious, repetitive and > error-prone, like setting up a connection, managing transactions, > handling errors and properly releasing resources. > > An advantage of using Spring is also that it supports Hibernate and JDO > out-of-the-box, so graduating from JDBC to an O/R persistence layer > might be easier. > > DISCLAIMER: I've never used Spring, just read its documentation and I > really like what I've seen so far. Might be using it for a future > project, though. > > Ugo > > > http://www.springframework.org/docs/reference/jdbc.html There is also a library called DbUtils at Jakarta (http://jakarta.apache.org/commons/dbutils/). DISCLAIMER: I've never used DbUtils, just read its documentation :) quote: DbUtils is a small set of classes designed to make working with JDBC easier. JDBC resource cleanup code is mundane, error prone work so these classes abstract out all of the cleanup tasks from your code leaving you with what you really wanted to do with JDBC in the first place: query and update data. lg -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: OT: [RT] Use of flowscript or the pyramid of contracts
Leon Widdershoven wrote: But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) There is a middle ground between a full-fledged O/R mapping layer and raw JDBC calls. You could, for instance, try Spring's JDBC template classes [1], as they take care of the tedious, repetitive and error-prone, like setting up a connection, managing transactions, handling errors and properly releasing resources. An advantage of using Spring is also that it supports Hibernate and JDO out-of-the-box, so graduating from JDBC to an O/R persistence layer might be easier. DISCLAIMER: I've never used Spring, just read its documentation and I really like what I've seen so far. Might be using it for a future project, though. Ugo http://www.springframework.org/docs/reference/jdbc.html
Re: OT: [RT] Use of flowscript or the pyramid of contracts
I had a task to write a web interface to a table with 300 columns. The column names were still in flux. I really did not feel to write 300 elaborate column definitions. XML is very readable, but it was too verbose for me at the time. And as you say, it looks a very daunting task and that's what most starting users probably think. And if they, because of that, start with xsp and esql (which admittedly is very easy) the going forth to yet another language and framework can be inconvenient. Especially when you get paid to write applications, not learn frameworks:) But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) Leon Leszek Gawron wrote: On Mon, Apr 19, 2004 at 12:32:38PM +0200, Leon Widdershoven wrote: 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= 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. You are not right. Setting up hibernate and writing first application consisting of 5 tables took me 1 hour. For two weeks I been gathering strength to do that because I've been as scared as you are :) lg
Re: OT: [RT] Use of flowscript or the pyramid of contracts
On Mon, Apr 19, 2004 at 12:32:38PM +0200, Leon Widdershoven wrote: > > 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= > 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. You are not right. Setting up hibernate and writing first application consisting of 5 tables took me 1 hour. For two weeks I been gathering strength to do that because I've been as scared as you are :) lg -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: OT: [RT] Use of flowscript or the pyramid of contracts
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= 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
Re: OT: [RT] Use of flowscript or the pyramid of contracts
Leszek Gawron dijo: > On Mon, Apr 19, 2004 at 02:44:11AM -0600, Antonio Gallardo wrote: >> Leszek Gawron dijo: >> 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. > Noone would pay me for the training so if someone wants advice I cannot > spend 16 hours straight to do that only. No one payed us for that. :-( We are a very small company in a very poor country. We need to go to the streets to find our food! :-D But training is the right thing, the more you train people, the less you save time later. This is a fact! :-D Also it helps me to see if I am able to explain all this stuff. It helps a lot to consolidate the knowledges about Cocoon. BTW, it was my first conference and I think it was good. Before that, I was afraid I was able to talk about Cocoon for 1 hour, but now I am afraid that 1 hour presentation is too small time for that! If things goes good, I will do a Cocoon presentation on summer for university students in my country. I hope it will encourage more people to try the Cocoon way. > But if I tell him: Look at the sitemap, create a simple view, create an > action ahat does an insert with esql > - he manages to do it by himself. Step forward is one of those 4 > technologies > you mentioned (learning 4 at the same time can give a newbie pretty big > headache) Told me about that! I am one of the early adopters. :-D We made the switch from XSP+DBActions+FormValidatorAction -> the 4 mentioned technologies at once, without training! In our office, I am the one who spend time trying new things before commit them for prodution. I really love this part of my job. > It is always better to start from the right place but without guidance > it's start small or do not start at all. Agreed. Best Regards, Antonio Gallardo.
Re: OT: [RT] Use of flowscript or the pyramid of contracts
On Mon, Apr 19, 2004 at 02:44:11AM -0600, Antonio Gallardo wrote: > Leszek Gawron dijo: > 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. Noone would pay me for the training so if someone wants advice I cannot spend 16 hours straight to do that only. But if I tell him: Look at the sitemap, create a simple view, create an action ahat does an insert with esql - he manages to do it by himself. Step forward is one of those 4 technologies you mentioned (learning 4 at the same time can give a newbie pretty big headache) It is always better to start from the right place but without guidance it's start small or do not start at all lg -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: OT: [RT] Use of flowscript or the pyramid of contracts
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
Re: OT: [RT] Use of flowscript or the pyramid of contracts
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// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
