Following this I don't see the need for
a. calling DB from within Flowscripts
You mean direct JDBC? Hmm.. I don't like the idea, but here Groovy can take the role a lot better than Javascript. Note, Groovy has built in SQL support and that is good.
From Antonio's comment I guess he just misread your comment. To restate it: Reinhard does not want flow scripts calling DB.
Yes, I don't like the idea too. It's good for prototyping but I wouldn't write my applications with direct DB calls from within the flow layer. I don't want direct DB calls from within Groovy as Flow language *also* because this mixes concerns!!!
Same here. DB should not be called from flow script - neither JavaScript nor Groovy nor XYZ. The thing is about page flow.
b. code CRUD in templates (Groovy, JXTemplate, ...) and XSP
I will use this combination for (2) it is more powerful than the proposed.
Also note, JXTG is useful in combination with CForms. It allow you to easy
make a dynamic listbox or show a simple list report for users. It is
really useful have JXTG at hand.
I really like JXTG but for now it has *no* direct DB access. You have to pass the objects to the pipeline within cocoon.sendPage*() and this is good!
Same here again. I wonder why templating languages shall be featured up with db access.
What I want to tell all users clearly is that they should avoid writing SQL-statements. Integrating SQL in applications is the start of a maintainence nightmare and IMHO we should clearly warn them using XSP, Groovy or any other templating system requiring you to write SQL *into* the code. Once again, I really like e.g. JXTG but it should *never* contain SQL statements. IMO the same is true for Groovy scripts.
+1 (to avoid writing "same here" again :) )
Joerg
