@carlw The local model is simply used to get a reference to the selection, without having to hold on to a reference to the tableview itself. It's better to use a ViewModel, since it also gives you the

bindSelected

functionality for free. I don't know if I quite understood your example, but maybe you want to offer it up as an alternative approach, with code samples?

@edvin I need to look closer at this, but it sounds a lot like something Rx could do the heavy lifting for

I use a pattern often where I have an Observable emit selections and the other table subscribes to them.

@edvin I've been working lately to keep a strict V -> VM -> Model directional relationship to avoid coupling, like having the Model know about the selection in a View (even if it's through the VM). This is to make sure that the design doesn't turn into a monolith.

@edvin I think the requirement is to transfer from one Person List model element to another. The selection should be ephemeral and left off at the ViewModel level.

@thomasnield I'd like to look at that emitter...I built my own based on a simple collection holding Consumers

@carlw working on it right now

@thomasnield Blog post?

@carlw maybe later if there's demand on how to do this stuff. It's already in the "Learning RxJava with JavaFX" guide, but it might be a good idea to create a digestible article to showcase RxJavaFX.

For now I'll add an answer on SO

@thomasnield Great. Having a decoupled model is really important to avoiding fat controllers (not speaking of TornadoFX) that know about each other's view details. This is a big source of side effect bugs and makes a project unagile.

@carlw yeah, that's why I created the

CompositeObservable

when I ran into that issue. I still need to document it which I'll probably do today

@carlw That sounds like a better way to tackle it, by just transferring Person objects and subscribing to them. I guess I just answered exactly what he was asking for, instead of asking about the actual use case. It looks a bit strange, to say the least. Though, to be clear, the model doesn't know about anything at all in this case, and is just used to keep track of the selected person. That's not a misuse of the model in any way IMO.

it's better than having a reference to the tableView.selectedProperty() but seems more like a presentation concept rather than a model concept

thinks like hover, etc should be kept away from the model

I totally agree, and the ui state is not known to the model in any way.

The model is just a container for an object, and we provide some nice shortcuts for TableView to interact with a model. That's why it works so well with the selection.

I see the selection as UI state. To me, it seems like the SO poster is managing two Person Lists and the model doesn't need to know about the pre-Sync state of the TableView selection

The model isn't used for anything else, but it's not correct to say that the model knows about the pre-sync state, or any other state. It knows nothing, it is simply instructed to keep a certain object when the selection changes. It knows nothing about where the item it's asked to keep is coming from, nor that it models any kind of state.

It doesn't know about tableview, selection or any other ui paradigm.

It's going to need to know about a pair of selected items, right? Left and right table selections

laundered through properties

No, the model has one single property, that's the

itemProperty

of type Person.

It has no functions or anything that has to do with the UI.

One view doesn't know that the other exist either.

When the selection of the tableview changes, a listener tells the model to "contain" another item inside the itemProperty. Then when the user clicks the sync button, the item is extracted from that model and fired as an event.

i think there's an opportunity to get the itemProperty details out of the model so that the model is just a pair of PersonLists

That's absolutely a good alternative approach, unless the lists shouldn't know about each other for some reason. Then the model could contain both lists and do everything internally instead of using events. I think though, that the sample is a bit simplistic compared to his actual use case, so we might not know everything we should 🙂

I can ask him more about the use case.

ok. when i get a chance...i'll show you some more code. I actually implemented this requirement, but can't post the code