[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    FXML [was The Next Great Thing: An Application Framework]
From:       zonski () googlemail ! com (Daniel Zwolenski)
Date:       2012-02-13 12:32:04
Message-ID: 0A30F011-C4AB-4378-9120-717AD670C981 () gmail ! com
[Download RAW message or body]

As Tom says, it's all reflection based, basically the tag <Button text="my button"> \
results in the FXMLLoader instantiating a Button and calling setText("my button") on \
it. You can put your own classes in and provide your own setters too. It's not \
dissimilar to REST style XML/Java mappings but with some extra smarts for JFX \
specific elements like observables and callbacks. 

Its great stuff for doing layouts. The only trouble with it, as far as it being part \
of the 'core' is that it has a distinct 'controller' concept in it, and it forces (or \
at least is heavily biased towards) a specific application architecture. It's not an \
architecture that suits the needs of all (no high level architecture ever does hence \
the drive to keep the core flexible and 'low level'). 

> From what I have understood, this controller concept looks to be in there mainly to \
> support the needs of the SceneBuilder tool, which probably seemed like a good idea \
> in that context but in other contexts it causes trouble. All's clear in hindsight. 

There's room for making it better and I have hopes that it will get there. I've \
floated a few suggestions (such as the ability to inject arbitrary objects into the \
FXMLLoader, thus avoiding a specific 'controller') that would make FXML a little more \
generic/flexible in what patterns/architectures it can be used with, and therefore a \
bit more 'core' friendly. These ideas are being explored and I'm sure those \
conversations will be continued over the coming months. 

By the way you can call a nice FXMLLoader.load("my_window.fxml") and get a scene \
graph back. In fact that's exactly how it works :)

On 13/02/2012, at 9:41 PM, Tom Eugelink <tbee at tbee.org> wrote:

> 
> FXML dynamically maps the XML to the classes, that is how it was possible to (quite \
> easily I must say) add support for MigLayoutFX to FXML. 
> Tom
> 
> PS: partial classes, yeah, that kinda had me spinning my head for a while there \
> when I did some C#. All though I would not mind having mixins back. 
> 
> On 2012-02-13 12:04, Jeff McDonald wrote:
> > Daniel Zwolenski<zonski at googlemail.com> wrote:
> > 
> > > > On a related front, two other areas that in my mind probably would have
> > been better off external to JFX are:
> > 
> > > > FXML: it is built on-top of JFX and so does not need to be part of the
> > core. It also implies a certain MVC architecture, and
> > > > as we've seen that's not ubiquitous (nor is the architecture style
> > chosen particularly in-line with at least a sub-section of the
> > > > community which is an example of the sorts of complications an
> > Application framework creates)
> > 
> > Isn't FXML development closely tied to the components/styles/properties of
> > a specific release version. If so, then developing the JavaFX core and FXML
> > in lock-step is the way to go, otherwise there would be version concerns.
> > 
> > FXML is still a "what is it?" kinda thing for me. At first I thought it was
> > more like a serialization format for JavaFX, but there seems to be more to
> > it. It would be nice to call some like FXML.build("my_window.fxml") and
> > then get a nice object graph back.
> > 
> > At least the JavaFX team didn't follow Microsoft's lead and add partial
> > classes to Java like MS did in .net.
> > 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]