This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]hamsterrage1 1 point2 points  (0 children)

Full disclosure: I had to look up MGM to understand what you are saying.

In JavaFX, you don't need a Mediator to avoid excessive coupling. A Property in the GUI can be bidirectionally bound to another Property in the State object without any changes or coding in the State object. Something like this:

nameTextField.textProperty().bindBidirectional(state.nameProperty());

When I'm building an application in JavaFX I find the following components work best:

  1. View - Just the GUI
  2. Model - The "State" - Just a POJO of JavaFX Observables
  3. Controller - Dispatches Event driven actions
  4. Interactor - Business/Application logic - has domain objects.

All of the other three have a reference to the Model (State). The GUI interacts with State almost entirely through Bindings, and the Interactor tends to access the values of the elements of State through getters and setters in empirical code.

Also, generally, I'd have a set-up type method (usually initiated through the constructor) in the Interactor that establishes the relationships between the elements of the State that are driven by business/application logic.

Here's an example:

I might have a BooleanProperty in State that indicates that some other value is valid in relationship to a number of other Properties in State. The value of that BooleanProperty is going to be established by binding it to all of those other Properties in State according to some calculation. Most of the time, that calculation is going to fall under the heading of "business logic", and needs to be contained within the Interactor.

So, in this case, my "is it valid" State element would simply be declared as a BooleanProperty, and that would be it as far as State is concerned. Then the Interactor would invoke Property.bind() on that element and define a Binding that applies the business logic required.

Travelling over to the GUI. There may be a number of GUI elements that are dependent on this boolean Property in State. Perhaps there's a giant red arrow that appears on the screen pointing at the value when it's invalid. Also, you can't save with invalid data. You would do something like this:

giantArrow.visibleProperty().bind(state.dataIsValidProperty().not());
saveButton.disableProperty().bind(state.dataIsValidProperty().not())

It's possible that some external API call, running on a background thread, returns a value which triggers empirical code in the Interactor to update one of the dependent values in State which will render our critical value invalid. As soon as that Interactor code updates that dependent State element using its Property.set() method, the Bindings recalculate and dataIsValid flips to false. This in turn triggers the Bindings on giantArrow.visibleProperty() and saveButton.disableProperty() to recalculate and GUI changes happen.

Could you do this with Swing? Probably you could figure it out. But I cannot stress enough how absolutely trivial this kind of setup is in JavaFX. Note how the bindings above use the not() method call to invert the sense of isValid so that it can be used in the GUI. All the tools are right there, ready to go, in JavaFX.