tornadofx 🚀 - TreeTableView Builder

Nice! I'll actually need TreeTableView next week, so this is perfect timing. I don't know the API of it well enough yet, but I'll start reading up on it in the meantime.

edvin on 10 Mar 2016

Yeah me too, although I explored it a little a few months ago. Depending on the complexity this may become a joint effort.

thomasnield on 10 Mar 2016

We should probably do both TreeView and TreeTableView. I need to think about how to tackle this though.

https://docs.oracle.com/javafx/2/ui_controls/tree-view.htm
https://docs.oracle.com/javase/8/javafx/user-interface-tutorial/tree-table-view.htm

thomasnield on 10 Mar 2016

Man trying to figure out a design for just TreeView is challenging enough. Mind is spinning but I know there is a way to do this...

thomasnield on 12 Mar 2016

Trying to visualize a TreeView in its usage.

Have not used TreeView and TreeTableView that much, but I know they are incredibly painful to build because of the imperative grouping process. Maybe we can set an ObservableList as the backing list and functionally group up and nest items somehow. For example, we can group up employees by department, and then show each indvidual. Speaking out loud here...

val employees: ObservableList<Employee> = ...

treeview<Employee>(employees) { 
    treeitem<String>(Employee::department) {
        treeitem<String>(Employee::name) {
        }
    }
}

thomasnield on 12 Mar 2016

Okay, I got something.

I had to break a few rules because TreeView is not streamlined at all from a coding perspective. I had to create extensions of TreeView and TreeItem to give the notion of a "backing list" rather than looping and adding raw values. Using functional approaches, we can add functionality that satisfies common use cases for TreeView.

It is still rough but here is a proof-of-concept. Once we leverage some property mapping with reflection, we could have a pretty strong API.

class MyView : View() {

    override val root = VBox()

    init {
        val persons = FXCollections.observableArrayList(
                Person("Mary Hanes","Marketing"),
                Person("Steve Folley","Customer Service"),
                Person("John Ramsy","IT Help Desk"),
                Person("Erlick Foyes","Customer Service"),
                Person("Erin James","Marketing"),
                Person("Jacob Mays","IT Help Desk"),
                Person("Larry Cable","Customer Service")
        )

        with(root) {
            treeview<Person,String>(persons) {
                rootitem("Departments") {
                    groupedtreeitem({ it.dept }) {
                        treeitem({it.name}) {}
                    }
                }
            }
        }
    }
}

treeview_tornado

Backing Builder functions

fun <T,R> BackedTreeView<T,R>.rootitem(value: R, op: (BackedTreeItem<T,R>.() -> Unit)): BackedTreeItem<T,R> {
    val treeItem = BackedTreeItem(data,value)
    treeItem.op()
    this.root = treeItem
    return treeItem
}

fun <T,R> BackedTreeItem<T,R>.groupedtreeitem(groupMapping: (T) -> R, op: (BackedTreeItem<T,R>.() -> Unit)) {
    data.asSequence().map { GroupByItem(it,groupMapping.invoke(it)) }
            .groupBy { it.mapping }
            .forEach {
                children.add(BackedTreeItem(it.value.map { it.item },it.key).apply { this.op() })
            }
}
fun <T,R> BackedTreeItem<T,R>.treeitem(mapping: (T) -> R, op: (BackedTreeItem<T,R>.() -> Unit)) {
    data.forEach { children.add(TreeItem(mapping.invoke(it))) }
}
class BackedTreeView<T,R>(val data: List<T>): TreeView<R>()
class BackedTreeItem<T,R>(val data: List<T>, item: R): TreeItem<R>(item)

private class GroupByItem<T,R>(val item: T, val mapping: R)

thomasnield on 12 Mar 2016

I put in a PR #50. Definitely not polished yet but I think it is a start.

thomasnield on 12 Mar 2016

Just confirmed we can nest as many layers as we want! I subgrouped by name length under department.

treeview<Person,String>(persons) {
    rootitem("Departments") {
        groupedtreeitem({ it.dept }) {
            groupedtreeitem({it.name.length.toString()}) {
                treeitem({it.name}) {}
            }
        }
    }
}

treeview_tornado_2

thomasnield on 12 Mar 2016

Did you get a chance to look at this yet? It pains me that I had to extend and modify the TreeView, but I can't help but contemplate the functionality gained.

thomasnield on 23 Mar 2016

I'm sorry, I read the comment "Definitely not polished yet but I think it is a start." and though you were going to do some more work on it, so I didn't even look. Sorry, I'll get right on it :)

edvin on 23 Mar 2016

Haha sorry, I should have communicated better. If you do like the direction of this I probably will need your help polishing it up since I know little about reflection.

thomasnield on 23 Mar 2016

My mistake :) I'll just finish up the HttpClient task and then I'll get right on this :)

edvin on 23 Mar 2016

No rush, I'd offer to help but I haven't had much practiced experience with HttpClient. I'm going off the grid until this weekend so I'll be back online then.

thomasnield on 24 Mar 2016

Enjoy your down time, I just finished HttpClient and started playing with this. I have some ideas :)

edvin on 24 Mar 2016

I like your general idea, but we should (and will) be able to avoid the subclassing. Also, I would like the backing list to be observable, so if you add or change data, the items should pop up in the correct subnode. Also, need to investigate if TreeTableView supports deeper nesting (I don't know if it does), and then think about how to support that as well. Just thinking out loud for now.

edvin on 24 Mar 2016

My week is clearing up. I agree with the backing ObservableList. The problem is I haven't found any concept of a "backing list" for TreeView. It's all manual population from what I've seen and that's why it is subclassed. This will take a lot of thought.

And I believe the TreeTableView does support deeper nesting. I haven't thought that one through yet though.

thomasnield on 24 Mar 2016

I have an idea about how to do this in a clean way, without subclassing and support for deeper nesting. I'm trying to figure out a way to support update of the hierarchy when the backing list changes. I'm at the cabin most of the week, but at least I have lots of time to think :) Can't wait to get to a computer and test my theories. Will keep you posted!

edvin on 24 Mar 2016

Please do! Look forward to hearing what you think up.

thomasnield on 24 Mar 2016

I just checked in the reflection based builders and column creators, aligned with the TableView stuff. Now it's on to testing some theories about hierarchy/treeitem creation :)

edvin on 24 Mar 2016

👍1

I think I'm going to have to learn about reflection. I've never had a need for it since I'm a very business end-focused developer. But I'm finding myself building API's a lot more and it might come in handy.

thomasnield on 24 Mar 2016

I've found a solution that works the same for both TreeView and TreeTableView. It supports deep nesting and doesn't require subclassing :) Basically, it's just three lines of code:

fun <T> populateTree(item: TreeItem<T>, itemFactory: (T) -> TreeItem<T>, childFactory: (TreeItem<T>) -> List<T>?) {
    childFactory.invoke(item)?.map { itemFactory.invoke(it) }?.apply {
        item.children.setAll(this)
        forEach { populateTree(it, itemFactory, childFactory) }
    }
}

I've added extension functions to both TreeView and TreeTableView that will call the above function with the root item as the first argument. This is the extension function for TreeTableView:

fun <T> TreeTableView<T>.populate(itemFactory: (T) -> TreeItem<T> = { TreeItem(it) }, childFactory: (TreeItem<T>) -> List<T>?) =
        populateTree(root, itemFactory, childFactory)

The simplest cases becomes somewhat more verbose, but the intricate cases will be very easy to reason about.

First some context: Looking at JavaFX example for TreeTableView, it is clear that a common use case for the TreeTableView is to group related objects under a common discriminator, like for example "Person in Department". A problem arises becase the TreeTableView can only hold a single value type (Person), and to create the Department TreeItem that should contain the Person items in that department they simply create a "Person that looks like a Department".

I've made sure we support this practice, even though it _should_ be solved in a cleaner way. Let's create this result from a flat list of Person objects:

val persons = listOf(
        Person("Mary Hanes","Marketing"),
        Person("Steve Folley","Customer Service"),
        Person("John Ramsy","IT Help Desk"),
        Person("Erlick Foyes","Customer Service"),
        Person("Erin James","Marketing"),
        Person("Jacob Mays","IT Help Desk"),
        Person("Larry Cable","Customer Service")
)

// Create Person objects for the departments with the department name as Person.name
val departments = persons.map { it.department }.distinct().map { Person(it, "") }

val view = TreeView<Person>().apply {
    // Create root item
    root = TreeItem(Person("Departments", ""))

    // Make sure the text in each TreeItem is the name of the Person
    cellFormat { text = it.name }

    // Generate items. Children of the root item will contain departments
    populate { parent ->
        if (parent == root) departments else persons.filter { it.department == parent.value.name }
    }
}

The populate function is called for each TreeItem. If the TreeItem returns any children, the populate function will again be called for each child. This way, you can keep recursing as deep as you want.

We first check if the parent sent in is the root node. This is how we know to just return the list of departments. For the next iteration the parent will be a TreeItem holding a department. Simply filter out all Person objects that has the same department. This is where it gets ugly when you repurpose the same domain object for both Department and Person. To solve this, one should create a common data class, or simply type the TreeView as TreeView and create a data class for Department as well:

data class Department(val name: String)

// Create Department objects for the departments by getting distinct values from Person.department
val departments = persons.map { it.department }.distinct().map { Department(it) }

// Type safe way of extracting the correct TreeItem text
cellFormat {
    text = when (it) {
        is String -> it
        is Department -> it.name
        is Person -> it.name
        else -> throw IllegalArgumentException("Invalid value type")
    }
}

// Generate items. Children of the root item will contain departments, children of departments are filtered
populate { parent ->
    val value = parent.value
    if (parent == root) departments
    else if (value is Department) persons.filter { it.department == value.name }
    else null
}

Ofcourse this is more code, but it is cleaner, and becomes easier to maintain as complexity grows.

This approach really shines when you have multiple columns in a TreeTableView. I'll add examples later, now I have to walk the dog. What do you think? :)

edvin on 25 Mar 2016

Btw, I think your example was kind of neat, but the TreeItem did not contain the actual Person object, so when you select a TreeItem you wouldn't know what Person object it represents (other than via the name, which would get ugly quick :) When the TreeItem contains the Person, the need for a cellFormatter arises, but that's a good thing, I think - and inline with how the other List based controls work.

edvin on 25 Mar 2016

Oh, by the way - I haven't create the actual treeview and treetableview builders yet, but they should be trivial if we go for this approach.

edvin on 25 Mar 2016

Example with just strings, kind of like your initial example:

val view = TreeView<String>().apply {
    root = TreeItem("Departments")
    populate { item ->             
        if (item == root) persons.map { it.department }.distinct()
        else persons.filter { it.department == item.value }.map { it.name }
    }
}

As you can see, it becomes a bit more verbose, but atleast every case can be expressed in the same way.

edvin on 25 Mar 2016

Oh wow. This looks pretty effective. Let me play with this today but I like where this is going. I suppose it can support as many items as needed?