Hi Danno, Scene Builder relies on FXMLLoader: - it won't open an FXML file whose fxml.version does not match FXMLLoader own version - it will attempt to open an FXML file no matter javafx.version but this may fail if SB FX SDK is no longer compatible with the FX version specified in the 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: Tue, 9 Jul 2013 08:41:13 -0600 > From: Danno Ferrin <danno.fer...@shemnon.com> > To: Svata Dedic <svatopluk.de...@oracle.com> > CC: openjfx-dev@openjdk.java.net > > > 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 about messy XPaths is less of a problem because the check is once > at the root. > > So one question I have is are the existing tools (SceneBuilder, FXMLLoader) > paying attention to the attributes and loading them any different if > anything other than the current version is detected? Is that in the long > term plans? > > > On Tue, Jul 9, 2013 at 5:44 AM, Svata Dedic <svatopluk.de...@oracle.com>wrote: > > > 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<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 creatively handle namespace with > > URIs matching a certain prefix. > > > > But... consider the FXML file as a XML document. It's grammar must > > correspond to the version of Javafx runtime - or at least to one of the > > already released past versions. I.e., the FXML should not use an unknown > > property or unknown class (more on the classpath contents concept below). > > So each version of Javafx runtime library constitutes a set of tags for > > classes, for class properties and events - which means a XML schema could > > be eventually generated for each javafx release. And XML schemas are > > usually identified by their target namespace URI and referenced using a xml > > namespace prefix declared in the document. > > In addition, we *need* a namespace different from the fx: namespace: while > > the [default] namespace contains elements from the javafx runtime > > "language", the fx: namespace contains elements from the FXML loader > > "language" (references, includes, ids). As Milan has pointed out, those > > languages are likely to evolve independently, but definitely have different > > 'schemas' (although generated). > > > > Consider for example a XSLT-based tool for FXML translation or processing: > > it can react appropriately to XML elemnents targetting different javafx > > runtimes, allowing to develop a XSLT-based transformation which is > > universal. If fx:version was used, matching in XSLT and XPaths would be > > unnatural to those languages instead of matching just for QName, you need > > to construct a XPath expression like > > /*[fx:version='8']//javafx:**AnchorPane > > or even more bloated syntax. > > > > From this point of view, using XML namespace makes a lot of sense for XML > > processing tools than fx:version, with an implicit rule to inherit > > fx:version down the element hierarchy until a different one is found. > > > > As for the 'classpath contents' concept: there's one unresolved issue with > > either fx:version or xmlns declaration. We allow to declare the version of > > javafx runtime in the fxml, but the actual usable language (components, > > their properties and events) are defined by the contents of the classpath, > > that possibly contain additional libraries. > > > > Right now, a 3rd party (e.g.) ChoiceBox component element will use a QName > > from javafx namespace as if that component was a part of core javafx > > runtime library, which does not as the "right XML way" (but it's the way > > how FXML works at the moment). > > While we now define a versioning mechanism for our own library (javafx > > runtime), we do not define anything that can be useful by 3rd party vendors > > to version their component state persisted in FXML - which is a pity. > > > > > > On 07/09/2013 11:57 AM, Werner Lehmann wrote: > > > >> 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: > >> > >> <?xml version="1.0" encoding="UTF-8"?> > >> > >> Using a processing instruction could be used if ever just one version > > applies to the entire FXML source. While processing instructions apply in > > textual order, FXML elements nest, so multiple PIs would bring a total > > havoc to the processing tools. > > > > My preference would be: > > 1/ versioned xml namespace. Each QName then represents an entity as > > specified by whatever javafx release. Conforms to usual > > backwards-compatible XML format evolution rules > > > > 2/ processing instruction. Out of band for most tools. I didn't think > > about this mechanism before - sorry, Milan. > > > > ... > > > > 99/ special attribute. Provides no processing benefit, while complicates > > both matching and validation, i.e. non-standard way to suggest appropriate > > schema. > > > > my 2 cents, > > -Svata > > > > > > My 2c. > >> > >> Werner > >> > >> On 09.07.2013 09:06, Milan Kubec wrote: > >> > >>> This information can be then used by tools somehow. > >>> > >> > > >
