@hastebrot In

CountryView

you don't need to create properties for the table, input fields and buttons.

@hastebrot The binding towards the selected country can be done directly inside the tableview

Ahh I thought the binding was already against the property

You don't need onDock at all, since you can bind directly against the viewmodel.

The button can also be disabled in a much more sexy way.

@User uploaded a file: Proposed changes

(I forgot to change the column definitions, updated them now to use properties)

Yeah I wanted the boilerplate to gradually improve this and better understand the problems.

OK 🙂

Of course later I want to get rid of the boilerplate code. Which means your suggestions are very welcome. However I think I'll probably keep the split between form using builders and distinct method with event handlers. I'll see what fits best at the end

Great. If you conclude that event handlers works best I'd be very curious of why. Let me know 🙂

You don't need to supply the type parameter to

toModel()

since, you have defined

countries

as

ObservableList<Country>

. Because of this,

resources.jsonArray("european-countries.json").toModel()

should do 🙂

I guess, I could also define `column()`s for

tableview

in a separate function, i.e. to separate the plain form hierarchy and the event handlers. Having separate functions also means I need the boilerplate code for the UI elements (e.g.

var capitalField: TextField by singleAssign()

).

There is nothing wrong with putting the event handling together with the node builders. It could be even my general workflow to first put everything into

override val root: Parent = stackpane {...}

for experimentation and later refactor the code and seperate them into node hierarchy and event handlers.

@hastebrot Why would you need boilerplate code for the ui elements? You bind them directly towards the view model properties, so I don't see any reason to create variables for them?

If you want to create the TableView in a separate function, you can create a function called

Pane.createTable() = tableview { ...

and call it from where you want the tableview to enter the node hierarchy with just

createTable()

.

@mikehearn I'm not even man enough to configure Avian on my Windows machine to test it out. It's a jungle of different ways to install make/gcc and the other prerequisites, but I haven't had any luck with even the basic configuration. Do you know if they provide some instructions for people not used to compile gnu stuff from scratch?

the readme suggests using cygwin to build - i haven't tried on windows but the instructions look little different to what it'd take for linux/bsd.

if the weather is bad at the weekend maybe i can fiddle with it and see if i can get a windows build

@mikehearn I'd be forever grateful 🙂 I already have Git Bash installed, I think it's based on mysysgit, which should include make, but I'm fine with installing cygwin along side it if needed.

I have lots of experience with SWT, so I'd hit the ground running if I can just get the build environment set up.

Why would you need boilerplate code for the ui elements?

@edvin separation of concerns 😕 some customers want this. I noticed the TornadoFX views contain a lot of logic. I'm open to explore different approaches to organize the code.

So, for Tornado I want to write "acceptance tests" that test the examples. I guess, I should use the examples from the code repository and wiki (because some of the examples in the guide are intentionally boiler-platey). This probably includes diffing of rendered images of the stages.

I also want to write unit tests for builders.

My first idea:

class FooViewTest {
    @Rule val robot = FxLifecycle.robot()
    @Rule val viewLifecycle = FxLifecycle.before().view(FooView::class)
    @Rule val stageLifecycle = FxLifecycle.after().clearAllStages()

    @Test fun click_on_button() {
        robot.clickOn(".countup")
        expect(".counter").has.text("1")
    }
}

Looks a bit boilerplatey (not much TornadoFX-like). I really want to prefer `@Rule`s over test class inheritance. Note that `@Rule`s for JUnit4 don't work with their equivalents in JUnit5 (at least that's what I understood when I asked someone from the JUnit5 team in Vienna).

I don't think the boiler plate there matters, it's pretty sweet, but we could use a more builder like syntax for it perhaps. It might look more TornadoFX-like.

@edvin I'm going to work on the dirty state model for the TableView in the guide this afternoon.

@edvin it just occurred to me, maybe this belongs in Chapter 11 with the other

ViewModel

stuff?

`AssertionError`s in JUnit 5 output a looong stacktrace 😕 IntelliJ helps and hides folds "8 internal calls", but does not filter the other 20

org.junit.platform.engine.*

calls.

@User uploaded a file: Untitled