Can we take a step back? Let's look at the possibilities:
1. URI resolver: Processes a URI String, returning either the same URI
or a modified/different one. Corresponds to JAXP's URIResolver and SAX's
EntityResolver. Generally usable whereever we use URIs to access
external resources.
2. URI to InputStream resolver: Takes a URI and returns an InputStream
from where a resource (font, image etc.) can be loaded. Such a resolver
could mak use of the URI resolver above before actually resolving to an
InputStream.
3. URI to FopImage resolver: Basically corresponds to our
FopImageFactory today. Takes an URI and provides a FopImage instance,
making use of at least a (1) and optionally (2).
(3) could, for example, also provide the ability to create an image on
the fly (charts, barcodes, static progress indicators, whatever...).
All three could be expressed as plain Java interfaces. Each for its own
level of responsibility. From top to bottom the responsibilities narrow
down.
Wouldn't it solve any possible requirement to provide a central registry
in FOP where implementations of these interfaces (all three) are
provided? By default, FOP provides its own basic implementations and our
customers (Cocoon for example) could plug in their SourceResolver and
CatalogResolver as necessary.
Actually, that was what I originally planned to do by introducing Avalon
(Framework). Its Serviceable/ServiceManager pair would have provided
this infrastructure (allowing easy interfacing with Cocoon). I don't
think it's a big problem to write some basic infrastructure to provide
this (extending FOUserAgent or writing some FOPEnvironment class).
Avalon would provide that already, as would probably other frameworks
(such as Hivemind). In the end it depends on how much we will want to
write ourselves and not depend on other libraries. Given the recent
events in Avalon-land (and around it), I don't have a problem with going
our own way although it doesn't sound ideal to me. Batik has done the
same.
Just a few thoughts...
On 30.04.2004 23:29:19 Stefan Seifert wrote:
What about interface javax.xml.transform.URIResolver with
javax.xml.transform.Source resolve(String href, String base) ?
Note that org.apache.xml.resolver.tools.CatalogResolver is an
implementation of this interface using various sorts of catalogs.
Well, i'm not sure if thats helping us here, because the different
resolving/source concepts seem primarly to target resolving one string
url into another string. My aim is to resolve a string source uri and
get an input stream (like it is done by excalibur source resolving or -
in a more simple way - by the
java.net.URL/URLStreamHandler/URLConnection connection classes used by
FOP 0.20.5 in the current implementation).
Jeremias Maerki
