You can make read-only properties bindable. In your case your age property is a read-only property since it only has a getter. The normal bindable stuff doesn't work on that because bindable properties require both a getter and a setter to work. But if you define only a getter you can still use the [Bindable] metadata tag, but you have to dispatch a custom event that tells everything that the value has updated.
Check out these links: http://www.rubenswieringa.com/blog/binding-read-only-accessors-in-flex http://dynamicflash.com/2006/12/databinding-to-read-only-properties-in-flex-2/ (I googled for 'flex binding read only') Doug On 2/29/08, JustusLogan <[EMAIL PROTECTED]> wrote: > > 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! :-) > >
