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
