Yuppo. To me a big problem is that the SQLTransformer performs poorly, users start off using it because ESQL is more hidden in the documentation for instance, and then "Gee cocoon is slow"...
-Andy Stephen Ng wrote: >This is true, but the coding is trivial--it's just one line. > >This could be put into the util logicsheet, removing the need to know >Java to do it. > >If we keep both methods, a step towards making Cocoon more user-friendly >would be some doc explaining when to use which method (which goes back >to a use-case I suppose). > >Steve > > > >>-----Original Message----- >>From: Per Kreipke [mailto:[EMAIL PROTECTED]] >>Sent: Friday, July 12, 2002 11:54 AM >>To: [EMAIL PROTECTED] >>Subject: RE: [PROPOSAL] Remove SQLTransformer in 2.1 >> >> >> >> >>>>Personally I much prefer esql to SQLTransformer because I >>>> >>>> >>can control >> >> >>>>the caching in an xsp. >>>> >>>>Anyway it isn't quite true that you can't do >>>> >>>> >>"transformation" in an >> >> >>>>xsp: I have SQL which is dynamically generated from an xslt >>>>transformer which I then feed into my esql. I use the resolver to >>>>grab the output of the transformation pipeline. >>>> >>>> >>>> >>>> >>>Which is what I thought. There doesn't seem to be a use case that >>>can't be acomplished one way or the other. >>> >>> >>Right. But it requires Java coding. The SQL Transformer can >>be handled by people without Java skills. >> >>Per >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, email: [EMAIL PROTECTED] >> >> >> >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
