On 23.10.2005 23:45, Ralph Goers wrote:
We are chosen as committers as induviduals and not as representants
for our companies. From a community stand point I would say that it is
time to deprecate the SQLTransformer. As a representative for my
company I would rather say: no way, we have tons of code that depend
on it. It is a complicated question, but I don't think that the answer
is: I need it at my work so the rest of you should support it.
This is a really good point but I'm not sure I'd come to the same
conclusion. Personally, I know I'd never want to use the SQLTransformer
for any of the projects I work on. But then, if I needed to create a
really simple website it might be the quickest way to do it. I tend to
try to look at it from what I think the general Cocoon customer base
wants - and that is imprecise and tricky. In the case of the
SQLTransformer, if we remove it and tell our customers that in order to
upgrade they a) have to maintain the old transformer themself, or b)
have to write a whole bunch of Java code are rearchitect their
application, then I'd be very reluctant to remove the component.
Frankly, I think that is why XSP is still around - some folks still find
it the easiest way to get the job done despite our recommendations that
there is a better way.
I also don't like the idea of removing all the old stuff we no longer
recommend. Of course Cocoon moves forward to other approaches and the
best practices are changed. But as long as we don't have a new golden
hammer for a group of tasks (as we had with CForms in contrary to the
other form frameworks) we should not remove the old stuff. It does not
hurt to hold it in our codebase, the maintenance is nearly zero. Or when
was XSP touched the last time? Doing it the recommendations/best
practices way is a much better approach IMO. Of course there will be a
time where we have to throw out some ballast. But for XSP or our
different persistence approaches the time has not arrived IMO. So
already stabilizing and finishing the CTemplate approach might make XSP
superfluous.
Jörg
