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
