On 12/5/17, 11:23 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>Responses inline: > >> On Dec 6, 2017, at 7:07 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >>> 3 There is no even being dispatched for removeElement. If I’m attaching >>> event listeners when they are added, I should be removing those >>>listeners >>> when they are removed. >> >> I'd like to find a way to make removal PAYG. Lots of apps never need to >> remove anything. > >Agreed, but I can’t think of a way to do this. One way is to have assignable removeElement logic. Another is to have a bead that overwrites UIBase.prototype.removeElement. What won't work on SWF but will on JS. > >>> 4. Assuming #1 makes sense, it feels like there should be two separate >>> events: One for single elements, and a second when all of them are >>>added. >>> It might make sense to keep childrenAdded for en mass (with no >>>payload), >>> and elementAdded when a single element is added and dispatch a >>>valueEvent. >> >> Yeah, or if the payload is null, assume it is an "en mass" event. > >That could also work. I’m not sure which way is easier to grok from a >user perspective. Not sure about usability, but it is probably less code to call addEventListener once and check for null if you need to than call addEventListener twice. > >>> >>> Some background on the bead I’m working on: >>> I’m trying to create a ToggleButtonBar. The idea is to allow a >>>container >>> to accept ISelectable components which have a selected property and a >>> bead will ensure that only a single ISelectable is selected at any one >>> time. It’ll also keep track of the selected index. The only way I was >>> able to figure out how to keep this generic and track the selected >>>states >>> of the components was to attach change listeners to each of them. >> >> What is the difference between ToggleButtonBar and regular ButtonBar? >> There are places where things that look and act like buttons aren't >> actually buttons. ButtonBarItemRenderers and some day, >> CheckBoxItemRenderers are often better off not actually being based on >> Buttons and CheckBoxes when they have to interact in a group setting. > >I’m trying to keep this really simple. ButtonBar extends List which >requires dataProviders, ItemRendererers, etc. My approach is to allow >adding any component which has a selected property to any container. The >bead will handle correcting the selection of the unselected elements. I >want to enable the following mxml: > > <js:HContainer> > <js:beads> > <js:SingleSelectionContainerBead/> > </js:beads> > <js:ToggleTextButton text="Fee"/> > <js:ToggleTextButton text="Fi"/> > <js:ToggleTextButton text="Fo"/> > <js:ToggleTextButton text="Fum"/> > </js:HContainer> > >Those ToggleTextButtons could be RadioButtons, Checkboxes, etc. We should make sure it works, but I would expect issues around focus, keyboard selection and accessibility. And also, how it upgrades to being able to load the text labels from resources or a server and add or remove buttons. This sort of thing makes me wonder if there is some other item renderer contract we should be offering instead. IIRC, right now, the contract dictates that the renderer must have a "data" property. Maybe if there was a contract where we could dictate the property to set you could just drop in an existing component as a renderer. There was a similar thing in Flex. It was a bit heavy, but maybe folks don't care. Way back I pointed out that all components should be able to be expressed as a UIBase or ContainerBase/GroupBase with a collection of beads. It would be interesting to see what the other List beads expect. Right now a factory watches a dataProvider and generates an item renderer for each dataProvider item. Hopefully the other beads don't care how the item renderers appeared and can be repurposed to your pattern. IOW, either you specify a factory and an item renderer and a dataProvider or you supply a set of children, but everything else should work. Of course I could be wrong, but I'm packing it in for tonight, so I'll find out in my morning. -Alex
