cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: SQLTransformer design question
Date Fri, 14 Oct 2005 17:12:56 GMT
That sounds good to me and is actually the way we implemented it to allow us to use the SQLTransformer.

As soon as I have time I will create a patch. 

Also I am not sure anyone has looked at it but the only other big problem we have encountered
in a very large system that now uses Cocoon is

If a patch for that is needed I can create and send as well. Without us fixing this Cocoon
would be unusable in our environment. 


> wrote:
>> Our barrier to be able to extend the SQLTransformer is the Inner Class
>> Query is either package access in the 2.1.7 version or now refactored
>> to private access in the latest code base.
>> Could Query be a interface with a default implementation , a non Inner
>> Public Class, a simple Protected Inner Class...? 
>> Is there some other way of allowing inheritance?
>Yes. Inner class Query can be made protected, additional method  protected Query 
>newQuery()  should be added to the SQLTransformer, and all usages of  new 
>Query()  should be converted to calls to newQuery().
>In this case, in the derived SQLTransformer, you can extend from Query, and 
>override newQuery() method to provide your own Query implementation.
>If that sounds good to you, you can prepare a patch, put into into Bugzilla, and 
>send a note here.

Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at

View raw message