Ted Patrick > { Events & Community } > Adobe Systems

9 Responses to “ 360Flex SJ 2008 - Diving in the Data Binding Waters with Michael Labriola ”

1. #  glenn August 27, 2008 12:05 PM

   thanks again Ted, this one was a killa! top stuff.
   
   I've a question though (and seeing as Michael didnt give any contact details I thought I'd just post it here) if you dont mind.
   
   Hi Michael,
   
   Just watched your presentation at 360flex on data binding and have to say it was very illuminating.
   
   just a quick question. (well i have 1000 but just one for now ;-)
   
   when you spoke about models and making the whole class bindable.
   Am i correct in understanding that I'd get a performance benefit from making the properties of the class bindable one at a time rather than that whole class.
   
   is it’s correct that the complier will create a unique .....proportyChangeEvent name when I bind each property (so making it unnecessary, in this case anyway, to use a custom event name) and thus help with the problem you mentioned of having potentially 1000s of properties asking, as you put it, ‘is this for me..’?
   
   Is it the act of making classes rather than individual properties bindable that can cause a lot of the bottle-neck?
   
   please forgive me if I’m off track here, I think I’ll need a few runs through your presentation for a few of the more esoteric questions to show their total ramifications.
   
   Anyway, thanks once again for an extremely interesting and I have to say quite exciting presentation (the very fact I’ve just written that sentence surely says a lot about me and does worry me a little, maybe I should take up a sport! lol, )
   
   Thanks Michael,
   
   glenn
   tinylion development UK  

2. #  zachary August 27, 2008 2:02 PM

   Since I couldn't make it, I was hoping someone would bring up NOT binding in Flex. The best way to not misuse or bloat with unnecessary binding is to allow developers to decide what should be bind or not. By default all this="{that}" must be bindable, but what if that only needs to be set once or we will worry about updating? You can of course cast to a ObjectProxy, etc.. But MXML needs a non-binding format for variables, anyone else with me? (Or PLEASE tell me you found a way to set MXML attributes w/ variables without generating all that Watcher/Binder code generation!)  

3. #  Michael Labriola August 27, 2008 5:00 PM

   Glenn,
   
   First, you can find me (and the slides for this preso @ http://blogs.digitalprimates.net/codeSlinger/index.cfm/2008/8/20/360-Flex-San-Jose-Recap
   
   However, to answer your question:
   
   IMO, your absolute best bet is to define a custom event and dispatch it yourself for every property.
   
   Anytime you make something bindable, by default, it is going to dispatch a ‘propertyChange’ event with the name of the property that changed as a parameter. Every property in the class that is bindable will do this. Again by default, when you are using data binding every listener is listening for a ‘propertyChange’ event from that class.
   
   So, for example if I have a class with 5 properties and 5 labels bound to them. I then change 1 of the properties. 5 functions are called along with associated pushes onto the stack. 4 of them exit because the event was not for them, popping the stack, 1 of them proceeds. The issue, for me, is that there were an additional 4 method calls/stack pushes. Now, if I choose to update all 5 properties…. I actually call 25 methods, with 20 of them exiting after comparing the property name.
   
   If you define your own event names for each property, then you have a 1 to 1 correlation of properties being changed and listeners being called. (this of course uses my assumption of a single label bound to a single property, but all of these numbers get worse as you have more objects listening for changes) Now, there is some additional overhead at the player level for using multiple event names, however, it is my assertion that the function calls and associated pushes and pops are the bigger hit.
   
   I am not advocating that everyone stop using the default bindable generated code. Nor am I advocating that everyone must define every property manually. I am just saying that you need to understand this is a potential bottleneck and, when it is time to optimize an app, understand this is a great place to do it.
   
   Mike  

4. #  barry.b August 27, 2008 7:07 PM

   Michael, thanks for a quality presso. great stuff
   
   Ted, thanks for making this presso happen, both as far as the conference and also capturing it for those that couldn't make it. Appreciated.  

5. #  Michael Labriola August 28, 2008 5:20 AM

   re: zachary
   
   Not sure exactly what you mean. I can do this:
   
   protected var myName:String = 'mike';
   
   <mx:Label id="test" text="{myName}"/>
   
   That label will display the word ‘mike’. I will receive a warning that says Data binding will not be able to detect assignments to “myName”. That is because it didn’t generated any getters, setters or watchers for this variable nor this Label.
   
   The two things I don’t understand is that you said “set MXML attributes w/variables without generating all that Watcher/Binder code”. The above example works so long as you don’t want to change the value of the variable myName at runtime and have the Label update. This is because changing the value of a variable at runtime and having the view update is the definition of databinding. You are always free to simply update the text property in ActionScript, of course, but I don’t think that is what you want.
   
   Also, you mention ObjectProxy. If you are worried about the overhead of the binding generation, ObjectProxy is going to use all of that plus have additional overhead, so I am not sure that is a good route.
   
   I guess the best advice I could offer would be to half use the data binding generation. If you said:
   
   [Bindable(event=’fooChanged’)]
   protected var myName:String = 'mike';
   
   Flex will generate the watcher for this variable, but not the getter/setter. So, then you could change the value at will and only dispatch the ‘fooChanged’ event when you wanted the view to update.
   
   Mike  

6. #  zachary August 28, 2008 11:05 AM

   Thanks Mike,
   
   I guess what I am trying to say (although not doing a very good job at it!) is that yes, I want to define the property value in AS and include it in my MXML layout, like you said:
   
   protected var myName:String = 'mike';
   
   <mx:Label id="test" text="{myName}"/>
   
   I just would like a way to do this and NOT bind, NOT have to do a half way hack and NOT get warnings.
   
   Say, you'd bind like this:
   
   [Bindable]
   protected var myName:String = 'mike';
   
   <mx:Label id="test" text="{myName}"/>
   
   and NOT like this:
   
   protected var myName:String = 'mike';
   
   <mx:Label id="test" text="!{myName}"/> (or any other such syntax...)
   
   My post was really either to say: 1) Hey we need to find a way to allow Developers to have non-binding variables in MXML and not get warnings, or 2) If someone knows the right way to do this, let me know!
   
   Thanks again for your response and your presentation. The Binding "magic" was the first thing I really investigated getting into Flex and it's important!  

