So if your agent is a vertx thing (embedded or verticle), then I think you have your side channel for comms with the UI

Yea but I might have two seperate procoesses

Ah, I see your point

If memory serves, Vertx has a way to set up an event bus bridge over arbitrary socket connections.

... could be wrong about that, it has been a while since I read the docs

I don't want vertx to infect my network 😛

Hah! It sounded to me like your application and agents were Vertx based.

mahbad

I run some verticles but I don't use it for anything other than a eventloop

and eventbus

Well good luck with it. I gotta go -- was just reminded that not making dinner was a poor choice in the marital bliss department.

@iLobanov Can you post your domain object?

@edvin Here is listing

// data
@Serializable
data class Project(
    val id: Int? = null,
    val companyId: Int,
    val sender: Sender?
) {
    companion object {}
}

@Serializable
data class Sender (
    val id: Int? = null, // Null when proposition
    val emailFrom: String,
    val reportRate: Long,
    val sampleRate: Long,
    val launchTime: Number,
    val status: String
) {
    companion object {}
}

// view model
class ProjectModel : ItemViewModel<Project>() {
    val id = bind(Project::id)
    val companyId = bind(Project::companyId)
    val sender = bind(Project::sender)
}

// view 

class ProjectCardFragment: ListCellFragment<Project>() {
    private val project = ProjectModel().bindTo(this)

    override val root = stackpane {
        vbox {
            println("ProjectCardFragment >>>>>>>>>>>>>>>")
            println(project.companyId)
            println(project.sender)
            textInt(project.id)
            text(project.sender.value.emailFrom)
...
}

@iLobanov Since you're not using observable properties in your domain objects, that's about the best you can do. You can however creating bindings for sender.emailFrom directly in the

ProjectModel

and bind towards that, but it won't update when you change the sender, since that isn't observable. I highly recommend to not fight the JavaFX properties, and just accept that they are needed in a JavaFX application. Without them you'll have to jump through burning hoops all the time. With real properties you can do multi level observable bindings that update automatically on commit. If you feel you need to keep your data classes, at least use DTO's 🙂

@edvin thx! And there is no the way to bind another ItemViewModel child class as property?)

@iLobanov Sure, that would work, but you will still have to update the item references by overriding

onCommit

I'm looking into the use of varargs. I saw that goto required params. (https://github.com/edvin/tornadofx/blob/master/src/main/java/tornadofx/Component.kt#L577) Is that correct?

@bkenn Let me know if you get any feedback on the SO issue, OK? 🙂

@edvin will do. I have started to migrate one of my projects to it and it surpisingly works well so far. All tests are passing.

@tieskedh I see no reason why params should be required. Probably an oversight on my part.

I'll change it

@bkenn Fantastic! I would be surprised if there was no way to write a plugin to handle domain objects with properties smoother so we don't need to litter annotations everywhere, hopefully somebody will set us on the right track

@tieskedh Thank you!

I'll do a release tomorrow.

@edvin PR is Ready

@tieskedh Thanks! I love it 🙂 Merged 🙂

thx, I'm learning the frmework now and the lack of varargs irritated me a bit. Up to the next one. 🙂

@tieskedh I have a feeling we'll see more PR's now that you're actually learning/using the framework :))

we'll see

do you know jitpack? cause I think it's a better alternatve for getting the latest snapshot, as the snapshot updates after every commit (and it's free too)