Question

I’m trying to extend ButtonBarButton to include an additional label that shows the number of updates for the respective box in a viewstack (which is the tabbar’s dataProvider).

I can get the additional label (named indicatorLabel) to read an initial value from data, but I can’t get it to update automatically like the actual “label” attribute. My understanding was that you could bind to the data object, but that doesn’t appear to be the case.

The box that is used in the viewstack has an attribute called _indicator

[Bindable]
public var _indicator:String;

Which I know is updating properly because I can see it updating in the box (which also has a label bound to it). It appears to just not update the buttonbarbutton.

My buttonbarbutton class has the following (where init() is called in creationComplete

[SkinPart]
public var indicatorLabel:spark.components.Label;

private function init():void
{
 indicatorLabel = data._indicator;
 addEventListener("dataChange", onDataChangeHandler);
}

private function onDataChangeHandler(e:Event):void
{
 trace(e.target.label + ' ' + e.target._indicator);
}

I’m guessing my assumptions for either databinding or the data obj that gets passed to the button are incorrect. Any help is appreciated.

Answer 1

I have answered a question here just a few days ago that is closely related to this one. It’s a bit more abstract, but it should answer yours too. Have a look at Flex : Communicate between the skin and the data model?

As for your additional question about performance improvement: you just have to keep in mind that whenever you use binding, the compiler will generate some event listeners to listen for changes in the data. Of course that’s not an issue with a one-off component or even with a bunch of instances, but it may become one if you have a List with thousands of components that all use binding. First of all the garbage collector won’t clean these components up so easily when they’re no longer needed and secondly – depending on your implementation – thousands of events may be firing at once.

bottom line: you could consider the commitProperties() approach performance tuning, hence you shouldn’t consider it until you actually run into a performance issue.

on the other hand from an architectural point of view: that approach allows for a cleaner separation of the component and its skin. With the hostComponent / binding approach you could say the skin knows too much: it has to know about its host component and its properties. While the other one allows you to have a completely ‘dumb’ skin. So again I tend to use binding with one-off components and commitProperties() with highly reusable ones.

In the end it’s all a trade-off (because the ‘clean’ way is more complex and more work) and it’s up to you to make a weighed decision for each particular situation.