Return-Path: 
 <dev-return-59775-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 76324 invoked from network); 20 Apr 2004 18:38:41 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 20 Apr 2004 18:38:41 -0000
Received: (qmail 15710 invoked by uid 500); 20 Apr 2004 18:38:18 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 15634 invoked by uid 500); 20 Apr 2004 18:38:18 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 15497 invoked from network); 20 Apr 2004 18:38:17 -0000
Received: from unknown (HELO mail.s-und-n.de) (212.8.217.2)
  by daedalus.apache.org with SMTP; 20 Apr 2004 18:38:17 -0000
Received: from notes.sundn.de (ntsrv5.sundn.de [10.10.2.10])
	by mail.s-und-n.de (postfix) with ESMTP id EAC2C19F6D6
	for <dev@cocoon.apache.org>; Tue, 20 Apr 2004 20:38:20 +0200 (CEST)
Received: from s-und-n.de ([10.10.20.145])
          by notes.sundn.de (Lotus Domino Release 6.5)
          with ESMTP id 2004042020311393-74923 ;
          Tue, 20 Apr 2004 20:31:13 +0200
Message-ID: <40856E7D.4080308@s-und-n.de>
Date: Tue, 20 Apr 2004 20:39:57 +0200
From: Guido Casper <gcasper@s-und-n.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Modular database component
References: <408103CA.105@s-und-n.de> <4081A3B8.1060303@apache.org>
      <4081A615.7060805@apache.org> <4082BF8E.5050608@s-und-n.de>
      <42368.10.0.0.5.1082335601.squirrel@ags01.agsoftware.dnsalias.com>
      <40837948.2010706@dds.nl> <20040419075318.GE8987@wlkp.org>
      <40838B14.2040905@apache.org>
      <5FCE6040-91DD-11D8-B9D8-000A95AF004E@codeconsult.ch>
      <408396FA.1040402@apache.org>
      <38F82D90-91E4-11D8-B9D8-000A95AF004E@codeconsult.ch>
      <4083E4CC.1090200@apache.org>
 <32933.10.0.0.5.1082400303.squirrel@ags01.agsoftware.dnsalias.com>
In-Reply-To: 
 <32933.10.0.0.5.1082400303.squirrel@ags01.agsoftware.dnsalias.com>
X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release
 6.5|September
 26, 2003) at 20.04.2004 20:31:14,
	Serialize by Router on PBSN1/Systeme und Netzwerke(Release 6.5|September 26,
 2003) at
 20.04.2004 20:31:14,
	Serialize complete at 20.04.2004 20:31:14
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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:
> 
> A-PersistenceBroker - A very simple API to deal with DB. With DB
> transactions, but not object transactions
> B-OTM - Object Transaction Manager. The same as above + Object Transaction.
> C-ODMG
> D-JDO
> 
> In this way OJB is not exclusive for big leaguers. You can use OJB in
> minor applications too.

That's interesting. Would you care to explain to me what the difference 
between a DB transaction and an object transaction is?

<snip/>

>>You also asked how the DatabaseComponent which I'm thinking of could
>>work - here an example:
>>
>>function myDBFunc() {
>>    var myDBComp = cocoon.getComponent("myDBComp");
>>    myDBComp.setMapping("mappingFile.xml");
>>    myDBComp.add("tableSet-A"); // tell the component which tableset to
>>use
>>    cocoon.sendPageAndWait("blabla", {});
>>}

I like that.

> 
> 
> I will prefer OJB people to make what they do the best.

which is an O/R-mapper for which you need an object model, which you 
might not have (and maybe don't want to have).

BTW do you have an idea how OJB might work with Dynabeans (or XMLBeans)? 
(just thinking out loud again)

Guido

> Is worth to make
> another DB support in Cocoon anothe propietary API? AFAIK, Cocoon is the
> "glue" for webapp needs. And here we will go to another area. Also, why
> reinvent the wheel again?
> 
> 
>>Maybe the DatabaseComponent should support reading operations too.
>>The question is whether we don't duplicate the efforts of e.g. OJB with
>>this approach? The only difference is that you don't need Java objects ...
> 
> 
> 
> 
> Best Regards,
> 
> Antonio Gallardo
> 
> 

-- 
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
                     Tel.: +49-5251-1581-87
Klingenderstr. 5    mailto:gcasper@s-und-n.de
D-33100 Paderborn   http://www.s-und-n.de
-------------------------------------------------