Hello, are you suggesting to use various fx:versions on multiple elements in one FXML file? It seems very unlikely that we would want to mix more versions of the same class in one document. I've suggested to use default namespace, because JavaFX API classes basically are (default) namespace for the FXML document, in fact namespace of the document is defined by classpath.
On the other side XML diffing might really have problem when using FQN, because those names won't match even for the same elements. I'm not expert in XML document versioning though and I cannot say how important it is. Don't know if it's an argument, but XML default namespace is actually feature of XML and as such it's for free for us. Using fx:version attributes must be defined, designed and implemented. Please note that due to nature of FXML - elements are defined by classpath - the version of FX API should not be strictly checked, the version number just says what version of JavaFX API was used to create the document. This information can be then used by tools somehow. Milan Dne 5.7.2013 18:59, Danno Ferrin napsal(a): > I may be coming into this a little late, but I have concerns about > using the default namespace for version identification. I feel a > namespaced attribute in a namespace fixed across versions to identify > the semantics would be a better choice, i.e.: > > <?import javafx.scene.control.*?> > <Button text="press me" xmlns:fx="http://javafx.com/fxml/1"; > fx:version="2.2"/> > > <?import javafx.scene.control.*?> > <Button text="press me" xmlns:fx="http://javafx.com/fxml/1"; > fx:version="8.0"/> > > My concern is that tool automation that is sensitive to fully > qualified names may have a difficult time interacting with what > amounts to namespaces that can arbitrarily changed underneath them. > As is stands the tools need to look at namespace-aware attributes to > determine some values (such as fx:id) so simply turning off > namespacing is a problematic choice already. One very problematic > application would be XML diff tools, as making them match some > namespaces and not others can be difficult. The entire document would > become a diff then since the FQ name of the root node is different. > > On Fri, Jul 5, 2013 at 9:17 AM, Eric Le Ponner > <eric.le.pon...@oracle.com <mailto:eric.le.pon...@oracle.com>> wrote: > > Hi Milan, > > This looks good. > > Note that, since b28, Scene Builder 1.1 now generates FXML files > which include: > xmlns:fx="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 version > management (to be defined). > > Cheers. > > Eric > > > > > From: Milan Kubec <milan.ku...@oracle.com > <mailto:milan.ku...@oracle.com>> > > 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@openjdk.java.net > <mailto:openjfx-dev@openjdk.java.net>" > <openjfx-dev@openjdk.java.net <mailto:openjfx-dev@openjdk.java.net>> > > Reply-To: milan.ku...@oracle.com <mailto:milan.ku...@oracle.com> > > > > 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 and proposed namespaces are described > in issue: > > https://javafx-jira.kenai.com/browse/RT-28599 > > > > Thanks for comments > > > > Milan > > > > > > Dne 7.6.2013 10:49, Milan Kubec napsal(a): > >> 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 namespaces - one defines version of > fx: prefixed elements and attributes (xmlns:fx; it's already > there, just the version is appended) and the other of actual > JavaFX API used to produce document (xmlns; default, no prefix). > The first will be checked, because wrong version can cause > failure. The latter is only informational, no strict checking of > version is possible, but tools can suggest to upgrade runtime, > translate document etc. > >> > >> JavaFX API version is stored in System Properties as > "javafx.version". The open question is still where and how to > store fxml version in code. I think that we could have also > property for this purpose, e.g. "fxml.version" in System > Properties. So far it's part of FXMLLoader API, which is probably > not very fortunate. What do you think? > >> > >> Issue details: https://javafx-jira.kenai.com/browse/RT-28599 > >> > >> Milan > >
