On 17/01/2012 10:02, Roland Zwaga wrote:
> From what I heard the spark datagrid was a big improvement compared to the
mx one,
perhaps this can be used to further optimize the performance.
There is a considerable amount of work just to get a full set of necessary features into the Spark
DataGrid - and that's without its current performance issues. Whether these performance issues
affect you as developer really depends on the domain you're working in - but it's a problem for
large or dynamic data sources which may exclude it from many Enterprise applications.
Also, as David Arno references in another thread (Subject:Overly Large Classes), the DataGrid is
composed of a small number of large classes and overriding particular features of the datagrid can
be extremely difficult as the classes aren't decomposed into functional components i.e. you often
need to override methods of the large DataGrid classes (DataGrid, Grid, GridLayout etc) while
needing to call the super... implementation methods of (SkinnableContainerBase, Group, LayoutBase etc).
So is it worth finishing the Spark DataGrid and other large composite components when they need such
an overhaul? IMHO I think this would be time better spent on creating a new DataGrid from scratch
based on principles of composition, and separation of concerns (I know we can do both but ... !).
The DataGrid component I wrote recently is based on functional composition and uses a pseudo
Spring-like context for injecting Factories and Configuration values into deeply nested component
parts. These components parts can be either display objects (renderers, indicators, scroll bars,
headers etc), models (Row models, column models, data models, selection models etc) or Controller
objects(row and column drag controllers, layout controller, editor controller, scrolling strategies
etc). Currently, in KineticGrid, there are 59 different factories that can be overridden to
customise the grid and the grid functionality is still incomplete! These all interface-driven and
have defaults, so are transparent to a developer unless specific functionality needs to be overidden.
Using a component-specific context provides a single point for access of factory providers,
configuration providers and component models that does not depend on the display list and Style
Manager for configuration - additionally most of the auto-binding between configuration and factory
instances can be performed automatically by the context and factory objects themselves. This
approach can provide performance advantages as separation of concerns allows plug-and-play of
classes optimised for different domains. Decomposition also allows subsets of functionality to be
developed and shared either alongside, or within, the Flex Framework.
A solid datagrid is an absolute must for the Flex SDK, but I'm sure a lot
of people will
be interested in lending a hand in that component. It ought to be the
startcomponent
of the entire framework I think, hehe.
A DataGrid component based on composition should automatically provide full List, Tree, Color
Picker, Date Chooser functionality so it's certainly a contender for starting component!
Despite compositional overhead, KineticGrid performs around 4-10 times quicker than Spark grid in a
dynamic scenario - if there's interest I can see about finding time to document the architecture.
Alex
--
Alex Bradley
-------------
http://www.kinesissoftware.com
