Max, Inline comments...
> 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. I seem to understand you better now. These features I'm working on are for AS ATM. But I'm not against adding some mxml+data binding functionality in addition too. > 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. The selectedItems is the same the selectedIndexes for the most part, it doesn't actually keep the selecteItems, it translates them into a new Vector<int> to store the selectedIndexes. So that means you would like a getter/setter to access an array of indexes for enabled/disabled buttons. It's doable, but will have to be done separately from this current features. It's a bit more of an effort to have an additional vector.<int>. It will need to update with any change to the dataProvider (add/remove/reset/refresh). We could move someone functionality up to Listbase, but I'm not sure what benefit that would have overall since only the ButtonBar / TabBar seem to change properties on a per item bases. Although let me know if you find an example for it. ButtonBar ComboBox DropDownList List SpinnerList TabBar > 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. I was planning on trying to address this with having it watch the dataProvider for changes to additional properties (enabled, tooltip, visible). This would probably the place to squeeze in a disabledItems styled getter/setter property. -Mark On Tue, Apr 30, 2013 at 4:23 PM, RIAstar <max...@riastar.net> wrote: > 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 >
