• Email
  • Like
  • Save
  • Private Content
  • Embed
 

Diving in the Flex Data Binding Waters

by

  • 22,416 views

In depth overview of the Flex data binding code generation. Provides info on accomplish data binding through actionscript as well as limitations of the process.

In depth overview of the Flex data binding code generation. Provides info on accomplish data binding through actionscript as well as limitations of the process.

Accessibility

Categories

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

Cancel

14 Embeds 1,055

http://blogs.digitalprimates.net 437
http://www.digitalprimates.net 249
http://training.obecto.com 209
http://www.slideshare.net 131
http://www.adobe4all.com 10
http://shaydu.wordpress.com 5
http://www.norris2u4.com 3
http://durga-technology4you.blogspot.com 3
http://webcache.googleusercontent.com 2
http://translate.googleusercontent.com 2
http://static.slidesharecdn.com 1
http://localhost:8888 1
http://192.168.1.17 1
http://gantto.posterous.com 1

More...

Statistics

Likes
18
Downloads
495
Comments
3
Embed Views
1,055
Views on SlideShare
21,361
Total Views
22,416

13 of 3 previous next Post a comment

  • Roustalski Roustalski richard,

    When you mark a class or a specific property/getter/setter as [Bindable], it basically marks that item for code generation via the pre-compiler before the compiler does it's thing with the code. The dispatchEvent(...) is automatically generated.

    When you say [Bindable(event='blah')] or [Bindable(event='propertyChanged')], the pre-compiler says, wow, this guy knows what he is doing, and expects you to dispatch the event.

    This has nothing to do with the performance implications (e.g. 5000 bindable variables in a model locator all dispatching the same event) where your 'custom' name just happens to be the auto-generated event name.

    Hope that helps
    3 years ago
    Are you sure you want to
  • richardchaven richardchaven So if one uses '[Bindable]' on the accessor/mutator, the compiler will always dispatch a propertyChanged event (i.e. without checking to see if the value has actually changed), but if one specifies the event in the Bindable metatag (even if the specified event is 'propertyChanged'), then the mutator is responsible for dispatching the event?

    The mutator seems to call its matching accessor automatically; does this have anything to do with a binding optimization ?

    Cheers
    3 years ago
    Are you sure you want to
  • manfred_karrer manfred_karrer great presentation!
    An important part is maybe coming a bit too short in the slides: Performance.
    Binding with MXML is cool but much slower then using BindingUtils (~50%)...
    4 years ago
    Are you sure you want to
Post Comment
Edit your comment

Diving in the Flex Data Binding Waters Diving in the Flex Data Binding Waters Presentation Transcript