like you could save multiple "NewItem" records

...then go back in and rename

So you'd do all this outside the framework of the EditModel that's part of the TFX table view

this wasn't tornadofx (plain javafx) but it might give you guys some ideas

the end result for me was a singular back-end call that could be replayed

or rolled back

I'll have to see how important this turns out to be for my users. Thanks for the ideas.

@kastork If you really need it, I could try to whip up some code.

No don't spend time

if it turns out I actually need it I'll bring it up again

OK. I could refactor the editModel.items to be an observableList instead of an observablemap. Then this would be a oneliner, albeit a little expensive.

Hi 👋 Can someone guide me to where I can understand more how binding and viewmodels work ? I read the gitbook guide but its more of a getting started Some of the problems I have faced : - How to bind part of the UI to the presence or absence of an object in a nullable field of my model ? (Example: if a checkbox is checked, my object's field is populated with a type != from boolean) - More generally, how to map between properties of different types ? - How does viewModel.commit work ? When should I call it an how does autoCommit work ? As you have probably guessed by now, I have no knowledge of JavaFX 🙂

@tarek In the case of boolean, you can supply a default value to the binding expression. Mapping between different types in the model object and the viewmodel can be done by overriding the creation of the property in the bind method, but is generally easier to avoid. viewmodel.commit will push all changes in the viewmodel to the model property they are bound to, provided that there is an item in the viewmodel. If there is no item in the viewmodel, it's effectively a noop. autocommit automatically writes changes to the viewmodel facade properties directly to the underlying item.

There is something with the tableview builders that have been bugging me for a long time. Look at this issue: https://github.com/edvin/tornadofx/issues/599

The compiler can't distinguish between the two column builders where the difference is that the property reference is either pointing to a kotlin speak property, or an observablevalue of the given type in the second case.

The ability to reference non-observable properties sure is nice, so it would be a shame having to rename the column function for these properties, but I'm not sure how to do it.

I got an idea.. Maybe I could create a subclass of TableColumn and change the type parameter in the op parameter...

So basically adding something like

class TableCol<S, T>(text: String) : TableColumn<S, T>(text)

and using that class in the signature of the column property that supports non-observables, seeing as that is the ugly duckling here anyway 🙂

Hmm.. no, that's not going to work, since the issue is distinguishing between the second type parameter of the KProperty..

There is no clash between mutable kotlin properties and observablevalues, so maybe we should rename the one that supports readonly columns, and call it

readonlyColum

? That would solve it. I bet this is biting a lot of people, especially when starting out.

The issue was introduced when we created support for readonly properties.

As a test, I renamed the overloaded

column

builder that supports readonly properties to

readonlyColumn

. That resolves the issue, but I hope to find a smoother solution. This was the last function added though, so if something has to be renamed, it should be that one IMO.

Has anyone tried to write JSON/REST with Kotlin or TornadoFX? I have a couple base questions:

I am mostly a front-end dev, with enough experience in the backend to write, but I've never really designed any infrastructure larger than slackbot connected to an existing database

Could I write a Node.js application with REST and deploy it on Heroku for testing, and have that connected to my native TornadoFX application?

@amanda.hinchman-dominguez Absolutely, TornadoFX has very strong support for JSON/REST, with a built in http client and a nice way to convert to/from JSON

The reason why I ask is because I was reading through the documentation for JSON/REST and I noticed an existing call for apachehttpclient, but because my company does not use apache, I didn't want to do that

@edvin oh, built in? Very nice, so I don't actually need to use an exisiting rest client for existing servers?

Not that this matters, but from what I've read, it what was clear was strong support for JSON/REST, but not clear on how versatile using that http client is. That would be important for people that seriously want to use tornadofx for large solutions

@edvin If the httpclient is already built in, I don't need to make my own http client. Maybe I could test it locally with postman?