cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Connecting databases with Cocoon
Date Mon, 01 Mar 2004 13:32:16 GMT
Reinhard Poetz wrote:
> 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 
>>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 
>>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 
>>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?
> --
> Reinhard

I think it is a fairly complete picture.

So we need:

* SQL queries (inbeded in XML) -> XML, this is handled by ESQL and 
SQLTransformer, and by USQL in the future. Do we need some special 
component for doing SQL-level update and insert, or is this also the 
task of USQL?

* XML <-> RDB mapping - possibly based on XML-DBMS


View raw message