On Mon, 2003-05-26 at 15:29, Sylvain Wallez wrote:
> 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 ?
I thought of replacing it with the "normal" absolutization method. I
don't expect that will introduce big problems.
The resolveURI(location, baseURI, params) variant doesn't seem to be
used much in Cocoon anyway. And where it is used (e.g. SourceUtil) null
is passed as baseURI. (didn't look at the blocks though).
>
> 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.
That's what I was up to... I now have a URLUtils class for this.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org