Flex Pasta

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

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.

I was using an embedded font today with modules and charts.  My embedded font is declared in the css file and is only referenced in the main application page and not in each module.  When embedding the font in the main application, I would expect the font to be carried over into each module, the same way all the other styles work with modules.  For some reason though, the labels on the axes of the column chart don’t appear when the chart is in a module using an embedded font.  I have opened a bug with Adobe regarding this issue.  I’m not sure if it’s the chart doing something weird or the Flex compiler(or maybe me!).  In any case, I don’t think the labels should disappear.

Run the example and see for yourself the behavior: Charting.swf

Panel 1 is a column chart declared in the main application and Panel 2 is the exact same column chart in a module.  There is an embedded font ‘Verdana’ in the main application.

Charting.mxml

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”horizontal” xmlns:local=”*”>
<mx:Style>
Application
{
font-family: Verdana;
}
@font-face {
src:url(”font/verdana.ttf”);
fontFamily: Verdana;
advancedAntiAliasing: true;
}
@font-face {
src:url(”font/verdanab.ttf”);
fontFamily: Verdana;
fontWeight: bold;
advancedAntiAliasing: true;
}
@font-face {
src:url(”font/verdanai.ttf”);
fontFamily: Verdana;
font-style: italic;
advancedAntiAliasing: true;
}
</mx:Style>
<local:ColumnChart width=”50%” height=”100%” title=”Chart 1″/>
<mx:ModuleLoader url=”ChartModule.swf” width=”50%” height=”100%”/>
</mx:Application>