cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <>
Subject RE: [RT] Connecting databases with Cocoon
Date Wed, 25 Feb 2004 16:34:27 GMT

From: Daniel Fagerstrom [] 

> Reinhard Poetz wrote:
> >After using Cocoon for years I still think we are not very clear in 
> >telling our users what is the right tool for their needs. Of course 
> >this depends on their use cases and their skills.
> >
> >I see three different "Cocoon & databases" szenarios:
> >
> >1. Use Cocoon in enterprise szenarios which are 
> >   highly interactive (--> many forms) + data which
> >   has to be saved in databases
> >
> >   --> use CocoonForms, controlled by the Flow, a
> >       business facade written in Java, 
> >       O/R-mapping as persistence layer
> >
> >   --> or use a tool like XML-DBMS (see Mail from
> >       Daniel) as CocoonForms - database binding
> >       tool.
> >
> >2. Use Cocoon as 'pure' publishing engine
> >   --> use ESQL or SQL Transformer (or sooner or
> >       later USQL ...)
> >
> >
> >3. Use Cocoon 'mainly' for publishing and there are
> >   only a few interactive pages that have to be
> >   persistent in a database and the user is not
> >   familiar with Java (this is for many people
> >   a reason why to use Cocoon because they can
> >   use XML everywhere and don't need to learn
> >   a programming language)
> >
> >As you can see szenario 1 and 2 have clear solutions, scenario 3 
> >doesn't have. Some use ESQL with the drawback of mixing 
> concers, some 
> >use SQLTransformer which doesn't make it easy to make 
> >create/update/delete-applications and some use DatabaseActions which 
> >are IMO the simplest way but they are not supported by flow 
> and which 
> >are hidden in the depth of Cocoon (IMHO).
> >
> >IMO we should make the DatabaseActions more general components (... 
> >shouldn't be too difficult) which can be used from within 
> flow or from 
> >actions and we should make clear statements what we as developer 
> >consider as 'best practices' and what are the pros and cons of each 
> >technology.
> >
> >WDYT?
> >
> >--
> >Reinhard
> >
> I give some philosophical background to my opinion about this in [RT] 
> Cocoon Input Model. My opinion is that Cocoons concern are for 
> relational db (RDB) connections is for going form the RDB to 
> XML and in 
> the opposite direction.
> 1a. I think O/R mappings are cool and great for having persistence in 
> enterprize applications with Cocoon frontend. I wonder 
> however if they 
> are within Cocoons concern area, isn't this more about the 
> communication 
> between the Java objects and the RDB? 

Of course. If you have enterprise applications you have a service layer
without knowing from the existence of Cocoon at all.

> The connection back and forth 
> beween Java and XML definitly is part of Cocoons concern area, IMHO.

Yes, or in other words, the mapping between CocoonForms and Java is
Cocoon's concern.

I added this first point because I just wanted to complete the picture
and to show that the two other points are used in different szenarios
and from a different user group.

> 2. Yes, one definitely needs a SQL-level connection from 
> querys to XML data.
> 3. I agree that we need a simple to use bidirrectional form/RDB 
> connection like the DatabaseActions, but in my opinion they should go 
> between XML and RDB and not between hashmaps and RDB. My main 
> intension 
> with the XML-DBMS proposal is to start a discussion about finding an 
> easy way to go between XML and RDBS.

What is the target group of this approach? IMO there are two groups:

 a) if you want to use CocoonForms without an explicit service layer
    because it is either overkill or the programmer isn't a Java 
    programmer (definitly a reason why many people like Cocoon!)

 b) if you don't want to use CocoonForms at all and you want to
    map the information from the client directly to a database

WDYT? Is this a complete picture or am I missing something?


View raw message