yeah this is still an issue i have as well. I really don't want my domain model to have any ties to javafx and in some cases its not MY model to change. So like Brian, i end up with a ViewModel that mostly wraps a domain model, adds an old school listener and and updates its JavaFX Properties when the underlying domain model changes. Which is ok for now, but seems less than ideal

It might be just a constraint. If you have a rich domain model used elsewhere (ejb web etc) coupled with valuable validations then the layers might be justified

right now in my domain models im using the kotlin observable delegate to facilitate an old school PropertyChangeListener pattern. The ViewModel adds a a listener and updates its properties based on the updates. It works fairly well.

Does any of you guys have experience with arrow - and maybe even used it with tornadofx? I do not have any particular question, but I'd love to hear, how that works out 😉

I am aware of 3 libs that do functional right now: I see there is • the ReactiveX stuff: RxJava/RxKotlin particularly with RxKotlinFx on top • ReactFX (I use it in my main TornadoFX Project, because Im using RichTextFX which depends on it anyways) • then there is arrow Any thoughts on these?

Any idea what this is trying to tell me?

Type mismatch: inferred type is TreeItem but TreeItem! was expected

I have a simple function I was playing with

but get this error when using the function to populate a tree.

yes, I know this isn't going to cause the tree to sprout, but was experimenting

I can't fathom what the ! is after TreeItem

AHHH, ignore me. I went and looked at the TreeView and realised now that I was declaring the wrong a mismatching type

Great! Got the tree lazy loading a file tree based on click; thanks to a Javafx documentation.

I forgot about the condition when a directory is empty. Where I check for directory in expand, I have now added && value.listFiles() != null to cope with empty sets

ugh, column width and sizing seems to be very unintuitive 😞 fun times!

An old one

SmartResize too

thanks again carl, i think the bekwam will end up helping. My problem has been all i've found so far is SmartResize and its not working for my needs and often behaves very very strangely

hmm is there not a good resizing policy somewhere between constrained and smart? One that just takes into consideration pref/min/max/weighted widths and just honors them without trying to do so much?

i feel like smart is what i want, but when i resize the table or a column it does very whacky things

i agree. it seems like in the javafx api there's a Priority used in other components that could be used here to favor the last column. other frameworks like GTK have a FILL property that specifies what to do with a column's extra space

smartresize aside, CONSTRAINED versus UNCONSTRAINED isn't nearly good enough. UNCONSTRAINED gives you gaps to the right. CONSTRAINED makes a singular Y/N flag get equal spacing to a long description field.

so, i usually attach the favored bindings to the last column and rely on everyone else's pref widths

(in plain javafx)

on one side glad to see i'm not crazy, on the other size... damnit lol. Swing has its very very major issues, but this wasn't one of them 😞 Oh well, its ok for now, just very jumpy especially because its a treetable so obviously the first column's "data" changes width often and smart resize handles that very ... jumpy.

Hey gents, so I'm getting into tornadoFX in earnest for a little sample app. My biggest problem with tornadoFX was that it could tempt users to push business logic conditionals into view code, (where, of course, FXML, our current approach, prohibits this pretty effectively, though I've written a couple complex bindings)

but it seems that TornadoFX has a kind of MVC opinion regarding views vs controllers and its own form of injection to try and keep view code view related, im having a hard time understanding it. I'm looking around on the repo for tutorials, can somebody refer me to one that maybe walks through MV[C|P] with TornadoFX?

I've been putting Tasks in the ViewModel to keep the Model classes plainer and synchronous. That will evolve into co-routines as long as co-routines can provide the same cancellation and progress capabilities.