On Wed, Nov 19, 2003 at 12:01:41PM +0100, Reinhard Poetz wrote: > > From: Leszek Gawron > > > On Mon, Nov 17, 2003 at 09:01:57PM -0600, Antonio Gallardo wrote: > > > I really no wonder why peope still think XSP is the great > > Gig in the > > > Cocoon town, because if you google around you will feel this is the > > > way Cocoon goes. To be honest I don't google about this for a long > > > time but still early this year this was the tendency. > > xsp is very powerful if you use it with esql. > > > > - very fast custom database action creation (xsp actions) > > - nice syntax, no need for enormous amount of JDBC code > > needed, no need to > > handle exceptions > > - esql is customized transparently for several databases ( > > i.e. max-rows, > > skip-rows) - very useful for me because I connect cocoon to existing > > database installations so I do not have the comfort to > > choose one that fits > > the best. > > > > while the flow: > > - has some database support but is really poor > > I wouldn't code my DB support in Javascript I'm not advising that also. I am talking about providing an easy framework for database operations that would be available from flow.
and really: why not ? I usually make two scripts : controller.js and persistence.js. JS has a great feature: it is interpreted so all you need is a text editor. You just apply changes and everything works without - building new classes - jar packaging - stopping the container - replacing the jar - starting the container > > > - you have to catch exceptions yourself > > who else should catch them for you? SQLExceptions should be beclared or thrown. Simple JDBC wrappers usually convert almost all of them to RuntimeExceptions. 90% of exceptions usually denote a design time or fatal error so there is really no point to recover from them - it just should be simply logged > > > - no database customizations > > I think flowscript shouldn't support DB access directly Maybe you're right but if you drop XSP what database support you have? Actions? Then can be used for really simple processing as using them for more advanced features makes it harder than using pure JDBC. Please note also that the biggest cocoon application example - Petstore - accesses database directly from JS. > > > - O/R support is still pre-alpha and even if it was already mature > > - the overhead is much too big comparing to pure JDBC for projects > > not-enterprise size > > This is valid for your first project but it's like with Cocoon: After > your first Cocoon project many of us also take it as platform for very > simple projects. > The last few weeks I learned more and more about OJB and you can be sure > I'll take it in many projects in the future - also in projects where I > wouldn't have taken it in the past because I *thought* it is too > complicated (in opposite - using OJB makes it much easier!) > > > - you cannot use it for web applications that use already > > ready database > > schema - try to add some functionality to big accounting > > system - you > > would have to map almost whole existing db even if you > > need access to 3-4 > > tables > > I think if you can remove all those SQL-statements out of your code > which is IMO very ugly it's worth doing it. That's not the point - if you have an accounting system there are usually about 150 tables (very large). If you implement a simple plugin to that system you usually are concerned about a few of them while the OJB would need to map ALL refences between database tables. Continuing the example: cocoon is very powerful in presenting reports. I haven't seen a single report tool that does O/R mapping. Continuing II: I still cannot picture retrieving 5000 of objects via O/R and showing them on paginated view - the performance would be tragical. > > > - sometimes the db schema makes it impossible to use O/R tools > > that's possible ... > > > - in 2 years I haven't found a single project that does not > > fall under one > > of above conditions > > > > I would really like to contribute to some flow-db block that > > does not involve O/R mapping but do not know where to start from. > > > > Maybe this helps - I like the idea but don't know if this will work ... > but I think it worth following it. > http://marc.theaimsgroup.com/?t=106761394400006&r=1&w=2 > (... but it would be OJB based) > > What I don't want to see in a flow-db block is SQL statements ... I think that it should be possible to choose between O/R and pure database access. O/R could be a proposed solution and JDBC wrapper a backup one. ouzo -- __ | / \ | Leszek Gawron // \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
