If you have to implement transaction logic I think there is no way around Flowscript/CocoonForms/DataObjects(via O/R-mapping or EJB) in order to reach a clean design.
I think this is the message for our users.
+100000. Time to start spreading the gospel :)
IMO strong Flow + Forms + OJB / JDO / O/R will get Cocoon widespread acceptance. That, and good documentation :)
One further thought on DB and flowscript: If you want to combine the ease of use of XSP and flowscript and you
don't want to mix concerns - why don't you call pipelines from within
your flowscript?
Yep, this is the easy way. I could see this being the answer to some FAQ:
Q: How can I easily send an email from the Flow layer?
A: The simple way is to write an XSP, and call the XSP's pipeline from within the Flowscript. If you need something a little cleaner, you can simply write a helper class in Java and access it from your Flow as an object.
Then you can do all the things XSP/ESQL offer having direct database access. And I don't know how it should become easier if we build a specif 'flow-database-framework' compared to the flexibility of Cocoon pipelines which are called from within the flow layer. This also means that you have caching (--> pipeline caching) for free.
Regards,
Tony
