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