Hello,

I would agree on the need of an SQL transformer. 

We have a significant investment in 2.1 code using the SQL transformer. We 
don't intend to look at cocoon 3.0 until production release (mainly because we 
are a small group and don't have the time or resources to evaluate at this 
stage)
But in order to upgrade our sitemap code to a version that does not have such a 
transformer would be too costly. At worst we would have to develop our own 
transformer when the time comes.

This would not be ideal as i am sure we don't have the same level of expertise 
in the java/cocoon 3.0 framework as the Apache developers. So I would agree 
with Lars and request that the team include an SQL transformer in the framework.

Cheers,
Frank

On 29/07/2011, at 2:47 AM, Lars Huttar wrote:

> On 7/28/2011 2:26 AM, Francesco Chicchiriccò wrote:
>> On 28/07/2011 00:32, Lars Huttar wrote:
>>> Hello,
>>> 
>>> In the past (Cocoon 2.1) we used XSP pages for database queries to return 
>>> results as XML for processing in Cocoon pipelines.
>>> 
>>> Looking toward the future with 2.2 and beyond, we saw that XSP pages were 
>>> deprecated, so we started using SQL transformer instead.
>>> 
>>> With Cocoon 3.0, is the SQL transformer still part of the picture? (I don't 
>>> see it among the samples.) Or is there something else that is recommended 
>>> for grabbing data from a database as input to a pipeline?
>> 
>> Not as far as I know: anyway, nothing obstacles to add it in cocoon-optional 
>> or - better - in a separate module.
>> Nowadays there are many choices (JPA, iBatis, ...) not available at the time 
>> of the SQL transformer...
>> 
>> Regards.
>> 
> 
> Thanks for this reply.
> Is there any way I can contribute toward SQL transformer (or a replacement) 
> being added to Cocoon 3?
> I know basic Java development, but am not familiar with the various libraries 
> and frameworks involved (spring, maven, avalon, etc.).
> 
> Some kind of database input is central to the web apps we are developing (as 
> it is to most web apps, I suppose), so having this functionality early on 
> will determine whether going with C3 is feasible for us.
> 
> Regards,
> Lars
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to