Modularizing large FX gui apps, esp. using fxml developed by Scene Builder

Question

StarterApp - One large java source file.
Trying Out the JavaFX UI Controls (Using the JavaFX UI Controls)
StageCoach is a simpler app, but with fxml, controller, and main code in separate files.
Allows manipulation using Scene Builder.
https://code.google.com/p/jfxtras/source/browse/ProJavaFX/Chapter03/StageCoach?repo=samples&r=322042d9ac293fcd9dd8f63e1664df45a0c4746f
I was lead to these by the book, Pro JavaFX 8:
http://www.apress.com/9781430265740
Rich as it is, the StartApp is one big piece of code, with no modules such as an fxml file.
By spreading out the code for StarterApp and StageCoach and studying it carefully
I should be able to build a system as large as StarterApp, but as a three-file combo.
StarterApp has nothing that deals with concurrency or persistence - those will be my jobs.
I'm doing this because I'm building a large NLP app.
It needs a GUI for future users.
- Bob F

Answer 1

Take a look at some app examples from the open-jfx repository
  https://wiki.openjdk.java.net/display/OpenJFX/Quick+Start
For a smallish app, see the ConferenceScheduleApp:
   openjfx/8u-dev/rt: 3d138300d935 /apps/experiments/ConferenceScheduleApp/
For a (much) larger app, see SceneBuilder:
   http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/3d138300d935/apps/scenebuilder
   Ladstatt: Home made JavaFX SceneBuilder
For a minimal framework which features FXML and dependency injection, see afterburner.fx:
   http://afterburner.adam-bien.com
