kotlinlang #tornadofx

@edvin this is working for me menuitem(name = "Close", onAction = { evt -> close() }) but this syntax which I have been using for buttons doesn't menuitem("Close") { setOnAction { close() } }

carlw

01/10/2017, 11:56 AM

Is that second form legal?

edvin

01/10/2017, 11:57 AM

menuitem doesn't require

setOnAction

, everything inside the first block is the action. If you add

setOnAction

, the event would fire on menu activation number two.

edvin

01/10/2017, 11:57 AM

I would like to change the interface to require

setOnAction

so it's in line with buttons, this is a recurring source of bugs.

edvin

01/10/2017, 11:57 AM

It would break existing apps though, so we'd have to do it for 2.0

carlw

01/10/2017, 12:30 PM

@edvin do you use Fragments a lot in your CRM? It seems like the long declarative statements of a complex View can get unwieldy after a while. Specifically, for traditional menuing with lots of KeyCombinations and actions

edvin

01/10/2017, 12:38 PM

@carlw Right now I use lots of Fragments, but I'm converting them to Views using Scope. Why would there be a difference between Fragment and View for statements? Do you have an example?

carlw

01/10/2017, 12:38 PM

@User uploaded a file: Composed View

Composed_View.java

carlw

01/10/2017, 12:39 PM

menu has a menubar root, status bar has an hbox with progress and a label, content has a hierarchy of the main app nodes

carlw

01/10/2017, 12:40 PM

All this is in my app for resigning jar files...I'm converting it to Kotlin alongside the existing Java code

carlw

01/10/2017, 12:40 PM

https://github.com/bekwam/resignator-repos-1

carlw

01/10/2017, 12:40 PM

the exact lines I posted earlier will be committed in a few minutes

edvin

01/10/2017, 12:54 PM

This nested binding stuff is really hard. Changing the syntax a bit and making some adjustments.

edvin

01/10/2017, 1:01 PM

I think I've got it.

edvin

01/10/2017, 1:02 PM

To create a nested observable/writable property you can now write:

val fatherName = child.parentProperty().nested(Person::nameProperty)

edvin

01/10/2017, 1:02 PM

You can nest as deep as you like.

edvin

01/10/2017, 1:26 PM

I added a parameter to ViewModel

bind

called

forceObjectProperty

to avoid creating specialized properties like

IntegerProperty

if you need an

ObjectProperty<Int>

instead. This is important because

SimpleIntegerProperty

for example cannot hold null values and will convert null to 0.

edvin

01/10/2017, 1:43 PM

These nested properties are incredibly sweet. Consider an

Orderline

which has a

Product

property. In a TableView however, you want to display the

id

of the product on that orderline. You can define this as follows in `Orderline`:

edvin

01/10/2017, 1:43 PM

val productId = productProperty.nested(Product::id)

edvin

01/10/2017, 1:43 PM

Now in your TableView you just do:

edvin

01/10/2017, 1:43 PM

column("Product", Orderline::productId)

edvin

01/10/2017, 1:43 PM

Pretty clean IMO 🙂

carlw

01/10/2017, 1:58 PM

@edvin Did you consider using the same syntax as the Bindings.select() steps or does that force a lot of ugly type handling?

edvin

01/10/2017, 2:32 PM

@carlw I thought about it, but a varargs list of steps is impossible to do type safe.

edvin

01/10/2017, 2:32 PM

@carlw Maybe

nested

is not the right word?

edvin

01/10/2017, 2:33 PM

select

perhaps?

carlw

01/10/2017, 2:33 PM

i think you said it works for any depth...maybe path or steps would be better in keeping with the javafx documentation? nested properties was used in Struts so i'm not totally against it

carlw

01/10/2017, 2:34 PM

maybe there's a way to integrate Bindings.select()...something like column("Product", select(....)) in a way where the select() can be used outside of TableView

carlw

01/10/2017, 2:34 PM

I like the GridPane / row builder BTW

edvin

01/10/2017, 2:35 PM

It can be already actually.