From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]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?
-- 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
/Daniel
