cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <>
Subject DB support in flowscript (was: XSP "official" position)
Date Wed, 19 Nov 2003 11:01:41 GMT

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.
(... but it would be OJB based)

What I don't want to see in a flow-db block is SQL statements ...


View raw message