Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 11547 invoked from network); 25 Jun 2007 10:20:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Jun 2007 10:20:20 -0000 Received: (qmail 2711 invoked by uid 500); 25 Jun 2007 10:20:19 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 2652 invoked by uid 500); 25 Jun 2007 10:20:18 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: users@cocoon.apache.org List-Id: Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 2641 invoked by uid 99); 25 Jun 2007 10:20:18 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jun 2007 03:20:18 -0700 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of warrell.harries@googlemail.com designates 64.233.184.228 as permitted sender) Received: from [64.233.184.228] (HELO wr-out-0506.google.com) (64.233.184.228) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jun 2007 03:20:14 -0700 Received: by wr-out-0506.google.com with SMTP id 67so856034wri for ; Mon, 25 Jun 2007 03:19:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=jGx7Jn1mMTR2Cf07gSIKY0Iz6BYfiwRh5EJuSpp5RddrIDW5V72thIhWP6qIIOyFv5b7MFGYpPXIt84xPwZJUaEEtNof0Gvdkfsd/Xy9dPbPGMHXNdHuuSDwPl16fVQNkr0s4dESOwZpY7ywukxtO8AIDjCFQXaDgb3rQ8rN840= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=F988kCPi/CxlKJnooLlu7EfJpTlCAe2khnReVp7slCP3xNQvOI1s2rUBWQuYo5i4/bE8h+BMgplVAkGjslyycGZ8kgznCahRZ9mEp4J1fuNX3QdzlFcbxviL1zO361dS7try68/TzfeFGy+UfJGuVY1oc6ABv5ZERILirr5nSk4= Received: by 10.78.107.8 with SMTP id f8mr2455968huc.1182766791994; Mon, 25 Jun 2007 03:19:51 -0700 (PDT) Received: by 10.78.173.12 with HTTP; Mon, 25 Jun 2007 03:19:51 -0700 (PDT) Message-ID: <5c4168b80706250319h611e4e2escaac0c0f103e364b@mail.gmail.com> Date: Mon, 25 Jun 2007 11:19:51 +0100 From: "warrell harries" To: users@cocoon.apache.org Subject: Re: Cocoon database access strategy In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_71091_31356665.1182766791903" References: X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_71091_31356665.1182766791903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Ard, I understand your comic sarcasm and I think I know where you are coming from ;-) In the final analysis, it seems to depend on where you place the centre of gravity of your application at the outset. If you start building an Object based system and then add persistence you are probably always going to have to write business logic in Java and use an OR framework to map this onto a a relational DB. However, most Enterprise systems start with an ER Model . Various hybrid systems grow around the central DB so it makes sense to gravitate toward the Enterprise DB for all sorts of engineering and political reasons. One size does not fit all and in the world of CMS I can imagine that your approach works for you and your customers. I was just trying to advise those (possibly the majority0 of Cocoon developers who are trying to develop relatively small internal Web-applications that work with Enterprise data. For that kind of thing I endorse the SQLTransformer, JDBI, FlowScript approach. Regards On 25/06/07, Ard Schrijvers wrote: > > Hello, > > >This leads to start writing > > code before > > > the problem is fully understood and a reluctance to > > refactor once it > > > is. These are the very tendencies that Cocoon allows us to overcome > > > because it is entirely possible to develop fully fledged > > applications > > > without writing any Java code. These 'pure' XML applications are > > > likely to be much more maintainable, flexible and capable of re-use > > > than those that skew their centre of gravity back towards Java. > > I can hardly believe everybody seems to take this statement for granted > (jdo and jcr APIs are ofcourse totally redundant since you can write your > own fine sql statements, and of course, sql is a brilliant strong > specification, so when you have it running for oracle, you can switch > automatically without effort to mysql, derby, hsqldb, sql server)...anyway, > if everybody wants to write sql, do many xsl transformations and take the > burden of maintaining sql statements, be my guest :-) > > > Regards Ard > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org > For additional commands, e-mail: users-help@cocoon.apache.org > > ------=_Part_71091_31356665.1182766791903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Ard,

I understand your comic sarcasm and I think I know where you= are coming from ;-) In the final analysis, it seems to depend on where you= place the centre of gravity of your application at the outset. If you star= t building an Object based system and then add persistence you are probably= always going to have to write business logic in Java and use an OR framewo= rk to map this onto a a relational DB. However, most Enterprise systems sta= rt with an ER Model . Various hybrid systems grow around the central DB so = it makes sense to gravitate toward the Enterprise DB for all sorts of engin= eering and political reasons. One size does not fit all and in the world of= CMS I can imagine that your approach works for you and your customers. I w= as just trying to advise those (possibly the majority0 of Cocoon developers= who are trying to develop relatively small internal Web-applications that = work with Enterprise data. For that kind of thing I endorse the SQLTransfor= mer, JDBI, FlowScript approach.

Regards

On 25/06/07, Ard Schrijvers <a.schrijvers@hippo.nl> wrote:
Hello,

>This leads to start writing
> code before
> &= gt; the problem is fully understood and a reluctance to
> refactor on= ce it
> > is. These are the very tendencies that Cocoon allows us = to overcome
> > because it is entirely possible to develop fully fledged
&= gt; applications
> > without writing any Java code. These 'pur= e' XML applications are
> > likely to be much more maintainabl= e, flexible and capable of re-use
> > than those that skew their centre of gravity back towards Jav= a.

I can hardly believe everybody seems to take this statement for g= ranted (jdo and jcr APIs are ofcourse totally redundant since you can write= your own fine sql statements, and of course, sql is a brilliant strong spe= cification, so when you have it running for oracle, you can switch automati= cally without effort  to mysql, derby, hsqldb, sql server)...anyw= ay, if everybody wants to write sql, do many xsl transformations and take t= he burden of maintaining sql statements, be my guest :-)


Regards Ard






------------------------= ---------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@coco= on.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

------=_Part_71091_31356665.1182766791903--