cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Hohls" <>
Subject RE: Cocoon database access strategy
Date Mon, 25 Jun 2007 10:43:27 GMT
Maybe its because I am not Dutch.... but I really
do not get this story -  anyone care to explain?

>>> "Ard Schrijvers" <> 2007/06/25 12:27 PM >>>

Claude: "Is like the story of the hippo."
Reuben: "I'm not familiar with that story."
Claude: "The hippopotamus, he is not born going, 'Cool bean, I am a
hippo.' No way, Jose. So he tried to paint the stripe on himself to be
like the, uh, the zebra, bet he fool no one. And then he tried to put
the spot on his skin to be like the leopard, but everyone know he is a
hippo. SO at certain pont, he look himself in the mirror, an he just
say, 'Hey, I am a hippopotamus, and there is nothing I can do about it.'
And as soon as he accepts this, he live life happy. Happy as a hippo.
You understand?"
Reuben: "I'm gonna kill you!"
Lisa: "Reuben! No, Reuben!" 

As long as everybody is happy :-) 

ps movie "Along came polly"

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. 


On 25/06/07, Ard Schrijvers <> wrote:

>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: 
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
CSIR E-mail Legal Notice 
CSIR Copyright, Terms and Conditions 
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

View raw message