7. #  zachary August 28, 2008 11:14 AM

   As an example, let me cite the way you can use ResourceManager in a non-binding way:
   
   <mx:Label id="test" text="{@Resource(bundle='myResources', key='GREETING') }"/>
   
   You can of course bind Resources, but this syntax was created to not generate the Binding overhea when localizing apps.
   
   It's covered here:
   http://labs.adobe.com/wiki/index.php/Flex_3:Feature_Introductions:_Runtime_Localization#Why_do_I_need_to_write_a_binding_expression_instead_of_.40Resource.28.29.3F
   
   This is how I understand it, although I could be way off!  

8. #  diamondTearz September 7, 2008 1:32 PM

   . Michael tried to explain all of this to me a couple of years ago when he was consulting on the NRAEF project I was working on. At that point my brain was full a few minutes into the explanation about why I shouldn't use my squiggle tags all over the place. HEaring it now with a better understanding of the framework this is an excellent session that answers many questions I've had in the past about a binding not doing its job.  

9. #  verveguy September 20, 2008 7:22 AM

   Thanks for the deep discussion on Binding internals and realities. Great tips on optimization
   
   There's one cranny of this that I'm currently stuck in which I have not yet found an exploration of: the interaction of binding expressions in MXML and AS3 namespaces.
   
   Assume I have a namespace defined called "my_internal", used to partition off a framework I'm developing from users of my framework. (ala mx_internal)
   
   If I have this in an MXML script block of a component I'm developing *in my framework*:
   
   ..
   
   
   use namespace my_internal;
   
   my_internal var model:SomeType;
   
   ...
   
   I cannot seem to get a subsequent binding expression in the same MXML file such as
   
   mx:Label text="{my_internal::model.description}"
   
   to work.
   
   If I leave off the namespace qualifier, the compiler warns me that I will have runtime binding problems.
   
   When I fully qualifying the reference, the compiler is happy and the warning goes away, but at runtime, changes to the description property of the model instance are *not* propagated to the Label.
   
   It seems that the literal string "my_internal::model" is being passed down into the binding machinery and then, somewhere, the fact that it's a namespace qualified reference is not being handled correctly.
   
   I've been poking around in the generated code, not yet with any insight.
   
   And yes, this could be a problem with the runtime scoping of the namespace: my head hurts at that point and I'm not sure how to debug.
   
   Suggestions, please!
   
   Brett Adam