Ah right, I remember that. While I agree it's an improvement over listeners, I still think that this kind of binding 1) couples your view and your model too strongly and 2) creates n*m connections, which is a lot of overhead.
For example, if you want to bind two text fields to two different variables (say a status bar and a window title), you now have four connections to maintain and walk through every time something changes. And obviously, your tool had better support refactoring (especially renaming) or deciding to rename varName to something else might lead to events becoming suddenly lost. I still think that the local software bus approach is much more powerful and solves these two problems: 1) No more coupling between view and model, the only hub is the message bus, and 2) it creates n+m connections instead of n*m. The downside is that both publishers and subscribers need to have a handle on that bus, but we know how to solve this pretty effectively today, both from a code organization and architectural standpoint. I discussed this in longer details in this blog post<http://beust.com/weblog/2010/07/26/local-message-bus/>some time ago. My code has become dramatically simpler whenever I replaced listeners with a local bus. -- Cédric On Tue, May 31, 2011 at 11:00 AM, Ricky Clarkson <ricky.clark...@gmail.com>wrote: > Sure. Instead of saying.. listen to this text field and whenever it > changes update this variable, and listen to this variable and whenever > it changes update the text field, you bind the two together and then > forget about it. > > TextField { > text: bind varName > } > > At least that's in the original dead language. I don't know how it's > done in the API version of JavaFX, but rather than wait I did > something similar myself, though without the magic[1]: > > https://github.com/rickyclarkson/fj-swing > > I should note that I am not using fj-swing, though I am using a couple > of private implementations of the same concept. > > [1] The magic is a cool way of implementing this stuff so that each > evaluation configures a dependency tree. Consider some psuedocode. > > bind x = 5 > bind y = 10 > bind z = x >= 5 ? y * 2 : 3 > bind textfield.text = String.valueOf(z) > > That says that x is bound to 5, y is bound to 10, and z is bound to y > * 2 if x is >= 5, 3 otherwise. Now consider: > > rebind x = 4 > > Logically that should result in the text field changing, which means > you need to be able to know that z depends on x. Well, you can, > because you can record what gets evaluated while binding z. > > Note that in this reevaluation of z, y is removed from the dependency > tree, as unless x changes again the value of y is irrelevant. > > -- > Skype: ricky_clarkson > UK phone (forwards to Skype): 0161 408 5260 > > > > 2011/5/31 Cédric Beust ♔ <ced...@beust.com>: > > On Tue, May 31, 2011 at 10:35 AM, Ricky Clarkson < > ricky.clark...@gmail.com> > > wrote: > >> > >> I particularly like the event dispatching, it looks like it wouldn't > >> lead to the same mess raw Swing often does. > > > > Can you be more specific on what you like about it? > > -- > > Cédric > > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to javaposse@googlegroups.com. > > To unsubscribe from this group, send email to > > javaposse+unsubscr...@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/javaposse?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
