FXML file
Scene Builder is strongly coupled to the FX SDK bundled with it.
I don't see this changing very soon.
Eric
> Original Message
> Subject: Re: [API Review]: Add 'fxml.version' to System Properties (Was:
> FXML version number)
> Date
I think mixing FXML versions in one FXML document is a bad idea, so my
proposal of a version attribute would only show at the root of the document
applying to all elements of that document, seeing the fx:version attribute
anywhere else should be considered a strict validation error, so the
concerns
Hi,
sorry to step in in the middle of the discussion. I was pointed to this
thread only lately, as a part of review process of
https://javafx-jira.kenai.com/browse/RT-28599
The note about XML diff / processing tools is valid; indeed even
NetBeans which processes FXML must be adapted to creat
Hi,
I don't particularly prefer one way or another but the first thing which
came to my mind is to use a processing instruction. Especially because
it can be "used by tools somehow". XML itself shows this:
My 2c.
Werner
On 09.07.2013 09:06, Milan Kubec wrote:
This information can be then
but using values from
> 'fxml.version' and 'javafx.version'.
> It may also use those variables to improve error report or version
> management (to be defined).
>
> Cheers.
>
> Eric
>
>
>
> > From: Milan Kubec <mai
t;http://javafx.com/fxml/1";
>>xmlns="http://javafx.com/javafx/2.2";
>>
>> Scene Builder Next will do the same but using values from 'fxml.version'
>> and 'javafx.version'.
>> It may also use those variables to improve error report or
n
> management (to be defined).
>
> Cheers.
>
> Eric
>
>
>
> > From: Milan Kubec
> > Subject: [API Review]: Add 'fxml.version' to System Properties (Was:
> FXML version number)
> > Date: July 1, 2013 7:01:12 AM PDT
> > To: "openjfx-dev@
ion' and
'javafx.version'.
It may also use those variables to improve error report or version management
(to be defined).
Cheers.
Eric
> From: Milan Kubec
> Subject: [API Review]: Add 'fxml.version' to System Properties (Was: FXML
> version number)
> Date: J
Hello,
I propose to add 'fxml.version' property to JVM System Properties to
store version of FXML specific version that is supported by FXML Loader.
The property would be more specific equivalent of 'javafx.version'
because these two versions won't advance simultaneously.
Details about versioning
Well, changes in classes referenced by FXML is a bit different story.
This "API" is in fact defined by classpath that is available to
FXMLLoader. And assuring compatibility on this level is more about
JavaFX API backward compatibility, e.g. Scene in JavaFX 8.0 API should
be signature compatible wit
I guess there's the FXML namespace and directives to the Loader as one
consideration, which I think is what you're focusing on here.
The other issue though is changes to the classes that the FXML references. For
example when Builders go, suddenly a whole lot of FXML files will suddenly
become
Hello,
evolution of FXML is meant to be backward compatible. Any change in fx:
namespace (no plans yet) will increase fxml version, but FXMLLoader of
version 2 will load fxml of version 1 and 2, of course. On the other
hand FXMLLoader of version 1 (e.g. JavaFX 2.2.21) won't be able to load
new feat
I think marking the FXML version is a good idea, but not sure what the
implications of an incompatibility are though if it is in the backwards
direction?
There definitely will be version compatibility issues in FXML, but any
backwards compatibility issues will break running apps that are web
deplo
Hello,
I have implemented simple versioning for FXML documents in FXMLLoader, but
without support in tools it won't be very useful. I have agreed with NetBeans
and Scene Builder folks that they will include support for versioning too.
Support means that they will produce document with two XML na
14 matches
Mail list logo
