Antonio Gallardo wrote:
Hi Christopher:
I think that the point they tried to show us is that the database
functions can be an optional part of all the Flow block. I agree because
some applications will not need to use databases at all.
Yes, clearly, that is the case. However, there isn't yet a mechanism for creating "JavaScript" blocks - and you can't solve everything at once.
The problem I was trying to address is this: why do people choose to use ESQL or JSTL for database processing, rather than writing JDBC code in their server pages? Well, because it's _easier_. So, in my opinion, we will need an equally easy-to-use API to convince those people to use the flow layer. I've had first-hand experience in my regular job of a wide range of people finding JDBC very unfriendly. And for such people Hibernate or OJB as a solution isn't going to seem much friendlier.
That's it.
I fully agree with you on this subject, and that was the point of my post you were referring to. In order to lower the entry cost of PHP-and-the-like people in Cocoon, we must provide some "unclean" (from an architectural point of view) solutions that ease the job of using databases. This will allow them to slowly grasp the Cocoon philosophy and better structure their next application. Also, Cocoon is used on small projects where using an O/R machinery is just too heavy.
But these features should not be in the core.
Anyway, I've moved getConnection() off of the "cocoon" object and placed it in a new "Database" object, so now you should do this to create a connection:
var conn = Database.getConnection(dataSourceName);
This looks better. I'll look at this more closely ;-)
Thanks, Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
