Always open to discussions.
Inline comments... *> Thanks for looking into various approaches. What are the scenarios that > make having an API that requires searching the dataprovider, better than an > array that parallels the dataprovider, better than requiring a field on the > dataprovider like we do for mx:Menu [1] (see "enabled" property). * Well what I envisioned for these convenience methods was to be able to change certain properties of the buttons directly and adhoc. Currently in the example we have a method addressing single buttons and an array fed one that grab all matching the array. The reason I didn't have an array parallel to the dataProvider was it felt like your Option 3 was a better option for it. Meaning rather than hosting a separate array of enables states, just use the dataProvider and have more fields in it. I had already planned on making a feature to use the dataProvider contain certain properties (enabled, toolTip, visible, buttongroupings, etc). Watching for changes to the dataProvider to update the child objects. But I try to only show small amounts of additions at once. Was hoping to make it faster to digest and process them than without having large delays. But I do plan on showing the new features for discussion purposes. *> I honestly don't have an opinion, I just wanted to point out a third > possibility that has been done before. Also, instead of providing more than > one way, it might be best to settle one one. One disadvantage to providing > multiple was of doing something is that you then have to implement and order > of precedence (If I use both APIs, which one overrides the other).* Well the methods that are in the example now, don't conflict, but adding that third option would modify take a little consideration. *> 1) in the MX days, we "disallowed" duplicate entries in the dataprovider. > In Spark, we do not, so there is a theoretical chance that a label can be in > there twice (practically, I can't really think of why anybody would do that) > so you have to decide whether to cover such a case or not.* That does affect the current Single based method, but the array fed one will grab duplicates too. *> 2) In a buttonbar of just icons (audio/video playback controls or something > like that) can you assume there are distinct labels to search for?* No. it wouldn't match much without labels. I could do what I did for the other features, just pass a field it should use for the search match. This will allow a custom field in the dataProvider that would give same functionality but not pass labels to the buttons themselves. Thanks for your feedback Alex. It has good constructive thoughts. -Mark On Sun, Apr 28, 2013 at 1:18 AM, Alex Harui <aha...@adobe.com> wrote: > Hi Mark, > > Thanks for looking into various approaches. What are the scenarios that > make having an API that requires searching the dataprovider, better than an > array that parallels the dataprovider, better than requiring a field on the > dataprovider like we do for mx:Menu [1] (see "enabled" property). > > I honestly don't have an opinion, I just wanted to point out a third > possibility that has been done before. Also, instead of providing more > than > one way, it might be best to settle one one. One disadvantage to providing > multiple was of doing something is that you then have to implement and > order > of precedence (If I use both APIs, which one overrides the other). > > Couple of other things to consider (and again, I don't have an opinion here > either): > > 1) in the MX days, we "disallowed" duplicate entries in the dataprovider. > In Spark, we do not, so there is a theoretical chance that a label can be > in > there twice (practically, I can't really think of why anybody would do > that) > so you have to decide whether to cover such a case or not. > > 2) In a buttonbar of just icons (audio/video playback controls or something > like that) can you assume there are distinct labels to search for? > > > [1] > > http://help.adobe.com/en_US/FlashPlatform//reference/actionscript/3/mx/contr > ols/Menu.html > > > >
