Then when you edit the grid it causes collection change events to fire – you don’t even have a listener on the grid, which is kinda cool.

However I don’t think this is a really common approach and as such Adobe doesn’t give it any attention. it seems to have some glitches, so just be warned.

Jason :
Another thing to mention is that the change event seems to get thrown multiple times under different circumstances. If your data class is marked as [Bindable] (for example the Widget class) then the PropertyChangeEvent will contain oldValue and newValue. If not, they will both be null. Also the event gets fired twice, the 2nd time oldValue and newValue are null.
One glitch I’ve noticed is that if you sort by a column, then edit the values in that column, you’ll get inconsistent firing of the change event.

This was a huge help to me. I definitely favor monitoring the data model over the view. Does anyone know why the collection change event fires twice? Are people just ignoring propertyChangeEvents with null oldValue and newValue?

Adding a listener to the collection has some odd behavior and I still question whether it’s the best way. But the reason I don’t like itemEndEdit is because you have to write a lot of code in the view – particularly in your event handler, you have to write some kind of switch statement to deal with all the columns unless they are all TextInput.

If you have all TextInput fields then its pretty easy but if you have a more typical grid with checkboxes, date fields, dropdowns, maybe some custom item renderers, then you have to know exactly what input control to expect and then cast the correct one in order to get the value. I don’t really like having to handle each column in the grid differently.

If you listen to the collection changes, on the other hand, the oldValue and newValue get passed to your already cast correctly and you don’t have to even know what type of input control was used to trigger the edit. I like dealing with things generically when I can so I don’t have to write a bunch of logic in the view layer.

Basically I think it’s a question of whether you want a smart view & dumb model, or a smart model & a dumb view. I’m taking the approach of a smart model because I’m lazy and I don’t like writing the same event handler code 10 times for the same data just because it appears in several places in the app.

I’d definitely be interested to hear what results people have gotten either way.

I would recommend using itemEndEdit. The newly entered value is not difficult to get.

To get the new value use: event.currentTarget.itemEditorInstance

For example:
// This assumes that you’re using the default
// itemEditor which is a TextInput.
newValue:String = TextInput(event.currentTarget.itemEditorInstance).text

One glitch I’ve noticed is that if you sort by a column, then edit the values in that column, you’ll get inconsistent firing of the change event.