Up through Flex 2.x, the primary goal of the list classes was to be as fast as possible. Many assumptions were taken in order to squeeze better performance out of these classes. Those assumptions have the negative effect of reducing ways you can extend the components.
We’ve seen that the Flash Player 9 and the new AS3 VM is pretty fast and are looking to spend a few cycles in Moxie and future versions on generality/subclassing/extending and new features at the expense of performance. Our rationale is that many of you want to do really fancy stuff with the list classes that is really hard to do right now, and that execution and rendering speeds are sufficient today and will continue to get better and thus should absorb and negate additional computation required by being more general.
Post-Moxie, we are considering a major overhaul to the list classes and framework in general. For Moxie, we are adding some new features and new APIs. We’ve made it easy to add effects to the renderers in the List and TileList classes (not sure DataGrid effects will make the first Moxie release). Another team is building an AdvancedDataGrid complete with summary rows, column span, grouping and more. In order to do implement these new features we’ve added some new APIs to allow renderers to be created based on the data object, divided renderers into sub-containers to separate scrollable renderers from fixed ones (header, locked columns and rows do not always scroll), and exposed more of the internals of the scrolling logic.
The Moxie versions are far from general. There’ll still be private and mx_internal variables to trip over. In subsequent releases we hope to greatly improve generality and create more common subclassing patterns throughout the framework. But the main point I want to bring out right now about the Moxie versions is about backward compatibility.
We have a commitment to retain backward compatibility with the previous version of Flex (2.x). However, we do not commit to bug-for-bug behavior compatibility. If we fix a bug and you were relying on that buggy behavior, your application’s behavior may change. We promise not to remove APIs that existed in Flex 2.x, but the fuzzy area is in how those APIs should behave. In the strictest sense, those APIs should remain the same: that some input produces the same output. However, right now, because the set of changes to the list classes was so significant, we are thinking of allowing the output to change. It would take significant additional time and effort to get 100% compatibility in the API behavior and further degrade performance and increase code size. I’m telling you this now so we can gauge the impact this will have on those of you that have subclasses the List classes. If there are certain APIs that you all use, we can consider trying to make those APIs behave more like 2.x. The percentage of folks that have done significant subclassing is small and most of what you’ve done might be in the AdvancedDataGrid and/or the effects features anyway so you might be better of using the new component or features.
Following is a sample of the changes we’ve made so far. Please give us feedback as to what the impact on you will be. Note also, that if we do a major refactoring post-Moxie, that may present a whole new learning curve in order to customize the List classes.
lockedRowCount – bug fix – no longer includes the header. If you’ve set lockedRowCount in an app, you will probably need to decrease it by one.
rowCount – bug fix – no longer includes the header.
listItems – API change – no longer includes the header at row 0. No longer includes locked columns or locked rows.
listContent – API change – no longer parents renderers that represent the header, locked columns or locked rows.
makeRowsAndColumns() – API change – only draws items for listContent, so no longer draws items for all items if there are locked columns or locked rows
visibleColumns – API change – only contains the columns that are not locked
draw***() – now draws backgrounds, highlights and selections in listContent as well as the lockedColumns sub-container if it exists
itemRenderer.parent – API change – no longer guaranteed to be listContent. Can be another sub-container.
In addition, there used to be an assumption that only the set of visible item renderers were created. In Moxie, we may create more off-screen renderers in order to handle effects and column and row span. listContent used to be positioned at 0,0 in the List class and now can be moved around in order to handle span and certain effects.
In summary, your subclass is almost guaranteed to compile, but may not run correctly, and if you’ve set lockedRowCount, you may need to adjust it by one.
If we get lots of responses, I am unlikely to reply to each one, but we’ll be listening to what you have to say.
- May 2012
- October 2011
- April 2011
- March 2011
- February 2011
- October 2010
- March 2010
- February 2010
- January 2010
- December 2009
- August 2009
- May 2009
- December 2008
- November 2008
- September 2008
- August 2008
- June 2008
- March 2008
- February 2008
- January 2008
- October 2007
- August 2007
- July 2007
- June 2007
- April 2007
- March 2007