The Future of List Classes (Tree, TileList, DataGrid, etc)

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.

22 Responses to The Future of List Classes (Tree, TileList, DataGrid, etc)

  1. Thanks a ton Alex. it was really a nice info.

  2. Campbell says:

    I find it hard to justify most the private (internal I understand) class vars. If a var is stored in the class instance, then if we extend it we will more than likely need to be changed. But I appreciate the work going into V3 componenents

  3. Jason Holmes says:

    That rowCount bug will affect me, but that’s definitely for the better.
    I never understood why it included the header and always thought it was rather odd.
    I’m all for the changes.

  4. Ray Greenwell says:

    Alex: I say fix things! If you retain API compatibility but fix bugs, then I don’t think anyone can complain. If someone depended on the buggy behavior then they can continue to use the old version of flex until they fix their code to work the right way.
    It’s not like fixing a bug in the player, where app developers depending on the buggy behavior have no say as to whether users are using a new or old version of the player. Those bugs are harder to fix and may require deprecating a method and adding a replacement.
    But changing flex is OK, IMO, because the app developer can just choose not to use the new version until they’ve ironed out the kinks.

  5. nwebb says:

    Thanks for the great info Alex. Yes, I’d say I’m also in favour of the changes and excited to hear about the possible post-Moxie overhaul! I would love to see some classes made easier to extend, and it doesn’t seem like you have to be doing anything particularly fancy with Lists to run in to the need for a workaround – trying to maintain the state of CheckBoxes in a scrolling List appears to require some kind of workaround unless you’re happy to mix details about the current state of the view in with your data.
    It’ll be a while before info about the big overhaul goes public.
    Checkboxes scroll just fine for us as long as the state is driven by the data. If you are using checkboxes for selection state, I would tie that to isItemSelected().

  6. Ray Greenwell says:

    Oh, one other thing:
    It’d be great if a flex 4 (?) app could be loaded up inside a security domain inside another app.
    Flex currently chokes on this, trying to climb the display hierarchy to find the SystemManager. I made a patch for flex 2 that fixed this and worked, and I’ll be doing the same for flex 3. Would you guys be interested in seeing my patch? It may not work for every situation, but I tested it with a few small flex apps.
    This is not our top priority, but we will get to it someday. Our solution may require a player update.

  7. Bjorn says:

    Hey Alex,
    Not that i’ve looked into it too much but are there any plans to incorporate a smooth scrolling option in, as opposed to “row by row” scrolling?
    There were plans, but we’re running out of time. However the changes we made should make it easier for us and/or you to make it work.

  8. Dwang says:

    Im wonder if it’s a way to change a row style , like mark some rows with color.
    You can color rows using the stylesFunction example in the item renderers section, and this functionaility will be formalized in the AdvancedDataGrid.

  9. Peter Wong says:

    Hi Alex,
    I’d really like to see smooth scrolling in Flex 3. What are the chances of this happening now?
    Zero. It has been pulled from 3.0. We’re looking to see if we can give enough clues that you can get it working on your own if you make assumptions such as that all of your rows are the same height.

  10. Rich says:

    Hi Alex,
    So, if all of my TileList rows are the same height, what do I need to do to coax some smooth scrolling (other than use the FlexStore2 solution and lose all of the ICollectionView goodness)?
    Cheers, Rich
    In 3.0, there are new properties added to ListBaseContentHolder and the main listContent doesn’t ‘have to’ be positioned at 0,0. We use this for the new dataEffects. We think there is a way where you hide the scrollbars, put up your own scrollbars and change verticalScrollPosition and listContent.y, but we haven’t proven it out, and we hope to provide an example soon.

  11. Nick says:

    Hi Alex,
    Was unnerving to see no mention of a possible fix to the huge issue of not being able to select a certain row/node/etc when there are identical strings in the data. Any news on this? ETA?
    It won’t be in 3. Maybe 4 if you can give me a scenario where it is actually necessary. When would you want the same string in there twice? How would a user know which one to select? To re-write the entire list engines to use something other than UID would be painful unless we place lots of restrictions like you can’t sort/re-order/insert/add etc. The common workaround is to simply wrap the strings in dynamic objects { label: “foo” }.

  12. Alex, is there any way to scroll just a branch level of the list classes currently or going forward in flex 3 or 4?
    Might seem like an odd request, but I have a few projects that need a “tree like” control where just the branch levels would be scrollable within the confines of the parent container.
    To do that with Tree would be difficult, probably a difficulty rating of 8 out of 10. The key factor is your selection model. How do users select items? Can they select the top-level nodes? How will scrollbars work? One for the whole container or one for each open node? I would definitely consider creating a custom expand/collapse class that shows/hides a List of subnodes and just fill a VBox with those things and then handle selection somehow.

  13. Nick says:

    Regarding the issue with recurring strings:
    Examples: In an XML-populated tree I can have a recurring text leaf with a certain value (lets say a job position “Manager” or a common name “John Doe”) who because of its position in the tree can be easily distinguishable. The bug appears. Or, lets say I have a datagrid that fills with name/value attribute pairs of a certain XML element () The bug appears.
    Browsing through the Flex bug reporting system I very quickly found several instances of this issue being reported (SDK-11307,SDK-8047,SDK-120,SDK-7981,SDK-12631). I think that the least you could do is adress this problem in the documentation and there suggest workarounds.
    I have not looked into the ListBase myself but I assume the following assumption would be correct (quoted from
    an option to allow the use of “===” triple-equality semantics (which would compare the XML nodes by reference in this particular case) would be nice, as this would resolve the problem entirely while preserving the current behavior for all unaffected users.
    If your dataprovider is XML, that bug should already be fixed in 3.0. Please get the beta, try it out and let me know if it isn’t.
    The case that still won’t work is a dataprovider full of plain strings.

  14. Nick says:

    Hi Alex.
    Thanks for your answer. There are still issues in the latest beta (and latest nightly build). The actual selection seems to work, selectedIndex is correct – but the visual representation still has the same problem (highlight and rollover still stays with the first instance of duplicate row/leaf), which means a user cannot tell what row/leaf is selected.
    Finally saw your test case. It will remain unsupported because it unfolds a single object/node.

  15. Hey Alex, I posted a few more examples of my various attempts at creating a scrollable accordion menu on my blog and at flexcomponents. I’d love to get your thoughts on the appropriate direction at this point. Best regards and hope you have a happy Turkey Day.

  16. Hey Alex, thanks for all your help pointing me in the right direction for the Accordion Style Scrollable Menu/List component I’ve been trying to build.
    I made a few comments on flexcoders that I’m sure you’ll see, but I just wanted to thank you personally.
    If you have any time to check out the demo and give me any comments I’d love to hear your thoughts.
    The working demo is on my blog. I’d post the full url, but the link is really long and runs outside of your blog.
    Best regards & thanks,
    Justin Winter

  17. Beau N. Brewer says:

    Here is a question I have been unable to solve on my own.
    I need to set an item in a list to a highlighted state without having the cursor actually over the item. I am dropping images into a album list and would like some visual feedback as to what album the images are going to be placed into without setting the selectedIndex or selectedItem in the list. Any help would be appreciated.
    Beau N. Brewer
    Alex responds:
    Our list classes have a drop feedback capability already. Override showDropFeedback and tell the renderer to alter its display somehow.

  18. shopping says:

    I think the changes are great and are certainly going to be very helpful. I see Adobe has now released Flex 3. I’m not up to date with where things are here now, but I wonder how this affects things going forward? I’ll have to browse around and see where things are right now. It’s been a while since I’ve been involved with these things.
    Alex responds:
    There’s always lots of new stuff being worked on here. The List classes still can use some improvements and we’re prioritizing the list of what we can do in the next release. If you have thoughts, file an enhancement request.

  19. The subclass is not running correctly. Do you have any fix for this? Can I still have the same performance if I remove the subclass(es)?
    Alex responds:
    I’m not sure what you are referring to. I would post your question in more detail on FlexCoders.

  20. paps says:

    Hi Alex,
    I am working on Tree control , i have to make it editable only on double click.
    I have seen that you have done the same for DataGrid.
    Even i followed the same step which you have mentioned for Tree control.
    But i am not able to update the value on click of enter key as well tab key.
    Could you please guide me how to do this.
    Thanks in advance
    Alex responds:
    I would recommend asking on FlexCoders. I don’t have the bandwidth to look into this right now.

  21. Sam says:

    I am trying to migrate our application to Flex 3.
    We are using ItemRenderers in the DataGrid and we need to know if the renderer is currently selected.
    This line of Code that you had mentioned in your previous posts( ListBase(owner).isItemSelected(data) ) does not work because Flex 3 expects a ListBaseContentHolder Class instead.
    When I cast to ListBaseContentHolder, there is no method that would tell me if my item renderer is selected.
    Any help would be greatly appreciated.
    When are you calling isItemSelected? The owner starts out as the LBCH, but later gets set to ListBase

  22. Erol says:

    Hi Alex,
    i have a TileList in my app which is geting data from a php server dynamicly it works fine to show items in it but DefaultTileListEffect is not working i try many ways but no success.
    if you whant i can send you a copy of the application.
    your help would be greatly appreciated.
    Alex responds:
    I don’t have time to help you. Please post on FlexCoders. Someone on there can probably help you.