I posted the code that would fix the error to you earlier tonight, here it is again, including a fixed `JiraDataModel`:

-.rb

Note that there is no need to pass in an instance of

JiraTicket

- one is automatically assigned from the

ListView

for each row.

Huh. I thought I did that. It has been a long day

Based on the feedback I got, I've refocused and restructured the flow of my slides. Feel free to peep 🙂

Same content, different focus.

I peep'd

I don't think I have any feedback, I probaly should've read the speaker notes, rather than just look at the slides heh

they're nice slides

@edvin thanks! I haven't quite internalized the model/binding structure. I kinda just apply patterns that I think work, heh

I'll get it one day

Now at least I'm verifying that it will in fact build on my CI server.

What are the best practices to organize a project? I.e. separate views, controllers, events, fragments

@beepdog Sweet! Let me know if you get stuck on anything 🙂

@ValV I try to keep business logic out of the view, so the view basically reacts to events and fire off calls to controllers. If the view is large, I'll separate it into logical smaller views. Reusable pieces like that are Fragments most often. I try to use events to avoid tight coupling/direct references between uicomponents.

I did not really thought of putting some pieces of main view into fragments yet, I supposed that fragments were primarily intended for all kinds of message and dialog windows

@ValV I find that it makes it much easier to keep things organized as the UI code of a single view grows past several hundred lines

Yep, it's kinda an art to separate code into blocks and devise hierarchy of a project

Absolutely 🙂 If I know in advanced that the View will be huge, I like to add the fragments into a BorderPane or other parent container that makes sense for the UI as a kind of planning step before I start writing the logic

So those fragments better to put in the same directory (

view

) with MainView, I think, but what's about dialog windows? I wish my project to be as much intuitively (and logically) be comprehensible for other developers as possible

I'm putting all messages (object/class FXEvent) into a separate class

Events

and then

import my.project.Events.*

There's also an option in IDEA such as creating separate objects. Is this approach similar to `Controller`s?

I.e. singletons

@ValV With a View broken up into several (reusable if needed) Fragments or even sub-Views, some of the other TornadoFX patterns will become apparent. Also, the standing advice of not to couple UI controls is essential because you may not have a reference to a particular UI control around to update it.

Fragments

I haven't fully grokked yet

Difference in scope...find a View, get the one and only View object in the app. Find a Fragment, get a fresh Fragment object

@carlw scope or Scope? haha

same thing...Singleton scope versus Prototype (Spring's term) scope

there are other scopes outside of TornadoFX that are commonly used like Request/Application/Session scoped in web programming or Conversation scoped, Seam long-running operations

the scope defines a lifecycle