FXML [was The Next Great Thing: An Application Framework]

[Daniel Zwolenski]

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.
>> 
> 
>