pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gk_br...@verizon.net>
Subject Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg (or similar) subproject inside Pivot
Date Thu, 08 Sep 2011 15:12:00 GMT
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.

On Sep 8, 2011, at 10:59 AM, Chris Bartlett wrote:

> On 8 September 2011 21:36, Greg Brown <gk_brown@verizon.net> 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.

View raw message