But then again, I'm not sure if all these fixes and improvements are a
language problem, or if at least some items may be a runtime problem?
The new binding library for JavaFX 2.0 will be a simple, "non-compiled
bind" (interpreter tree over some EL) like early JavaFX's - with a big
warning "use sparingly or else your app performance will suck"? In that
case, how would a superior binding system from Visage integrate smoothly
with JavaFX 2.0's? Or, if JavaFX 2.0's binding will be a
high-performance system, why should the Visage project burn effort
there, duplicating Oracle's work? Will JavaFX 2.0's binding include some
feature equivalent to triggers?
A+
Osvaldo
I also third it. Great to hear your "voice" from out there in the
Wilderness so to speak.
I am not so surprised that you mentioned binding as you were
researching binding and "lens" in your public blogs over a year ago.
On 5 October 2010 23:37, Stephen Chin <st...@widgetfx.org> wrote:
> I second Jim's welcome. Great to hear form you, Chris!
>
> I hope you don't mind, but I added you as an honorary project committer.
> :-)
>
> On lazy binding, I always wondered how the replace triggers worked... I
> guess that answers my question (they break the model). I added an
> enhancement request for this:
> http://code.google.com/p/visage/issues/detail?id=11
>
> Cheers,
> --Steve
>
> On 10/5/2010 3:19 PM, James Weaver wrote:
>
> Good to hear from you, Chris. The Visage project welcomes your help!
> Thanks,
> Jim Weaver
--
Peter Pilgrim,
**Java Champion**,
JavaFX / Java EE Software Development / Design / Architect
Certified SCRUM MASTER, Scala Enthusiast
:: http://audio.fm/profile/peter_pilgrim ::
:: http://jroller.com/peter_pilgrim ::
:: https://java-champions.dev.java.net/ ::
:: http://twitter.com/peter_pilgrim ::
:: A Oracle Certified Enterprise Architect for Java EE 5 platform ::
On 10/5/2010 4:52 PM, Osvaldo Pinali Doederlein wrote:
> Repeating my opinion from my first post, another vote for prioritize
> the completion of the current language, before considering wild new
> features :) I've been tracking the binding functionality with great
> interest, but all currently planned binding improvements/optimizations
> were interrupted by the JavaFX 2.0 roadmap (at least if Oracle would
> complete JFXC Presidio...). The problem with triggers is hard, may
> need some substantial design effort before any code is touched; so,
> maybe it's a better idea to start with the low-hanging fruit, like the
> pending items of JFXC-3557.
Good suggestion. There is quite a nice list of items there to work on.
> But then again, I'm not sure if all these fixes and improvements are a
> language problem, or if at least some items may be a runtime problem?
> The new binding library for JavaFX 2.0 will be a simple, "non-compiled
> bind" (interpreter tree over some EL) like early JavaFX's - with a big
> warning "use sparingly or else your app performance will suck"? In
> that case, how would a superior binding system from Visage integrate
> smoothly with JavaFX 2.0's? Or, if JavaFX 2.0's binding will be a
> high-performance system, why should the Visage project burn effort
> there, duplicating Oracle's work?
My assumption is that the JavaFX bind mechanism will be limited in
either its expressiveness, performance, or both. I would like to
preserve all the expressiveness of the Visage bind system while also
tuning performance. Without having access to the new bind APIs, I think
the best path is to keep the Visage language binding, and create a
transparent coupling to observable properties as a special case that we
will optimize for.
> Will JavaFX 2.0's binding include some feature equivalent to triggers?
My understanding is that the equivalent to triggers will be observable
properties.
Cheers,
In JavaFX 1.3 they changed the implementation to work directly off
instance variables whenever possible, and only add in the bind code when
it is actually used. This gives you a reduction of bytecode size for
the more common case where a variable is never bound. It also reduces
memory usage by reducing the number of property references and improves
performance for calls that go directly to the variables.
While there is always room for improvement, I am a big fan of the
current bind implementation in Visage and would like to keep it for any
Visage to Visage bind references. Once we have a concrete bind library
for Java (Rich said early 2010), we can see how difficult it will be to
wire the two binding systems together so you can bind from Visage to Java.
Cheers,
--Steve
--
--Steve
blog: http://steveonjava.com/