This discussion is archived
1 2 3 Previous Next 33 Replies Latest reply: Oct 27, 2011 9:38 AM by RichardBair Go to original post RSS
  • 15. Re: FXML suggested improvements
    MiPa Pro
    Currently Being Moderated
    You can always do something like this:
    ChoiceBox<String> languageChoiceBox = (ChoiceBox<String>)root.lookup("#languageChoiceBox");
    Assuming "root" is the top-level element you have created via FXML and "languageChoiceBox" is the fx:id
    given to the element you want to look up. Note the # in the lookup string.

    Edited by: MiPa on 20.10.2011 06:11

    Edited by: MiPa on 20.10.2011 06:13
  • 16. Re: FXML suggested improvements
    885691 Pro
    Currently Being Moderated
    My problem is this:

    I'm composing complex forms with JavaFX right now. I'm using a Guice-constructed controller to abstract away the database. With the namespace approach, I'm now able to push my custom made controller instance into the FXML for use there. Using FXML ${} syntax, I'm able to pull the values from the custom controller to the GUI.

    But my custom made controller is not able to access the GUI components, to for example get the value of a text field on screen, which it needs in order to save it to the database. @FXML annotations only work on the implicit controller specified in the FXML.

    So, as far as I can see, only half of the problem is actually solved by the namespace approach, given that the objects inserted into the FXML namespace don't have any access to the actual components on screen, the communication goes one way.

    Am I missing something obvious here?
    You aren't missing anything. I think the controller enhancements I mentioned earlier will help address most of these issues.

    Also, see my comment above about using includes to implement multiple controllers. By design, an FXML document is intended to be associated with only a single controller (though again, there may be cases when you want to associated more than one FXML doc with the same controller).

    It may help to think of an FXML document like a class. As I mentioned earlier in the thread, an MXML document in Flex or a XAML document in WPF is actually compiled into a class. Specifically, in .NET, a XAML document is optionally associated with a "code behind" file, written in C# or other CLR language. Microsoft calls these "partial classes" - part of the class is defined by the markup, and the other by the "code behind".

    We don't support partial classes, but the concept is the same: you define your UI structure in markup (FXML) and your "code behind" in your controller. The two are intrinsically related and combine to form a single coherent unit.

    Again, the enhancements we've been talking about will ultimately allow you to do a lot more with the controller than is currently possible. I think that once these features are available it will be a lot easier to implement the sort of solution you are describing.

    G
  • 17. Re: FXML suggested improvements
    875756 Pro
    Currently Being Moderated
    Hi Greg,

    It's good to hear there is something on its way for controller injection. It would be great to know more about it before it gets officially released. Once it's out there it's pretty much locked in and these early stages are the best time to get feedback and adjust if necessary.

    I see that you reference both Microsofty and Falshy style tools and technologies in the design influences. I think it is good that this is being used as input as JFX aims to compete in this space. It's my hope (dream) however that JFX is also hoping to take over the JSP/AJAX space, i.e. 'JEE' applications. In order to do this, I think it would be great if these technologies were analyzed and used as inputs as well.

    In particular it would be great if there was some general review of the use cases trying to be solved and the approaches used for GWT, Spring, SpringMVC, Struts2, Tiles, JSF, Guice, general AJAX, velocity, EJB3, Hibernate, Spring Remoting and similar. I get the general feeling that most of the people who are supportive of my original proposal (which is very much in this style) are coming from this background and are finding it hard to use FXML to solve their use cases in an architecture that fits in with these.

    These sorts of developers didn't come across to JFX1 because it was too far down the flashy/scripty end of the pool and it was not possible to cleanly use this within the bigger JEE ecosystem. Clean architecture (separation of concerns, dependency injection, loose coupling, no statics) is, in my experience, given a much higher weighting in JEE apps than it is in Flash, VB.net, ActionScript style applications (I have programmed heavily in both over the years - creating https://coinland.com.au/ in Flash+Java for example really highlighted the different approaches the languages/communities encourage).

    The JEE community could always build its own FXML-like toolkit to do support specifically for our needs, and probably will if the native FXML doesn't get there, but it would be far, far better to have the core, official FXML engine support the full spectrum of developers. I have a few questions in particular about your next round of FXML changes that it would be great to know about and ideally sort out options before release where it all becomes locked in:

    * Will the controllers still be defined by a classname or is it just an arbitrary name that the factory can use as a lookup? If a classname, will we be able to use an interface (MyController) and then have the factory supply an implementation (MyControllerImpl) and it still do all the binding (how would properties work)? If an arbitrary name, what will this mean for RAD tool support?

    * Will controller inheritance be supported? If I have several views that all have a 'save' button for example, will I be able to define a BaseSavingController that defines the save button and also an abstract save() method and have the FXMLLoader pick this up?

    * Will we be able to bind the same controller instance to mutliple views? If so, what will happen to a field (say a button with id 'save') if it exists in both views? Once binding support is added, what will happen to a property - will FXML allow it to be bound to multiple properties in several views (e.g. the same person.name property bound to several fields across several views)? Will FXML allow the same callback method to be bound to by different views.

    * Will we still need to annotate things with @FXML? This doesn't add any value (or what is the value? the view has intimate knowledge on the controller whether the @FXML is used or not), and is just an extra step (forget and you only find out at runtime) and also puts FXML dependencies in our code (what if I later decide to use my controller with a non-FXML view, etc - ideally it would be view agnostic).

    * Will we be able to define an FXML file that has a ListView (or other container-style view) in it, and then have its controller populate the list with custom cells loaded from separate little FXML files based on the data type at runtime? Will the little FXML's be able to use/reference the controller of the containing view or somehow be wired up to methods in the containing controller?

    * Will the event callback matching still be as strict as it is now? Can we define our controllers to call #doSomething and have the FXMLLoader match this to a doSomething that doesn't take an ActionEvent as a parameter (i.e. match the ActionEvent one if it is there, but if not, look for a parameterless one). The ActionEvent is generally redundant (whereas MouseEvent may be more useful), and if I want to call a method (e.g. save()) from within my own code I have to pass in a null ActionEvent - like with the @FXML tag the controllers could be more view/technology agnostic.

    * Will there be any way to parameterise a callback. If I have ten buttons in my view, could I, for example have each button trigger a callback with an enum value as parameter (e.g. #showPage(Page.personDetails) vs #showPage(Page.personGroups) ) - instead of having to create 10 methods (showPersonDetails(), showPersonGroups(), etc). Will there be any elegant way to do this in FXML.

    One use case that I would love to be able to do, is use FXML for creating dynamic forms (i.e. the form structure is created by the user, it is not part of the code). FXML is the most perfect templating language for this (combine it with something like velocity and the possibilities are incredible).

    In this case the form cannot be hard-bound to a controller as the fields are data-driven. I would ideally like to be able to bind my form fields to a Map and be able to pull all the values back out as a map so I can save them back to the database. I can probably do something using the namespace at the moment to populate it, but I cannot see a way to get the values back out, except possibly using the little trick MiPa gave above with the root.lookup("#fieldName") (awesome tip by the way MiPa, nice one).

    FXML is awesome. We love it. We just need it to be flexible enough to cover our use cases without hurting our architecture. The controller factory may help with this, but I suspect it won't go all the way. My proposed variable declaration is one option, but I'd take anything that lets us use FXML in a pure-view way with minimal tight-coupling back to the controller.

    Cheers,
    zonski
  • 18. Re: FXML suggested improvements
    895253 Newbie
    Currently Being Moderated
    Greg: Looking forward to the controller enhancements.

    I believe my requirement is rather common for enterprise application:

    - Dependency injection into the controller (database, resource). Enables easy running and testing of a single scene in isolation.
    - Initialize a form with entity data that should be edited. Right now, you can only edit an empty form, the controller could not possibly know what should be edited.

    Thanks for the quick and in-depth feedback, you guys! :)
  • 19. Re: FXML suggested improvements
    895253 Newbie
    Currently Being Moderated
    zonski: Excellent overview of the situation. I'm glad I'm not sitting on the other side of the table, as this is very complex stuff :) I can see the conflict for the JavaFX guys. I suspect that at least in this early phase, they are primarily focusing on the less complex sides of the framework, trying to build a good basic toolkit for simple widgets and apps. Based on the JavaFX 2.0 example collection , this is clearly the case. Very little focus on complexity in forms and app navigation. It's too bad that this part, which is what our company really needs, has lower priority. But I can see why.

    I agree with zonski, FXML looks very promising. Not very much left to do to provide some very real value for my company. But still not quite there.
  • 20. Re: FXML suggested improvements
    895253 Newbie
    Currently Being Moderated
    MiPa:

    That's an excellent workaround for now. Thanks!
  • 21. Re: FXML suggested improvements
    885691 Pro
    Currently Being Moderated
    Will the controllers still be defined by a classname or is it just an arbitrary name that the factory can use as a lookup? If a classname, will we be able to use an interface (MyController) and then have the factory supply an implementation (MyControllerImpl) and it still do all the binding (how would properties work)?
    I imagine it would still be a class name. Since fields are injected by reflection on the type of the actual controller instance, this would still work regardless of whether the class implements an interface or not.
    Will controller inheritance be supported? If I have several views that all have a 'save' button for example, will I be able to define a BaseSavingController that defines the save button and also an abstract save() method and have the FXMLLoader pick this up?
    This is possible. I believe there is already a feature request to support this, but feel free to create one if not.
    Will we be able to bind the same controller instance to mutliple views? If so, what will happen to a field (say a button with id 'save') if it exists in both views?
    Controller instances cannot be shared. However, controller types can be shared. Each view will get its own copy of the controller. If your controllers need to share state, you could use statics or a message bus.
    Will we still need to annotate things with @FXML?
    Not necessarily. If you don't need to inject any controller fields, and all of your controller methods are public, you probably wouldn't need it.
    Will we be able to define an FXML file that has a ListView (or other container-style view) in it, and then have its controller populate the list with custom cells loaded from separate little FXML files based on the data type at runtime? Will the little FXML's be able to use/reference the controller of the containing view or somehow be wired up to methods in the containing controller?
    You can currently do this programmatically by calling FXMLLoader#getController() - not sure if it makes sense to support it directly in FXML or not.
    Will the event callback matching still be as strict as it is now? Can we define our controllers to call #doSomething and have the FXMLLoader match this to a doSomething that doesn't take an ActionEvent as a parameter (i.e. match the ActionEvent one if it is there, but if not, look for a parameterless one).
    This is possible, but I'm not sure I see a particularly strong argument for it. Controllers are meant to bridge the gap between dynamic markup and compiled code (where such strict typing is required). If you need this type of flexibility, a scripting language may be more appropriate (you don't need to declare the event argument in a script-based event handler).
    Will there be any way to parameterise a callback. If I have ten buttons in my view, could I, for example have each button trigger a callback with an enum value as parameter (e.g. #showPage(Page.personDetails) vs #showPage(Page.personGroups) ) - instead of having to create 10 methods (showPersonDetails(), showPersonGroups(), etc). Will there be any elegant way to do this in FXML.
    As in Swing/AWT, you can do this by looking at the source of the event. You can also attach additional metadata to the buttons using the "properties" colllection:
    <Button fx:id="detailsButton" text="Details">
        <properties key="details"/>
    </Button>
    
    <Button fx:id="groupsButton" text="Groups">
        <properties key="groups"/>
    </Button>
    One use case that I would love to be able to do, is use FXML for creating dynamic forms (i.e. the form structure is created by the user, it is not part of the code). FXML is the most perfect templating language for this (combine it with something like velocity and the possibilities are incredible). In this case the form cannot be hard-bound to a controller as the fields are data-driven.
    This also sounds like a good case for script code, either dynamically generated or authored by the user who created the form.

    Using Velocity to generate FXML would be very cool! :-)
  • 22. Re: FXML suggested improvements
    RichardBair Journeyer
    Currently Being Moderated
    I wrote another blog post this evening after having played with some of the concepts you guys have been talking about, using Guice as my DI engine.

    http://fxexperience.com/2011/10/fxml-guice/
    Will we be able to bind the same controller instance to mutliple views? If so, what will happen to a field (say a button with id 'save') if it exists in both views?
    Controller instances cannot be shared. However, controller types can be shared. Each view will get its own copy of the controller. If your controllers need to share state, you could use statics or a message bus.
    I think if the injection mechanism is correctly handled, then we can leave it up to the application as to whether the controller supplied during load is shared or not. It seems like the ControllerBuilder can do whatever it wants -- return a new instance or reuse an existing instance. Basically it is just a call-out, where the FXML load engine will say "please give me a FooController", and the builder can then ask the Guice Injector (for example) for such an instance, and the Guice Injector may return the same controller instance as previously used, a new instance, or perhaps some subclass of the expected type. All these seem like they should be valid scenarios.
    Will we be able to define an FXML file that has a ListView (or other container-style view) in it, and then have its controller populate the list with custom cells loaded from separate little FXML files based on the data type at runtime? Will the little FXML's be able to use/reference the controller of the containing view or somehow be wired up to methods in the containing controller?
    You can currently do this programmatically by calling FXMLLoader#getController() - not sure if it makes sense to support it directly in FXML or not.
    I think we do want to do this. I want to be able to use the Scene Builder to construct the various Cell templates, and to have these then be FXML such that they can be used. We haven't thought about this yet though and it will take some thinking.
    Will the event callback matching still be as strict as it is now? Can we define our controllers to call #doSomething and have the FXMLLoader match this to a doSomething that doesn't take an ActionEvent as a parameter (i.e. match the ActionEvent one if it is there, but if not, look for a parameterless one).
    This is possible, but I'm not sure I see a particularly strong argument for it. Controllers are meant to bridge the gap between dynamic markup and compiled code (where such strict typing is required). If you need this type of flexibility, a scripting language may be more appropriate (you don't need to declare the event argument in a script-based event handler).
    I really would like to see us not be as strict. The first FXML / Controller I wrote had an action handler that didn't need the MouseEvent or ActionEvent, so I didn't include it in the method signature, and was promptly wrist-slapped by FXML. I would rather we relaxed this (if the Controller doesn't need a UI class, why should we require it?).

    Cheers, have a great weekend all.
    Richard
  • 23. Re: FXML suggested improvements
    885691 Pro
    Currently Being Moderated
    I think if the injection mechanism is correctly handled, then we can leave it up to the application as to whether the controller supplied during load is shared or not.
    I agree - the same thought occurred to me yesterday. But any developer doing this needs to be aware of the implications (e.g. @FXML should not be used to inject field values in this case).
    I really would like to see us not be as strict. The first FXML / Controller I wrote had an action handler that didn't need the MouseEvent or ActionEvent, so I didn't include it in the method signature, and was promptly wrist-slapped by FXML. I would rather we relaxed this (if the Controller doesn't need a UI class, why should we require it?).
    It's not that we require a UI class - it's just that the signature needs to match the signature of an event handler, which takes a subtype of Event and returns void. It's same for delegates in C# or the proposed lambda syntax in Java 8 - the method signatures just need to match.

    Of course, we don't have to enforce this - we could allow a no-arg method to be used. But then you lose the source of the event as well as any other information associated with it, which may lead to poor programming practices if the developer is not aware that an event can be passed to the handler.

    To me, it just doesn't seem like a huge imposition on the developer to require the event arg, especially if it helps minimize confusion.

    G
  • 24. Re: FXML suggested improvements
    RichardBair Journeyer
    Currently Being Moderated
    Greg Brown wrote:
    I think if the injection mechanism is correctly handled, then we can leave it up to the application as to whether the controller supplied during load is shared or not.
    I agree - the same thought occurred to me yesterday. But any developer doing this needs to be aware of the implications (e.g. @FXML should not be used to inject field values in this case).
    Good point.
    I really would like to see us not be as strict. The first FXML / Controller I wrote had an action handler that didn't need the MouseEvent or ActionEvent, so I didn't include it in the method signature, and was promptly wrist-slapped by FXML. I would rather we relaxed this (if the Controller doesn't need a UI class, why should we require it?).
    It's not that we require a UI class - it's just that the signature needs to match the signature of an event handler, which takes a subtype of Event and returns void.
    Means the same thing in either case ;-). But it is true it isn't so much that requiring some UI class (like MouseEvent) is the main issue. It is rather the other -- I wrote an action handler that didn't need the MouseEvent or ActionEvent, so I didn't include it in the signature and was promptly wrist-slapped by FXML. It still stings :-)
    It's same for delegates in C# or the proposed lambda syntax in Java 8 - the method signatures just need to match.

    Of course, we don't have to enforce this - we could allow a no-arg method to be used. But then you lose the source of the event as well as any other information associated with it, which may lead to poor programming practices if the developer is not aware that an event can be passed to the handler.

    To me, it just doesn't seem like a huge imposition on the developer to require the event arg, especially if it helps minimize confusion.
    I don't think there is any impact on confusion -- if anything not requiring the parameter would decrease confusion for me. Like I said, I tried this first and it didn't work, which confused me. I believe the Swing Application Framework allowed for this kind of inference (it had @Action annotation support on methods). FXML being markup also gets one thinking of HTML / JavaScript, which also allows for optional args. We really should relax this constraint and allow for "submit()" to not require the ActionEvent. For another reason, I might want to invoke submit() not based on an ActionEvent but based on a KeyEvent or MouseEvent. In such cases, I would need three different sumbit() methods with the right signatures which would be a shame. Instead, I could just have one and it is called based on all such events.

    Of course I could resort to using JavaScript in the FXML to handle the events and call the submit method (sans arguments), but that would be a shame since I'm having to use JavaScript just to do something we could easily support out of the box.

    There is an issue regarding what happens when there is both a submit(ActionEvent) and submit() method. Of course in such a case, the most specific declaration wins.

    Cheers
    Richard
  • 25. Re: FXML suggested improvements
    885691 Pro
    Currently Being Moderated
    It's not that we require a UI class - it's just that the signature needs to match the signature of an event handler, which takes a subtype of Event and returns void.
    Means the same thing in either case ;-).
    OK, in this context I agree. My point was just that the signature isn't inherently UI-specific, because the Event class is not tied to the scene graph.
    FXML being markup also gets one thinking of HTML / JavaScript, which also allows for optional args.
    It is true that JavaScript allows for optional arguments in a method signature - however, this is a slightly different case. An event handler is more like a delegate. When you write your event handler in script, you are effectively providing the body of the handler function. FXML loader provides the "wrapper" by which this code is called:
    <Button text="My Button" onAction="doSomething(); doSomethingElse(event);"/>
    This wrapper takes an implicit argument named "event" that contains the properties of the event that is currently being handled (same as HTML). So it's not that this argument is "optional", per se - it's just that your event handing code isn't required to refer to it.

    When we specify a controller method event handler, we name the method that will be called when the event is fired:
    <Button text="My Button" onAction="#handleMyButtonAction"/>
    @FXML
    protected void handleMyButtonAction(ActionEvent event) {
        doSomething();
        doSomethingElse(event);
    }
    However, in this case, the "wrapper" is not automatically generated by FXMLLoader - it needs to be explicitly specified in code. If you were to register a similar event handler in XAML/C#, the event argument would not be optional:
    <Button Content="My Button" Click="myButton_Click"/>
    private void myButton_Click(object sender, RoutedEventArgs e)
    {
        doSomething();
        doSomethingElse(sender, e);
    }
    It also won't be optional if you wire up the handler programmatically in Java 8.

    I'm not saying these arguments are necessarily conclusive - just something to think about. Also, your point about conflicting method signatures raises another interesting issue. Yes, we could work around it by choosing the most specific signature, but that feels a bit hacky.
  • 26. Re: FXML suggested improvements
    RichardBair Journeyer
    Currently Being Moderated
     
  • 27. Re: FXML suggested improvements
    875756 Pro
    Currently Being Moderated
    Just as a point of reference, Spring controllers use a looser binding approach. That's not to say that FXML should as a result, but there is some precedence and maybe checking this out might give some ideas and/or highlight risks. Check out the 'FLEXIBLE HANDLERS' bit of this:

    http://blog.springsource.com/2007/11/14/annotated-web-mvc-controllers-in-spring-25/

    While you guys are on the topic, what's the thoughts on @FXML annotation being required for callback methods and for fields? Does this add value? For me, the less FXML specifics in the controller the better. I'd like to be able to swap between an FXML view and a Java one (or Groovy or whatever) without changing the controller. This isn't real feasible with the current features but if you guys get bidirectional binding going then the controllers should just be able to expose properties that form the 'presentation model' instead of actual Controls and this would get interesting.

    I'm also really keen to have inherited fields and methods get supported (there is a Jira for it, just pushing it so it doesnt get missed). This would make a big difference to the stuff I'm doing on http://zenjava.com which is where I'm outlining my slightly different usage of fxml, although if you have alternative suggestions to anything on there I'd love to hear about them.

    Just out of curiosity, aren't you guys in the same office? Are you just using the forum for this discussion for our benefit, or is this how you guys communicate with each other at work? :)
  • 28. Re: FXML suggested improvements
    885691 Pro
    Currently Being Moderated
    Just as a point of reference, Spring controllers use a looser binding approach...Check out the 'FLEXIBLE HANDLERS' bit of this:
    http://blog.springsource.com/2007/11/14/annotated-web-mvc-controllers-in-spring-25/
    Thanks for the tip - I'll check it out.
    While you guys are on the topic, what's the thoughts on @FXML annotation being required for callback methods and for fields?
    The annotation actually isn't required. If your fields/methods are public, you don't need to use it.

    However, if your fields or methods are not public, the annotation provides a small measure of security. Since FXMLLoader will only write to annotated non-public fields or invoke annotated non-public methods, it helps ensure that a malicious coder can't use FXML to inject your fields with bogus data or invoke handler methods inappropriately. Of course, there are other ways to get around that, but the annotation at least offers some minor degree of protection.
    I'd like to be able to swap between an FXML view and a Java one (or Groovy or whatever) without changing the controller.
    The annotation certainly doesn't preclude that. It just serves as a flag to FXMLLoader - when you are not using FXML, it would simply be ignored.
    I'm also really keen to have inherited fields and methods get supported (there is a Jira for it, just pushing it so it doesnt get missed).
    I can definitely understand the use case for using inherited methods as event handlers. However, I wonder if it would make sense to restrict this to inherited public or protected fields and methods. I'm not convinced that we should be injecting data into into private inherited fields or exposing private inherited methods.
    Just out of curiosity, aren't you guys in the same office?
    We're actually in different offices. I've just been continuing the conversation here because it seems to be of interest to the community and will help us better understand what developers might want to do with FXML.

    G
  • 29. Re: FXML suggested improvements
    875756 Pro
    Currently Being Moderated
    Thanks Greg.

    I had an interesting, left-field thought last night after reading your response, which I'm still mulling over. I'm going to outline the thought here - I'm not sure if it's a good idea or not and it may be too far from the core FXML architrecture anyway. Just more food for thought (I'm sure you're getting sick of me though!).

    The way I'm using FXML is that it is basically the view implementation. The @FXML annotations are really defining the interface between the controller and the view. Following this trail I started wondering if there would be any way (and any merit) in defining an interface for the view, instead of using the annotations.

    Say I had this FXML
     
    <StackPane>
        <children>
            <Label fx:id="messageLabel"/>
            <Button fx:id="clickMeButton" text="Click Me"/>
        </children>
    </StackPane>
    Then the view interface could be:
    public interface MyView
    {
        Label messageLabel();
    
        Button clickMeButton();
    }
    The FXML Loader could then just return an instance of this interface (create a Proxy instance on the fly that maps the method calls appropriately).

    If we had some way of exposing properties via the FXML then we could really end up with a nice interface to the view that exposes none of the implementation details. The GUI designer could swap between a Button or a Hyperlink or some other control, without the Controller code needing to be touched.

    Our interface could end up like:
    public interface MyView
    {
        StringProperty messageLabelProperty();
    
        StringProperty clickMeLabelProperty();    
    }
    Which maps to some (currently impossible) FXML:
    <StackPane fx:view="com.blah.MyView">
        <children>
            <Label text="bind:messageLabel"/>
            <Button text="bind:clickMeLabel"/>
        </children>
    </StackPane>
    This seems like a pretty clean separation. Our controller is accessing an interface for our view, FXML is a pure implementation detail. Changes in the controller do not affect the view, changes in the view do not affect the controller (unless the interface changes between them, in which case they both change to match). The RAD tool could generate the interfaces straight off the FXML, and the code writers could just use that and never have to deal with FXML at all if they don't want.

    This is all for field injection, not controller callbacks though. The callback mechanism is already a pretty clean separation, and the way the handlers get called is already quite decoupled (exccept for the fact that we have to tightly define the controller implementation in the view, can't use an interface for our controller definition, or inject it - but that's all been discussed above and is no different).

    One bonus thing that could be done with the view interface thing though would be to support an optional method called setController(AnyType controller) that allowed the coders to pass in a controller after the view was created. The Proxy class would just delegate back to whatever instance was passed in.

    We could get some serious, pure-code controller injection then! If we could also use interfaces for our Controllers, the separation would be perfect.

    Something like:
    public interface MyView
    {
        void setController(MyController myController);
    
        StringProperty messageProperty();
    }
    public interface MyController 
    {
        void sayHello();    
    }
    public class MyControllerImpl implements MyController 
    {
        private MyView myView;
    
        public MyController(MyView myView)
        {
            this.myView = myView;
            this.myView.setController(this);
        }
    
        public void sayHello() 
        {
            myView.messageProperty().set("Hello!");
        }
    }
    <StackPane fx:controller="com.blah.MyController" fx:view="com.blah.MyView">
        <children>
            <Label text="bind:message"/>
            <Button text="Say Hello" onAction="#sayHello"/>
        </children>
    </StackPane>
    Then your assembly (factory class, startup class, whatever) just assembles it all together:
    MyView myView = FxmlLoader.load("myview.fxml");
    MyController myController = new MyControllerImpl(myView);
    As I said, might be too big a jump for FXML, but it has potential as an idea and might be worth tossing around at any rate.

    zonski