On 1/15/2012 4:01 PM, David Arno wrote:
I'll
comment on List.
The class does many things: it's a container; it displays the contents of a
data provider; it supports scrolling; it supports item renderers; it
supports dragging& dropping; it supports single selections; it supports
multiple selections; it supports item editing etc. Classes should be single
purpose. Therefore the List class should be a compositional class that is
composed of IDataProviderSupport, IScrollSupport, IDragAndDropSupport etc
and the functionality that is currently in List should be in classes that
implement those interfaces. That way, the currently overly-large,
over-complex, unfocused class could be broken up into a large number of
properly focused, smaller classes.
That is kind of what the Spark Architecture did. And the end result
is that development is more complicated to extending and modifying
things [from the perspective of a component developer] is a complete
nightmare. It's much worse than the "too many private variables"
problem that existed in the Halo architecture.
For the sake of simplicity in development; wouldn't the MX approach of
having a single class to represent the List be better?
In my view Spark favored flexibility over simplicity.
--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust
