Flex Pasta » Flex 5: AdvancedDataGrid

Flex 5: AdvancedDataGrid

Ever since the AdvancedDataGrid joined the SDK it has been a bit of a love hate relationship.  The great features the grid brought were essential for many projects and usually centerpieces in an application’s functionality.  But the shocking part was the amount of bugs and lines of code(30,000+ lines…yikes!) that still plagues it.  Doug McCune wrote a great posting on the AdvancedDataGrid and the lines of code it has, not to mention the 415 line method!  The functionality of the AdvancedDataGrid is complex, so before I pile on with everyone else, let’s just point out that 1) It’s complex, 2) Sometimes lot’s of hands in the cookie jar can result in a lot of crumbs, 3) Writing code that the whole community can see instantly isn’t always easy.  The mistake with the advanced data grid was probably at the beginning.  Based on comparisons with the DataGrid classes, it appears most of the code was copied from DataGrid to the AdvancedDataGrid and then pieced together.  I am always against large code copies, because this scenario almost always is the outcome:  Bugy software that is overly complex to maintain and a nightmare to consider rewriting.

Worst pain ever sound bite  The Simpsons sound bites

Worst pain ever sound bite

What is the solution for the AdvancedDataGrid?

It needs to be rewritten.  Matt Chotin(SDK PM) wrote a posting about the status of the AdvancedDataGrid and Data Visualization.  Not exactly thrilling news as it doesn’t look like any major enhancements to DataGrid and AdvancedDataGrid will happen until Flex 5, but I understand why the spark architecture has taken priority.

Here are the 3 main things I hope get corrected in a rewritten AdvancedDataGrid:

  1. Comments.  There is very little commenting.  I open the AdvanceDataGridBaseEx class and the comment for this class is: “The AdvancedDataGridBaseEx class is a base class of the AdvancedDataGrid control. This class contains code that provides functionality similar to the DataGrid control.”   That is the description for all 8,000 lines.  Based on reading this I have no idea what AdvancedDataGrid is doing extending it, and why it extends AdvancedDataGridBase.  The Flex SDK should take a page from the Java SDK and write lengthy descriptions for each class.  Take for example java.util.HashMap at 1,000 lines of code.  Paragraphs of comments just documenting what the class does, and comments on every variable and method.  While most of the Flex SDK does have good documentation, class documentation in the spark architecture has been drastically improved.  Good docs are needed even more for the complicated code!
  2. Smaller methods and better utilization of the protected keyword.  415 lines is a ton.  This isn’t the first time I’ve seen this sized method.  One of the biggest hardships is when there is a bug or slight tweak needed to a component.  The code is not able to be overriden or is buried in a giant 415 line method which is impossible to override anyway.
  3. Use Helper classes.  The AdvancedDataGrid will have a large amount of code(not 30,000 large, but large).  Instead of having a class that extends a base class that extends another base class that extends another base class, let’s use helper classes that group common functionality together.  For example, for the advanceddatagrid, create a helper class called KeyBoardUtil.  One method can handle cell navigation, a second tree navigation, and so on.  It isn’t always easy to do this because of all the moving parts.  By cutting out key pieces of functionality, such as keyboard controls, code readability is improved, blocks of code are smaller,  methods can be better tested, and code can be reused.  Helper classes help define exactly what parameters are needed for the functionality and provide a clear goal as to what in return the helper functionality will modify.

3 Comments

  • 1. Mike Thompson replies at 24th November 2009, 12:58 am :

    I just hope the team responsible for the AdvancedDataGrid is never allowed to work within Adobe again.

    Their performance is just appallingly bad. The code is just horrifically ugly (I means, 415 line methods! And O(N^2) algorithms used in cell selection where O(N) is effortlessly possible). And then, to cap it all off, the process of fixing bugs is shambolic (does anyone know why critical bugs are marked “closed/deferred”, or even what that means)?

    Adobe should feel acutely embarrassed over this stuff up. They should then stop feeling embarrassed and actually do something about it. Like fix the outstanding bugs. Don’t enhance it. Just fix the bugs please. I really don’t think that’s too much to ask.

  • 2. Tom G replies at 24th November 2009, 1:40 pm :

    I don’t think you can always blame the team, I’m sure they had their set of pressure and its not a simple product. It was their version 1.0 working with someone elses code in another country. If Adobe had any common sense they would ask them for version 1.5 or 2.0. Clearly Adobe doesn’t think its necessary and customers will wait a few years before jumping ship. Look at some of the blogs from prominent India team members and you will see they have been tasked with totally different products (Ruby for Flash Builder? WTF)(http://flexpearls.blogspot.com/). Please get your priorities straight Adobe, fix what doesn’t work for your current customers before trying to conquer brave new worlds.

  • 3. Mike Thompson replies at 25th November 2009, 10:52 pm :

    I remember Seth Goding blogging on this type of situation a little while ago. His point was that “something going wrong” is a fantastic opportunity for a company to build good will. People are in pain and you, the company, can do something about it. Promptly. With good communication. Honestly. Humility.

    When everything is going right, there’s limited chance that you’ll build much good will. But fixing something that’s wrong and painful, is a fantastic opportunity for building good will.

    Now, I can’t find Goding’s blog item right now, so I hope I’ve paraphrased him correctly.

    My point is that Adobe has completely dropped the bundle on this problem. It’s not that they sold us a half baked component full of problems, it’s what’s they’ve done SINCE THEN which annoys me. It just wouldn’t be that hard for them to fix the problem. But they’ve let the whole thing become shambolic.

    A few half decent programmers pounding on the code for a few months, and the AdvancedDataGrid would be passable. Never great but passable. And we’d all be very grateful and have some respect. Are they that disorganised they can’t see this. Do they care so little about what we think?

    It’s not as if they haven’t been told.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>