On 12/6/17, 12:40 AM, "Harbs" <[email protected]> wrote:
>>>
>>> Agreed, but I can’t think of a way to do this.
>>
>> One way is to have assignable removeElement logic.
>
>Meaning an assignable Function property, or something else?
Yes:
public function removeElement(e:IUIBase):void
{
actualRemoveElement(e);
}
public var actualRemoveElement:Function = removeElementBody;
public function removeElementBody(e:IUIBase):void
{
// current body of removeElement
}
Pretty ugly.
>> Another is to have a bead that overwrites
>>UIBase.prototype.removeElement.
>> What won't work on SWF but will on JS.
>
>Interesting. Probably worth looking into.
Another option is to remove the removeElement APIs from UIBase and turn it
into utility functions.
org.apache.flex.utils.removeElement = function{parent, childElement)
}
>>>
>>> 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.
>
>I’m not sure I understand why you think these are issues. The components
>should be pretty much self contained. I guess I’ll see.
IMO, there are user expectations on how focus and selection will work. In
Windows and probably OSX, if you tab into a buttonBar, the entire
ButtonBar gets focus and the selected button is highlighted in some way
and you use arrow keys to change the selected button. Your pattern will
have different behavior and the screen reader is also likely to read
something different.
>
>> 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.
>
>I’m not sure if I’m following you here. My understanding was that the
>only way to specify the children of a list is to provide a dataProvider.
>It seems like you are saying that it should technically be possible to
>add the children directly. For kicks I just tried the following to see
>and it did not work at all (i.e. nothing was added to the button bar):
><js:ButtonBar>
> <js:ToggleTextButton text="Fee"/>
> <js:ToggleTextButton text="Fi"/>
> <js:ToggleTextButton text="Fo"/>
> <js:ToggleTextButton text="Fum"/>
></js:ButtonBar>
>
>I’m guessing that you are suggesting a factory could be added with
>conditional logic.
Actually, I'm suggesting no factory at all. The goal is to create
re-usable beads that don't have much conditional logic. You can certainly
make things re-usable with conditional logic, but that adds just-in-case
code.
A List should be the encapsulation of the following:
<UIBase>
<beads>
<SingleSelectionModelBead />
<ListViewBead />
<SingleSelectionControllerBead />
<VerticalLayout />
<DataProviderItemRendererFactoryForArray />
<ItemRendererClassFactory />
<StringItemRenderer />
</beads>
</UIBase>
There are also a few more beads to manage scrolling. We need to think
through what assumptions each of these beads might have and see if any of
those assumptions need adjusting. For example, I would hope that the
Selection related beads have no assumption that there are these Factory
classes on the strand. In theory, you should have been able to create
your ButtonBar like this:
<ContainerBase>
<beads>
<SingleSelectionModelBead />
<ListViewBead />
<SingleSelectionControllerBead />
<HorizontalLayout />
</beads>
<js:ToggleTextButton text="Fee"/>
<js:ToggleTextButton text="Fi"/>
<js:ToggleTextButton text="Fo"/>
<js:ToggleTextButton text="Fum"/>
</ContainerBase>
I've replaced the 3 factory related beads with the four children they
would have otherwise generated. There probably shouldn't have been a need
for SingleSelectionContainerBead unless it is an aggregation of
SingleSelectionModelBead and SingleSelectionControllerBead. If it isn't
an aggregation, what would be the cost of generalizing these beads so they
can be re-used? And if it isn't worth it, what is it about what you
needed that is different just because we don't have a factory of item
renderers?
Of course, I could be wrong...
-Alex
>
