I've just committed [experimental] changes that provide a simple database API for the Cocoon flow layer modeled after JSTL (http://java.sun.com/products/jsp/jstl). This will allow you to perform a database query in a flow script that produces a bean-like object for use by your presentation layer (i.e. you can pass it to sendPage*() or use it as part of your XMLForm model), without requiring a heavyweight object-relational mapping.
In addition, hopefully this will remove the need for ESQL and satisfy issues like the one raised here: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104533819604446&w=2
The cocoon object now supports a new function
getConnection([String] dataSourceName);
This looks cool... but, continuing my rant about oversimplification, why does the _cocoon_ object hold methods to access database connections ? AFAIK, this object is meant to give access to the enclosing context : request, response, manager (but *not* the environment, which IMO should be removed). So why JDBC stuff there ?
Shouldn't we start to structure the JS stuff in libraries that people load whenever (and only when) they need them rather than mix everything in a single object ?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
