Binding list

[danjohansson]

Hi
I know this is not done but perhaps I can ask anyway.
Was experimenting with table-view but got stuck on how to bind a list to the items property, is it supported yet?

Would expect to be able to have table-data in an atom and call something like (observable-list table-data :my-data) on it. Or perhaps use freactive cursors.

I got this far:

(def table-data (list {:name "Dan2" :age "high"} {:name "DanJ" :age "higher"}))
(fx/table-view {:columns [(fx/table-column {:text "Name"
                                               :cell-value-factory (fn [i] (fx/observable-property (.getValue i) :name))
                                               }) 
                             (fx/table-column {:text "Age"
                                               :cell-value-factory (fn [i] (fx/observable-property (.getValue i) :age))
                                               }) 
                             ]

                   :items table-data})

[aaronc]

Yes, what you're suggesting is ideal, but is not really implemented yet. I do have some domain-specific ways to do this in my project code, but because I don't have anything generalized yet, I didn't put it in fx-clj. I think in some of my code I'm using ObservableLists containing Clojure data strutures directly.

Ideally we would have some sort of idiom in Clojure for something that is an "observable collection". I have drafted some ideas in freactive, but nothing I'm totally happy with so for that reason I haven't published it yet. Basically though, I think we should have some wrapper structure that reports added/removed/updated changes to data that is stored in an atom/cursor/ref etc. - this wrapper structure would maybe have assoc!, dissoc!, update! operations to efficiently track changes and if the data in the atom/cursor/etc. changed in some other way (i.e. via normal swap!) it would just do a diff to figure out and report the changes.

Any thoughts?

[danjohansson]

Sounds good!

[clojj]

here I'm just using the regular (mutable) Java/FX (observable-)lists
https://github.com/clojj/fx-commander/blob/master/src/fx_commander/core.clj#L10

...guess the update of this list in this case has to be done by (fx/run<! ...)
https://github.com/clojj/fx-commander/blob/master/src/fx_commander/core.clj#L49
?

[aaronc]

You could also use run! is you want your go loop to continue. run<! will
suspend your go loop until the JavaFX thread returns if that's what you
want.

On Mon, Dec 22, 2014 at 5:33 PM, clojj notifications@github.com wrote:

here I'm just using the regular (mutable) Java/FX Lists

https://github.com/clojj/fx-commander/blob/master/src/fx_commander/core.clj#L10

...guess the update of this list in this case has to be done by (fx/run<!
...)

https://github.com/clojj/fx-commander/blob/master/src/fx_commander/core.clj#L48
?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[aaronc]

Not sure where you get the impression that fx-clj is introducing other
threads - it's up to the user to do that. You can use :on-action (fn []
...) to bind a click handler.

On Tuesday, December 23, 2014, clojj notifications@github.com wrote:

nice.
thinking about the JavaFX thread... is there any way in fx-clj to handle
the click-event 'inline' in the JavaFX thread ? (like any old callback
method)

if not, fx-clj is actually introducing non-JavaFX threads handling every
UI-event.. making use of the run*! variants obligatory, right ?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[aaronc]

Sorry, the handler should take one arg: (fn [e]...)

On Tuesday, December 23, 2014, Aaron Craelius aaroncraelius@gmail.com
wrote:

Not sure where you get the impression that fx-clj is introducing other
threads - it's up to the user to do that. You can use :on-action (fn []
...) to bind a click handler.

On Tuesday, December 23, 2014, clojj <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

nice.
thinking about the JavaFX thread... is there any way in fx-clj to handle
the click-event 'inline' in the JavaFX thread ? (like any old callback
method)

if not, fx-clj is actually introducing non-JavaFX threads handling every
UI-event.. making use of the run*! variants obligatory, right ?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[clojj]

yes, sorry.. didn't see that.
I'm really interested in how far I can take it with fx-clj.