DropDownList Spec available

Hi Jason,

I like your spec very much. I’m pleased that it corresponds to my suggestions :-)

Regarding open issues:

I deeply believe that a helper class should be created, even if it will be fairly simple for now.

Probably different DropDownComponents will be created by different programmers so even if the dropDown opening and closing logic will be the same it will be implemented in a slightly different way. This may lead to increased number of bugs and API inconsistency.(BTW I think that many bugs in Halo are caused by such code duplication.)

By creating a helper class and applying it in DropDownList a standard DropDown components design may be established. This should simplify creation of subsequent DropDown components.

Regarding labelElement skin part I think it is redundant. DropDownList will use custom button skin so button’s labelElement can be customized.

In subject of measuring size I remember similar discussion about List component itself. I think that the final solution should be consistent for both DropDownList and List.

My proposal of non-committing selection:

- Replace internal usage of public selectedIndex getter in ListBase and List by usage of some protected properties (e.g. _selectedIndex).

- Override selectedIndex getter in DropDownList so that it will return appropriate value.

- Cancel “selectionChanged” events or override ListBase commitSelectedIndex function to prevent “selectionChanged” from being dispatched.

- Commit _selectedIndex and dispatch “selectionChanged” event when closing dropdown.

I think that such design will have relatively small impact on List and ListBase subclasses. Exposing protected _selectedIndex may be a good practice since it will separate internal listclasses hierarchy interface from enduser interface (public selectedIndex). That way selectedIndex getter could be safely modified in subclasses without affecting superclass behavior.

Cheers,

Iwo Banas