cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [proposal] some changestoSourceResolver.resolve(baseURI,location, params)
Date Mon, 26 May 2003 13:29:44 GMT
Carsten Ziegeler wrote:

>Bruno Dumon wrote:
>  
>
>>Ok, back to the new-interface approach: rather than using an
>>ExtendedSourceFactory interface, how about letting the SourceFactory
>>optionally implement an additional interface, URIAbsolutizer. If
>>present, that interface will be asked to perform the uri-absolutizing
>>process, otherwise the default method will be used.
>>
>>The interface would thus look like:
>>
>>public interface URIAbsolutizer {
>>  public String absolutize(String baseURI, String location);
>>}
>>
>>The difference with ExtendedSourceFactory is that this one will only be
>>implemented in case the absolutize-strategy differs from the default
>>behaviour, while ExtendedSourceFactory more sounds like a successor to
>>the current SourceFactory.
>>    
>>

Does this means current Source implementations that would not be 
upgraded to implement URIAbsolutizer will continue using the existing 
absolutization scheme ?

If so, we cleanly keep backwards compatibility.

>+1, I like it :)
>

+1 also !

About the absolutization algorithms, instead of providing a set of 
components (how overkill !), what about providing them as static methods 
in SourceUtil ? Most implementations will just have to pick the relevant 
algorithm in that class, yet some are still able to define their own 
fancy algorithm.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Mime
View raw message