Degrafa vs. FXG (and Spark) [Bindable]

Hey Ely,

The main example is in creating controllers that are attached to the Skins with Degrafa objects in them (like OpenFlux does it).  The Controllers use BindingUtils.bindProperty to listen for when a Fill.gradientType changes, or when the Polygon.data changes, and then it updates another thing.  That's the most generic part, but there's lots of that.  Like creating a shadow based on the gradient angle and the position of the object.

Another example is in restricting a button's label width/height to the (rectangle width - the corner radii sizes).  And those corner radii change with the state.  I don't do that in the skin, I do that in a ButtonLabelController, which I can add to any skin and reuse the code. But it requires binding.

Or tilting the panel and changing the drop shadow size when the verticalScrollPosition, or any of the scrolling related variables change.

Or changing the color as a function of the gradient fill angle in a skin to easily simulate simple lighting.

For the horizontalScrollPosition/verticalScrollPosition, you can create an animated scroll bar very easily, and more fully featured than the built in stuff in Spark, with a controller that binds to those properties on a Group or Layout.

Granted you can do all this without binding, but binding just makes it soooo much easier.

Plus there shouldn't be much overhead if we're not dispatching events if it doesn't have an event listener for it, and they aren't generically "propertyChange" events.  That's what Degrafa does in some places.

By not having the option to bind to it, I am restricted to a particular coding style, and I miss out on some helpful coding practices, like composition over inheritance.  Currently in Spark, I can't extract out "controller" logic from the skin (that does something like the above) into some other object, unless I know when they're updated.  Some other options I currently have using the Spark Architecture:

1) Write some enterFrameHandler that updated properties based on other property changes.  Would require some dictionary keeping track of old property values on a target.

2) Extend the skin class and add [Bindable] tags, or extend the Group and add them.

3) Extend the Skin or component, and do a bunch of logic in the invalidation methods, which isn't necessary, especially during animations.  Plus I can't reuse that logic in another component without copy-pasting, and that's just too much work.  Like if I wanted to have an editable TextInput and an editable TextInput, I'd have to extend both with the same code in each.  I could solve that with a Controller no problem.

I think the controller architecture makes things so much easier to do, and classes so much easier to customize, without code duplication and inheritance.  But that's another point.

Binding doesn't need to be "active" if nothing's bound to it, and we can have an option to prevent binding on those properties with a variable like degrafa has: "enableEvents" or "suppressEventProcessing". That shouldn't impact performance.

Lance