I'm very new to Flex, and am trying to work through some structural issues. I'm trying to plan out my model-view separation, and am exploring how the UI listens to changes in the model.
For the sake of discussion, I've attached two simplistic examples. Each example has class Human (my model) with three properties: name, date of birth (dob) and age. Name and dob have instance fields, but age doesn't since it simply does some arithmetic and returns a value. There are two custom components: one that views Human properties, and one that edits them. The question sort of focuses on the "age" property, with some ramifications. The first version <http://www.rahder.com/junk/bindable/Main%20Bindable.swf> has Human defined as bindable, then binds its name and dob to fields in the UI. That works since those properties are backed by variables. But there is no "age" variable, so it's impossible to bind on that property. (Right?) Run the first version -- the one that uses [Bindable] on the class. If you change the person's DOB or name you see the change propogate, as expected. But if you scroll way over and choose a DOB from a few years back, you'll notice that the age do not change. So what's the right way to write the view code so it updates itself as age changes? Hopefully this can be done in a way that's the same as it handles name and dob. I *could* have Human subclass EventDispatcher (or implement IEventDispatcher, or add an event dispatcher property) and have the Human age and dob setters fire a change event -- the views could add a listener in their person setter. But that seems inconsistent: it would mean the view needs to be aware that the age property isn't backed by a variable, which seems like pretty poor encapsulation. The second version <http://www.rahder.com/junk/not_bindable/Main.swf> doesn't bind Human, but instead, uses an event dispatcher for all changes to Human. The UI's code is a little more complex, but at least it consistently handles changes rather than having to handle some property changes one way and other changes another way. Is this a case where people go ahead and use a bindable business class, and accept the inconsistent handling of the property that's not associated with an instance field, with a "it's no biggie, that's life" attitude, or is it better in the long run to forget automatic binding and do it manually through one's own event dispatcher? Thanks for your advice! :-)
