Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of joerg.heinicke@gmx.de designates
 213.165.64.20 as permitted sender)
Message-ID: <435C106A.2080303@gmx.de>
Date: Mon, 24 Oct 2005 00:36:26 +0200
From: Joerg Heinicke <joerg.heinicke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.7.12) Gecko/20050915
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Rules for adding blocks and functionality?
References: <43595E46.5090005@apache.org> <435BAB81.2080704@nada.kth.se>
 <435BBADB.5090806@apache.org> <435BD461.5080805@nada.kth.se>
 <EA972E52-0022-44C4-84F0-1CF38F4D171D@luminas.co.uk>
 <435BFE4C.7040804@nada.kth.se> <435C0488.3090600@dslextreme.com>
In-Reply-To: <435C0488.3090600@dslextreme.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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