Re: Flow Layer Database API

[Sylvain Wallez <sy...@anyware-tech.com>]

Christopher Oliver wrote:

> 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 }

Re: Flow Layer Database API

[Christopher Oliver <re...@verizon.net>]

Sylvain Wallez wrote:
> Christopher Oliver wrote:
> 
>>
>> 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 ?
> 

You are absolutely correct. However, for now I'd prefer not to invent 
new objects, and this was the most convenient place to put it, so others 
could try it.