Category: Flex

I was building this component to work with the DataGrid. It needs to to really “understand” the DataGrid, and part of that is being very intimate with how the DataGrid’s columns work. This is an array that holds DataGridColumns. These give data on how to draw the grid. The component needed to redraw itself if you passed in custom columns, just like if you passed in a custom array for the DataGrid. Additionally, it needed to update when the DataGrid itself had its columns changed.

Typically that last one is a rare use case, at least in my experience. You don’t go dynamically adding & removing DataGrid columns. However, if you do not explicitly set a columns array for the DataGrid, it has to read the first object of the dataProvider you send it (typically an array of objects). It then generates the columns from this object. The problem is, this initial event of generating columns does NOT fire a columnsChanged event. It was hard enough getting at the source code for the DataGrid, and I certainly can’t start building a stockpile of modified mx components in our class tree else I risk the portability of our code. Don’t get me wrong, I’d love to, there are a ton of little things I’d change, nothing big.

So what to do? Fix the function. This is easy in AS2; you just modify the prototype. This fix basically tells the DataGrid to call it’s existing generateColumns method, but in addition, dispatch the same event it’s getter / setter does so those who care can be informed.

DataGrid.prototype._generateCols = DataGrid.prototype.generateCols;
DataGrid.prototype.generateCols = function():Void
{
        this._generateCols();
        this.dispatchEvent({type:"columnsChanged"});
};

Yes, yes, I know… “Stop blogging about Flex 1.5, Jesse. Blog about Flex 2 instead!”.

Dude, it’s up to my client, not me… I’m working on it!

*** Update 7.14.2006: Got an official update.

(mt) Media Temple currently has plans for turn-key hosted Flex Data Services solutions. Although we don’t have a confirmed timeline for the rollout of these products please be assured they are in our pipeline and will be prioritized based on customer demand.

*** Update 7.12.2006: Been shooting emails back and forth with David Feinberg, a Product Manager at Mediatemple. He says they DO have plans, and are working on getting FDS setup. w00t! ***

I just asked Mediatemple sales and got a response. More specifically:

…To answer your questions specifically; at this time we don’t have any immediate plans to upgrade. Please check with our site or with me at a later time. …

Anyone know of any hosting companies that plan on doing Flex Data Services hosting?

When creating custom components, a lot of times it’s just easier to extend existing controls. For example, creating an auto-complete text field isn’t so hard; if you extend mx.controls.TextInput, the only code you have to write is for handling creation of the popup, and handling keyboard events.

The problem is validation. It’s an extremely complex process that works in many passes. In Flash MX 2004 and 8, it was constructor, init, createChildren, draw, and size. There were other minor, but integral functions in that process, but basically it comes down to create it, set it’s default properties, and render the mofo. This strong arm approach didn’t scale to Enterprise apps very well.

Enter the Flex framework. They further fine tuned the invalidation routines. Not only could you defer sizing and drawing to the next redraw event in the Flash Player, but all kinds of properties and styles. If you’re a seasoned Flash Developer, you know if stuff appears “not ready” you just wait a frame… or two. In Flex 1.5, things are no different. Typically, you can use a doLater (or 8) with simpler recursions for a lazy approach, or you can find what properties in particular start the process as most are pretty blatant (anything that calls invalidate).

I may sound like I’m bashing it, and I am, but it truly is valuable. Drawing once per redraw is better than attempting to draw 300 times a second when you can only draw 30 times a second. This is before refactoring and optimization of course. It’s just it’s extremely confusing the nuances of how those affect those extending the framework classes. You shouldn’t use Composition over Inheritance because you’re afraid of extending a class, instead feeling more secure by wrapping your own proxy methods around it as a safety net.

As a component developer, you may think you can take advantage of this, and you can. All the plumbing is held mostly in mx.core.UIObject and all his CSS and LayoutManager friends have hooks nicely integreated. The problem is mixing methods that redraw your GUI immediately vs. later. So, if you write methods that draw your GUI, and mix invoking them elsewhere with doLater’s, you can get unexpected results. The reason for this is that doLater’s are added to an array, and dealt with next screen redraw. After they are dealt with, they no longer exist.

I ran into a situation today where I was calling doLater in a class that extended TextInput, and they’d disappear off into the ether. The reason was, the method I was calling before was setting the “text” property. This is a getter / setter that actually causes invalidation. I’m doing the exact same thing in 2 places; calling a method that causes invalidation and then immediately calling a doLater after it. The only reason the second one fails is because the onEnterFrame spins off into the ether. The cause? Not sure. The first method is called when the internal component fires the enter key presseed event. The latter, broken, method is called in response of a List control being created in a popup being clicked on.

My guess is, the List emitting an event, and immediately being destroyed via a call from a Delegate scoped function somehow ticks off the internal guts of the UIObject, confusing it’s scope, and thus refusing to deal with the methodTable. Meaning doLaterDispatcher is apparently never fired even though onEnterFrame is happily chugging away, 21 times a second, doing nothing useful, eating CPU cyles.

My fix? Make all methods excluding the invalidation causing one to use doLater. Since there is no operator, similiar to public and private that goes something like “causesinvalidation”, I’ll just have to be extra mindful when extending controls that if I’m doing something that will cause multiple invalidations, I’ll have to provide a better conduit, such as a funnel method (you wanna redraw, you call me), or some other proxy.

Bottom line, if you doLater’s are failing to fire, try converting all functions to a doLater and/or indentifying what property you are setting / method you are calling that is causing the invalidation and tread around it.

…or build your own invalidation. Make a movieclip, make it’s onEnterFrame call your function via closure, and then immediately have it remove itself. This has worked flawlessly since Flash 4.