On 8 September 2011 22:12, Greg Brown <[email protected]> wrote: > Ah, OK. I have considered a similar extensibility mechanism in the past, > using a static map of file extension to Serializer<Image> that the Image > class would use to determine how to load a given image URL. But maybe a > service provider would work better.
Does that mean you would reconsider your '-1'? :) I think a service provider is a good fit in this case and would remove the build time dependency on the SVG jar from projects that don't care about SVGs. Image could search for a provider for the supplied file extension, use it if found, and default to Pivot's in built support for certain types. I don't see a need to wrap existing support (via BufferedImageSerializer?) in one or more providers. Any file extensions that are supported internally by Pivot/JRE could be overridden by users if they create and use their own provider. > On Sep 8, 2011, at 10:59 AM, Chris Bartlett wrote: > >> On 8 September 2011 21:36, Greg Brown <[email protected]> wrote: >>>> I have only scanned this thread quickly and haven't examined the code, >>>> but couldn't the SVG stuff be moved into a separate JAR as Sandro >>>> suggested, after modifying the relevant >>>> BXMLSerializer/Image/Drawing/whatever classes to find the SVG jar via >>>> Pivot/Java service loaders? >>> >>> The actual SVG stuff is already in a separate JAR (svgSalamander-tiny.jar), >>> which isn't included with the distribution. The only Pivot class that has a >>> dependency on it is Drawing, but if an app doesn't use the Drawing class, >>> then the SVG Salamander classes aren't loaded. So there's no need to use a >>> service provider - the JVM already takes care of that. >> >> I just looked at the source of the Drawing class and see that it is >> *ONLY* used for SVGs. The name suggested a much more generic class. >> Drawing has a dependency on the SVG classes, and then Image references >> it, and Image is referenced in a lot of places. >> >> I meant using a service loader to find a service (Image implementation >> provider) that could handle SVGs and return an Image. >> org.apache.pivot.wtk.media.Image.LoadTask.execute() currently >> instantiates a new Drawing if the extension is 'svg'. >> That extension could be the basis of a service lookup, which would >> find the service that might use Drawing (or any other SVG 'provider'). >> i.e. Don't hard code a reference to the Drawing class into Image. >> >> Support for additional Image formats could easily be added by dropping >> more 'image provider services' jars into the classpath. > >
