cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Widdershoven <...@dds.nl>
Subject Re: Modular database component
Date Tue, 20 Apr 2004 06:51:51 GMT


Antonio Gallardo wrote:
> Reinhard Poetz dijo:
> 
>>I'm aware of the fact that there are many ways in Cocoon. I think that
>>we as community should give clear advice what's in our opinion the best
>>way. If I'm asked I say:
>>
>> 1. Enterprise Level  --->  O/R-mapping, EJB
>>
>> 2. Simple Database Applications  with CRUD (create/update/delete)
>>                      --->  Flowscript and Database Component
> 
> With Groovy the (2) will be easier.
> 
>> 3. Publishing        --->  SQLTransformer
> 
> 
> I think (2) can be also be used with O/R mapping tool. Not sure what the
> DB component is. In fact (and with my respect to ESQL developers) why
> Cocoon will need to build another layer when there is OJB. Remeber OJB
> allow you to play at 4 levels:

As a user: Of course you can. The question is whether you'd want to. Using
OJB seems to demand that you set up descriptions of the tables, then
create appropriate classes etc.

For a user, most of whom know a bit about SQL, or can read about it in the
thousands of introductory level books, SQL is much easier, not to say more
standard.

Furthermore, creating a query based on form input is just the concatenation
of Strings. How much more easy can it get? As an added bonus, you can
just log the queries in the developer phase and cut-and-paste them in
the command line database tool to see why they would not work. If you
use an added layer that power would either be lost or more difficult
accessible.

I fully see that OJB is more beatifull. But not all people who wish
to write a simple flowscript app wish to start learning two major
technologies at once; they would fall back on a familiar technology
where possible to decrease the chance of failure.

I think more of providing an easy migration path from CRUD to OJB,
using a MigrateFromCRUDToOJB Wiki page in which a simple CRUD flowscript
is moved to the OJB framework, and a sketch of a situation where OJB
is clearly easier to use that any other way.

I think that, if you are familiar with OJB it is hard to see that things
like hibernate and OJB seem daunting; even the name promisses sleepless
nights. And who on earth needs a bridge or relational mapping for
Select username, password from authentication where username = 'foo';?
If you already have OJB up and running it is logical to use that, but
to start learning OJB just for that???

Leon

Mime
View raw message