Sorry for the delay.
I guess my main argument in favour of the array attribute was the
convenience of being able to enable/disable buttons purely through MXML
+ data binding.
But I have other arguments ;) I'm not sure why having another
"dataProvider" would be inconvenient. The `selectedItems` property for
instance is an example of an existing attribute that serves a similar
purpose (it selects/deselects items in a List). It would make sense to
me as a developer that similar functionality would be exposed through a
similar, consistent API; in this case e.g. a `disabledItems` attribute
which would enable/disable items in the List.
I say List (not ButtonBar) because I think it would make sense to expose
this feature at that level, rather than for ButtonBar only, so that all
subclasses of List can reap the benefits.
Alex' suggestion of an mx:Menu-like API makes sense too. That's actually
how I work around the issue at the moment. But it has the inconvenience
of being less discoverable: you /have /to read the docs to now about it.
I tend to discover a component's API by letting my IDE suggest
attributes or methods (e.g. I start typing "dis" to see if there's
something I can use to disable items and the IDE will tell me there's an
attribute called `disabledItems` that does the job).
Also this aproach makes more sense for components that will usually have
a more static model (Menus, ButtonBars and the like), but less so for
those that usually have a more dynamic model (List, DropDownList,
ComboBox, etc.): you'd have to add presentational properties to your
value objects or wrap them all in presentation model objects. So if you
want to expose this feature for all List-based components, I'm not
entirely sure that's the best solution. Besides, not all Menus have a
static model and not all Lists have a dynamic model.
Those were my thougts ;)
Max