You can skip all of the stuff below if you don't like reading and just want to go code...
In general for app code, use aggregation over inheritance in most places, though inheritance is useful sometimes.  Don't try to create your own controls by extending the Control class unless you are writing control libraries - that is complex and not well documented as well as largely unnecessary for app code.  Similarly PopupWindow isn't all that great or at least I have never found a need for it in app code - a basic Stage works fine for pretty much every case except perhaps very specialized things like context menus.  Java 8 has built-in dialogs and alerts in 8u40, so for standard dialogs or some reasonably customized dialogs, using those is better than creating your own.  If the standard controls aren't enough, try ControlsFX, it is (mainly) great and high quality.
Let resizable layout managers do the layout work for you and use constraints in the layout managers and nodes rather than mucking around with fixed sized layouts or layout through binding.
Don't try to implement a spreadsheet in a JavaFX TableView - just use the built-in controls for what they are good at and either develop a new control for specific functionality not provided by the built-in controls or just skip that feature if it would be too expensive to build it from scratch yourself (and it probably will be expensive - you just have to justify that against your project budget whether that is money or your own time).
Make use of WebView to bring in web components (e.g. Google Docs or Google Maps).  Don't try and pass a lot of data back and forth between a WebView and your app.
Don't do any style in code nor in FXML, put it all in a CSS style sheet.
For medium sized apps - use FXML to design and mark-up your GUI, and use SceneBuilder to create and edit the FXML, don't hand code basic form style UIs - in the long run the FXML based app will be easier to maintain.
For really small apps and learning tasks, write everything in code against the API so you understand that - use no FXML at all.
With JavaFX you are writing user interfaces, follow basic user interface design heuristics for which there are some principles to keep in mind.
Once you have a few FXML pages, passing parameters or sharing data between them is a question that most people run into as well as how to deal with navigation.  That navigation framework I linked is super basic and just meant for pretty simple applications.  A nicer framework which worked in general like a Browser navigation model would be useful - but I haven't seen a generic implementation of such a thing yet - I guess you could create one, but I definitely wouldn't start out trying to do that - instead focus on the basics of your application and get that implemented first.  If you end up needing a reasonably sophisticated navigation framework, eventually you will know it and can evaluate what to do then.
You can do an awful lot with CSS and styling the built-in controls.  It really is very flexible.  Learn CSS and the JavaFX variant by reading general CSS tutorials (then forget everything HTML specific) and study in depth the JavaFX CSS reference guide and understand its extensions like looked up colors and derivation functions.  When you want to know how some inbuilt thing is styled, go to the modena.css source (which can be hideously obtuse and complicated).  Use ScenicView and SceneBuilder CSS analyzer to understand how CSS is applied to elements.  Don't style borders with boxes - use layered backgrounds, that is how every control modena.css works and how your app should also work.
Deployment is a difficult topic - so sad and depressing.  For development, just build and run in your IDE.  For production, package the app as a self-contained application. Maybe one day there will be a better deployment model for JavaFX - but that is the best you can get for now.  Completely ignore webstart and web deployment models - any time spent investigating such technologies is completely wasted.
Do not try to integrate JavaFX and Swing or SWT.  Just write pure JavaFX apps.
For larger apps you intend to deploy to production, use Maven or Gradle as your build system (you can google the JavaFX plugins for each).  Do not spend any time with the stand-alone JavaFX packager or the JavaFX ant tasks and do not rely on your IDE to do your production builds.
Get help to targeted questions on StackOverflow.
Only code to Java 8+ and make use of functional programming techniques.
Don't write multi-threaded apps unless you know what you are doing.  When you do write multi-threaded apps, use the JavaFX concurrency utilities.  Never modify the active scene graph from another thread, nor touch a property which might trigger an event which might modify the scene graph.  Do use the concurrency utilities if you have network I/O otherwise you will freeze your app while the network I/O occurs and that is a "bad thing".
The Oracle JavaFX 8 documentation is good - read it and run a lot of the examples (except the ant based deployment ones and the Swing/SWT integration ones).
Ensemble is great, play with it and study the code to see for the samples (which you can view within Ensemble).
Binding is programming by side-effect, so be aware that when you change a property, it may trigger some potentially unrelated action through bindings or attached listeners.
Programming JavaFX in any language other than Java is an experimental thing, so only do that if you like experimenting and are prepared to do so without a lot of support.
Targeting embedded devices, iOS or Android for a JavaFX app is an experimental thing, so only do that if, yada, yada, yada.
JavaFX is a mid-level UI system, not a full application stack - it abstracts away the basics like rendering, controls and animation but does not provide comprehensive OS hooks, navigation frameworks, model/view/presenter frameworks, full dependency injection, client/server messaging, data <-> controls serialization and deserialization, etc.  FXML is just a markup system with a binding capability to Java code.  JavaFX and FXML do not constitute a full application framework.  There is no widely-used full application framework for JavaFX.  Sure some people have tried to create one, but none of those solutions have achieved critical mass of usage and features - plus a one-size fits all application framework will never exist anyway - client applications (e.g. a game versus a line-of-business app) differ greatly and deserve completely different architectures.
There are many things in the Java EE world which can be used in JavaFX (e.g., its dependency injection, its web socket or rest APIs and implementations, its server based systems to allow your app to access cloud based logic and storage, etc) - so feel free to use the bits you need, usually it's as simple as adding additional library dependencies to your maven or gradle project.  A typical medium sized JavaFX application will include multiple third party libraries (mostly non-UI libraries) to get its job done as this will be more convenient than coding everything against the JRE API - though there is an awful lot of out the box functionality you get from the JRE.
JavaFX is more complicated to use than Delphi and in some respects doesn't supply as much functionality in terms of built-in stuff like data base backed tables (though it supplies a ton more functionality in style).  It is not easier to create a complete business app using JavaFX than it would be to create a similar thing in Microsoft Access in the 90's.  Such is progress.
JavaFX is portable across desktop environments (OS X, Windows, Mac).  JavaFX apps have their own look and feel which is not like the native OS, but that is probably fine for a lot of apps.  AquaFX does an amazing job of making a JavaFX app looks like OS X apps (kudos to the creators of both AquaFX and the JavaFX built-in styling capabilities).
Unlike some other portable frameworks like QT, you don't have to write C code, you can write Java code (which to me at least is a win).  Similarly unlike HTML/CSS/JavaScript you don't have to write untyped JavaScript or make use of some obscure code snippet you pulled off the web for your button control.  You don't have to use the web framework of the day which withered yesterday.  Instead you have the (benefit?) of hardly any framework at all for JavaFX.  You don't have to have your app live within a browser sandbox that another developer once described as the ghetto of application sandboxes.
So, as compared to HTML - I think JavaFX is kinder to the developer, though end users don't really seem to care that much and are fairly accepting of HTML applications even when their functionality is often inferior to many more traditional GUI apps.  HTML is standardized, its full of standards, even the non-standard parts.  Everybody used to implement all the standards differently or make their own standards, however now the standards are so painstakingly, nitpickingly prescriptive that everybody implements pretty much the same thing - except when they don't.  JavaFX has no standard but its public API docs, it has just one implementation.  If you code against the API, your app is probably going to work forever - at least if you bundle the runtime with your app, cause if you don't you might end up like the poor guy in the previous question who can't figure out how to update his app specific CSS rules to get his app to look the same with a newer Java version.  JavaFX is a relatively niche technology and you don't have the legion of developers, tinkerers, industry investments and people just plain getting stuff done in any which way that you have with the whole HTML juggernaut.  The major thing that HTML provides that JavaFX does not is: Sharable, browsable deep links to stuff with search indexed content.  With HTML, Google will index it and you can link to and refer to other docs and other docs can link to yours.  It is the HT in HTML which makes the web so amazing and the F in FXML doesn't match it.  What is the F anyway?
That's a huge wall'o'text.  Just some random thoughts and opinions.  All opinions are my own.  Your opinions may vary.  That's OK.  I don't think a discussion is needed.  If you would like any clarification or further advice you can ask in new questions.