It could operate internally as a message bus, I think. In fact I
think it might have to to avoid problems with recursion.
Regarding refactoring, as the JavaFX language is dead your standard
Java IDEs should be able to cope with it unless JavaFX goes the way of
the stringly typed, which seems unlikely.
2011/5/31 Cédric Beust ♔ <ced...@beust.com>:
> 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 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.
>
--
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.
