As you guessed, this type of data binding isn't currently supported. Having worked with data binding systems like this in the past, I find that it can lead to confusing and inefficient code, as too many things are happening in the background when they don't need to be.
The load()/store() model used by Pivot maps more closely to how data binding is used in many practical applications (especially those that are REST-based): after making a server query to retrieve your data, you populate your form using the load() method. When you want to save it back to the server, you store() it into your model and upload it back to the server. More dynamic updates (like those you describe) can easily be achieved via event listeners. This way, your application has complete control over what is updated and when. G On Mar 28, 2010, at 11:48 PM, Michael Allman wrote: > Hello, > > I have two related questions on data binding in Pivot. After a lot of > searching and digging, I'm pretty sure the answer is "no" to both of these > questions. I just want to confirm so we can move on to step 2---how to fix > the situation. > > So suppose we have some kind of User object with a r/w "name" property and a > Label declared in some WTKX file. My questions are: > > 1. Is there a simple way to bind the Label's "text" property to the User > object's "name" property in such a way that as the app user types into the > text field the value of the latter property is set to the value of the former > (label.text => user.name)? > > 2. Is there a simple way to bind the User object's "name" property to the > Label's "text" property in such a way that when the value of the former > property is changed, the value of the Label's "text" property is set to the > new value of the User object's "name" property? > > This is a very important capability for me, and it's one that I think has a > reasonably simple solution. But I'd like to get a Pivot expert's thoughts > first. Maybe I'm missing something that's already there, or some other > feature that's more powerful than this. > > Cheers, > > Michael
