From: Leszek Gawron > 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.
I separate between applications which are more 'publishing-centric' and which are more 'transaction-centric'. 'publishing-centric'-applications usually don't need flowscript. Your example (reporting tools) is of course a representative of the this type and XSP(using ESQL) or SQL-Transformer is the easierst way. If you have to implement transaction logic I think there is no way around Flowscript/CocoonForms/DataObjects(via O/R-mapping or EJB) in order to reach a clean design. I think this is the message for our users. One further thought on DB and flowscript: If you want to combine the ease of use of XSP and flowscript and you don't want to mix concerns - why don't you call pipelines from within your flowscript? Then you can do all the things XSP/ESQL offer having direct database access. And I don't know how it should become easier if we build a specif 'flow-database-framework' compared to the flexibility of Cocoon pipelines which are called from within the flow layer. This also means that you have caching (--> pipeline caching) for free. -- Reinhard
