I'm not finding the TreeCell (or any of the similar Cell subclasses) as easy to use as I would like. For trees, the domain objects being displayed may vary base on the level in the tree or other factors. If the cell factory is the primary method to vary the look of the "cell" then I have to know the domain object type in the cell factory callback in order to determine what nodes to create. However, I am not guaranteed to know the domain type the cell will apply to. If the tree is made of only the same types of objects, that's fine, but that is probably not general enough. Also, the documentation is not clear if the cell factory creates one cell for every displayed cell, or reuses the cell when new items must be displayed. During display, can we assume 1-to-1 association between a treecell and a treeitem?

There are really two issues here: The actual cell that the domain object is rendered into and the rendering of the domain object into nodes that display something unique to the domain object. Those separation of concerns are not well represented in the cell factory method unless additional machinery is added. The end result is that the cell created from the call factory may need to have substantial logic in it to support even common cases of diverse objects in the tree. This becomes especially cumbersome for editable cells where the editing property is in the cell class.

So while it is possible to program *anything* using the API with enough effort, there is not an easy way to handle common cases without programming a lot of machinery having to be added by the programmer. I think that javafx should error on the side of making it easy to do common things (like WPF) and less like Swing where I always seemed to be programming in alot of extra boilerplate.