swpalmer at gmail.com
Mon Sep 10 12:52:34 PDT 2012
On 2012-09-10, at 3:25 PM, Greg Brown <greg.x.brown at oracle.com> wrote:
>> See my response to Greg. I don't currently process SVG at runtime. I just think it makes the API more generic if that case is supported better. I don't see why the current FXMLLoader should be limited the way it currently is.
> I'm sorry - I don't understand what limitation you are referring to.
> Keep in mind that FXMLLoader's sole purpose is loading FXML. It doesn't know about (and thus can't be optimized for loading) any other data format such as SVG. As I suggested earlier - if you want to efficiently load SVG, use an SVG-specific loader.
I'm referring to the way it accepts the FXML input only via a URL and not any other form. Ultimately all it wants is XML data and so I think it would be reasonable to provide an interface that accepts data in a more general form. If it could take an InputStream for example, then FXML that was machine generated wouldn't need to go to an intermediate file in order to load.
This isn't specific to SVG to FXML conversion, but that is a good example case. I don't have an SVG loader for JavaFX, and didn't find anything with a Google search, but I do know of two SVG to FXML convertors:
These could be used to quickly implement an SVG loader, since I haven't got the time to write one from scratch myself. But they would both have to write a temp file to leverage the current FXMLLoader.
I can use the temp file hack for my purposes, but figured a minor API change would allow for more possibilities. Unless there is a good reason to limit the loader to only URLs.
It's not a perfect match, but consider ImageIO.read(…), it comes in four flavours:
But really that boils down to two forms: from an arbitrary data source via an Input Stream, or from an addressable resource like a File or URL. I think adding the arbitrary data source version to the FXMLLoader seems like a reasonable thing to do.
More information about the openjfx-dev