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 > - you have to catch exceptions yourself who else should catch them for you? > - no database customizations I think flowscript shouldn't support DB access directly > - 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. > - 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 ... -- Reinhard
