A quick rundown for the those of you new to Flex/Flexicious:
The Flex SDK has 3 DataGrids provided by Adobe:
Flexicious has extensions built on top of each of the above. Usually referred to as :
Spark (ExtendedSparkDataGrid – newly launched)
And finally, we have a grid that we built from the ground up – Flexicious Ultimate (FlexDataGrid) which is the most feature rich product in the list above.
A couple weeks ago, we launched the new Flexicious Spark Extension. This caused a number of questions, concerns and feedback. (Thanks and keep it coming). A number of our customers immediately brought up - “What does this mean for Ultimate”?
So, let’s answer that first, because it is an important question. Ultimate has and will continue to be the Superset of everything in terms of functionality for the foreseeable future. It is the most powerful DataGrid component available for Flex today, and is by any measure, our most successful product. Our largest Enterprise customers use it almost exclusively, simply because it can do almost everything that the others can, and a lot more. It is where our innovation has and will continue to be born for the foreseeable future. DataGrids are often the workhorse components of most RIA applications. We understand the crucial role we play in this ecosystem and take your concerns very seriously.
Although we believe that the Spark architecture has advantages over the Halo architecture, from a purely functional perspective, the Spark DataGrid is nowhere close to Halo ADG or Ultimate. Seasoned Flex developers know that the Spark DataGrid is *still* quite primitive in terms of feature set, but it does what it does very well, i.e. display of flat data. However, the moment you need hierarchical data, or column groups, or locked columns and rows, and a number of other features, well, you better stick with Ultimate or Halo (and consequently, our AdvancedDataGrid Extension).
It’s always good to have options. A number of folks are using the Spark data grid exclusively in their apps, where there isn’t a requirement for complex functionality, and that is fine. For such applications, either our Spark or Classic product will be a good choice.
Finally, all our products share a lot of the codebase. The API’s are very consistent, property names and method signatures are usually consistent except when they have to support additional functionality, and moving from one product to another is usually quite trivial.