Copy constructors

[Scott Palmer]

On 2012-09-10, at 4:27 PM, Tom Schindl <tom.schindl at bestsolution.at> wrote:

> Am 10.09.12 21:52, schrieb Scott Palmer:
>> 
>> 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:
>> 
>> http://tomsondev.bestsolution.at/2012/01/16/svg-for-fxml-conversion/
> 
> The reason I'd advise against doing this at runtime is that parsing and
> converting SVG to FXML is not as simple as it might look like.

I understand, but in my case if it's going to fail it's going to fail.  The operator won't have the skills to fix it and it would only be an in-house tool for the artist to preview some icons in our UI.

Sorry I missed the point of you telling me to use an FXMLLoader instance.  Got it all straight in my head now.  Sorry for the noise.

Scott