Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The "URIResolution" page has been changed by Mehdi Houshmand: http://wiki.apache.org/xmlgraphics-fop/URIResolution?action=diff&rev1=1&rev2=2 Comment: Updated information about the ResourceResolver The plan, as of yet, is for the user to implement the following interface: {{{ - InputStream getInputStream(URI uri) throws IOException; + Resource getInputStream(URI uri) throws IOException; OutputStream getOutputStream(URI uri) throws IOException; }}} + + NB:// The Resource class extends a FilterInputStream and wraps both the InputStream and its "type" which refers to the MIME type of the resource being retrieved. We will discuss the necessity of a MIME type being bound to the resource later. + By doing so they allow for a mechanism to resolve URIs, then comes the issue of where to take a base-URI from. Intuitively you'd expect any relative URI within the FO to be resolved against the URI of the FO itself, and likewise for the fop.xconf. However we don't have access to the URI of the FO because FOP implements {{{org.xml.sax.ContentHandler}}}, so that's a no-go. So, using the URI within the fop.xconf seems obvious, but what about when no fop.xconf is given? - - I want to change the {{{FopFactory}}} API such that there are two constructors, one that takes a base-URI, one that takes the fop.xconf. That way we have a base URI to resolve against at instantiation. An implementation of a URI resolver can be given as a setter in the {{{FopFactory}}} since it's optional. A default implementation will do the resolution should the client not define their own. Internally a class will wrap both the base-URI and the implementation of the interface above and be given in the constructor of the {{{FOUserAgent}}}. This maintains immutability for a FOP run (since the user agent is only valid for a single run), and keeps the API fairly simple. + == MIME type resolution == + + Currently FOP performs file-type resolution using the file-type suffix of the file-name. This is fine on the command-line, however, it can get more involved when thinking about using virtual file systems, databases or some of the more abstract resource storage/acquisition mechanisms. As such we believe the MIME type should be resolved by the ResourceResolver; the user should be able to control the MIME type of a resource if they so wish. Obviously, the default (especially for CLI) resolver will allow for file-type suffix MIME type resolution, but the idea is to give clients more control about resource loading mechanism. + Please feel free to discuss any of the changes I'm suggesting above, there may be use-cases I'm not considering. This stuff is very tricky and since accessing resources is fundamental to FOP rendering documents, I have no doubt there are going to be objections. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
