:
String sb = XSPUtil.getContents(source);
--Steve
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 13, 2002 10:27 AM
To: [EMAIL PROTECTED]
Subject: RE: [PROPOSAL] Remove SQLTransformer in 2.1
From: Andrew C. Oliver [mailto:[EMAIL
second:
I don't want to rain on your parade, but...
from an architectural point of view: is
resolver.resolve(cocoon://dynamic-sql) in XSP so much
better than document() in XSLT ?
Yes, the first is cached, and I agree (up to a point, though)
that SQL queries belong to generation rather
Yepp!
Andrew, give me a mail when you are ready to start...
...maybe we can work this out together...
Cool . Will do. It is currently on the queue in position #9. I will
inform you if it moves to position #1 or if
it moves down too many positions.
Thanks,
Andy
--
Torsten
P.S.
I use SQLTransformer only, and I'm happy with it :) don't deprecate it :(
I guess it would be cool for both ESQL and the SQLTransformer to share code as
well as syntax. But this will probably break backwards compatibility for
both. IMHO it could be nice to start a new combo of XSQL
Torsten Curdt wrote:
P.S.
I use SQLTransformer only, and I'm happy with it :) don't deprecate it :(
I guess it would be cool for both ESQL and the SQLTransformer to share code as
well as syntax. But this will probably break backwards compatibility for
both. IMHO it could be nice to
/lmorandini/index.html
-
-Original Message-
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 13, 2002 3:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL] Remove SQLTransformer in 2.1
Torsten Curdt wrote:
P.S.
I use
-
-Original Message-
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 13, 2002 3:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL] Remove SQLTransformer in 2.1
Torsten Curdt wrote:
P.S.
I use SQLTransformer only, and I'm
From: Luca Morandini [mailto:[EMAIL PROTECTED]]
Andrew,
do you mind terribly showing an example of an ESQL feeded by a dynamic
query
produced by XSLT ?
I don't mind. Moreover, something tells me I already answered similar
question on user list...
Will it help you if I answer?
Vadim
Vadim Gritsenko wrote:
From: Luca Morandini [mailto:[EMAIL PROTECTED]]
Andrew,
do you mind terribly showing an example of an ESQL feeded by a dynamic
query
produced by XSLT ?
I don't mind. Moreover, something tells me I already answered similar
question on user list...
Will
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
Vadim Gritsenko wrote:
From: Luca Morandini [mailto:[EMAIL PROTECTED]]
Andrew,
do you mind terribly showing an example of an ESQL feeded by
a dynamic query produced by XSLT ?
I don't mind. Moreover, something tells me I already
From: Luca Morandini [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 13, 2002 1:29 PM
To: [EMAIL PROTECTED]
Subject: RE: [PROPOSAL] Remove SQLTransformer in 2.1
Vadim Andrew,
first:
thanks.
second:
I don't want to rain on your parade, but...
It's not my parade, it's Andrew's: I
]
Subject: RE: [PROPOSAL] Remove SQLTransformer in 2.1
Vadim Andrew,
first:
thanks.
second:
I don't want to rain on your parade, but...
It's not my parade, it's Andrew's: I merely stating possibilities :)
from an architectural point of view: is
resolver.resolve(cocoon://dynamic
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
Vadim,
My parade was to do achieve the following:
1. Excite a final decision on whether the SQLTransformer is deprecated
or not
2. Excite an effort (if not) to clean both SQLTransformer and ESQL if
not (SQLTransformer is *slow*)
It
Here is one...
xml-cocoon2\src\scratchpad\src\org\apache\cocoon\taglib\Tag.java
If this idea picks up, SQLTransformer will be re-implemented as a set of
tags (one tag?), and ESQL will be deprecated.
:)
PS SQLTransformer code might be messy. But functionality it provides is
valuable to
the output of the
transformation pipeline.
-Original Message-
From: Per Kreipke [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 11, 2002 5:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [PROPOSAL] Remove SQLTransformer in 2.1
The ESQL generator AFAIK supports everything one could need
Another options is to move all the shared functionality to helper classes or
components and reuse them in both places.
Konstantin
If there is a reason to use this functionality at the transformer layer,
I'm not against the idea. I've yet to hear
a use case though. The only ones I can
-10
The SQLTransformer provides a very good alternative to ESQL, it is in
some use cases more flexible as it is a transformer and not a generator.
And you don't need XSP to use it.
The SQLTransformer in its current state is not a 1.x construct, it has
been redesigned several times and
oh and can we remove the its deprecated notation from the documentation.
Time permitting, I'll attempt to resolve why it is so slow by comparison.
-Andy
Carsten Ziegeler wrote:
Andrew C. Oliver wrote:
Hi All,
Backward compatibility among minor revisions is generally a smart and
good
Andrew C. Oliver wrote:
-10
The SQLTransformer provides a very good alternative to ESQL, it is in
some use cases more flexible as it is a transformer and not a generator.
And you don't need XSP to use it.
The SQLTransformer in its current state is not a 1.x construct, it has
been
PROTECTED]
Subject: RE: [PROPOSAL] Remove SQLTransformer in 2.1
The ESQL generator AFAIK supports everything one could need
to do via
the SQLTransformer and there does not seem to be a reason
to continue
to support both technologies.
How can
It is remarkably slower than ESQL. Okay if you feel this strongly about
it then thats fine. Would you
be against refactoring the two and moving the common constructs to
common classes as Vadim suggested?
No, refactoring sounds like a good idea as long as the SQLTransformer
is not
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
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
[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
Per Kreipke wrote:
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
: [PROPOSAL] Remove SQLTransformer in 2.1
Per Kreipke wrote:
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
On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
. . .
I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
newer releases, remove all SQLTransformer based samples (or provide esql
alternatives).
(I have no formal voting rights here but)
-1
Why remove a component that
Bertrand Delacretaz wrote:
On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
. . .
I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
newer releases, remove all SQLTransformer based samples (or provide esql
alternatives).
(I have no formal voting rights here
The ESQL generator AFAIK supports everything one could need to do via
the SQLTransformer and there does not seem
to be a reason to continue to support both technologies.
How can that be true? The transformation point in the pipeline is very
different than a generator. For example, I can order
Per Kreipke wrote:
The ESQL generator AFAIK supports everything one could need to do via
the SQLTransformer and there does not seem
to be a reason to continue to support both technologies.
How can that be true? The transformation point in the pipeline is very
different than
ESQL is certainly more developed, but it is not a replacement. Where
in SQLTransformer do you suspect code rot? Have people been
experiencing problems with it?
Open up the sourceode for the transformer, look at the amount of
repetitive code.. . The SQL Transformer is also some many
How can that be true? The transformation point in the pipeline is very
different than a generator. For example, I can order transformations such
that the SQL transformer comes between other transforms but you couldn't do
that with a generator.
Very few times is there a reason to build your
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
Bertrand Delacretaz wrote:
On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
. . .
I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
newer releases, remove all SQLTransformer based samples (or provide
esql
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
Bertrand Delacretaz wrote:
On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
. . .
I'd like to propose we remove the SQLTransformer from
Cocoon 2.1 and
newer releases,
Andrew C. Oliver wrote:
Hi All,
Backward compatibility among minor revisions is generally a smart and
good thing to do. However, there does
become a point where it grows six legs and starts biting you.
The ESQL generator AFAIK supports everything one could need to do via
the
35 matches
Mail list logo
