:cubicleman.com

Ok, so I’m no CSS Zen master, far from it actually. The thought of creating good CSS that is cross-browser supported and all just makes me shiver. I had to look at something today concerning links with fancy image backgrounds and rollovers that tweaked this image. After some quick googling, I am a card carrying member of the Google Brain Club, I found this neat article on A List Apart on something they call CSS Sprites. Wow, what a cool deal. Basically you use a single image for all of your links and just reposition this image as a background. What does this gain? Well, for starters only one image needs to be loaded or preloaded. Sure, this one image may be bigger than a single one of the single link backgrounds, but the composite is likely to be smaller and take only one request. It might very well fall into the same number of packets as a single one too depending on image compression and such.

So, how to pull it off? I’ll go over a quick single link example. First, fire up Fireworks (can you tell I’m not a real graphics guy? :} ) and create your two link, or button, states. Here is a sample:

Now, use some simple CSS magic:
#outerCont {top:0px; left:0px; background: url( images/button_states.gif ) 0 0 no-repeat;}
#outerCont a:hover { background: url( images/button_states.gif ) -200px 0 no-repeat;}

Here is a sample page showing it in action:
button_states.html

Back to our regularly scheduled Flex/Air fun!

peas
DK

When creating custom components it is better to defer any processing in your mutators(read setters) to the validation phase(s) of the Flex framework. This can be beneficial for many reasons such as performance, timing, etc. Consider the possibility that x gets set before y but that x needs y when x is set at runtime when you have no control over when these get set due to asynchronicity or some such. Also, it can cut down on the use of bindable variables, a performance bottleneck.

Enter the Flex component life cycle. I’m not going to cover the whole life cycle, but suffice it to say that in the life of a component it can enter a invalidation/validation phase. Flex uses these phases to synchronize changes. Note that this entrance is not necessarily a one-time thing either. So how do we make use of this? One approach is to use a method called invalidateProperties(). This tells the SDK that during the next cycle of the circle of life for the component to call commitProperties(). We do not call commitProperties() directly, rather we let the Flex SDK do that. Hence the notion of invalidation and validation phases. Ok, some code!

This is a typical pattern for coding a mutator in your component for a property called zinger:
//a flag to flag changes, this makes the circle of life more efficient
private var:Boolean zingerChanged;
//the actual var stuff
private var:int _zinger;
public function set zinger(val:int):void {
if( val != _zinger) {
_zinger = val;
zingerChanged = true;
invalidateProperties();
}
}
public function get zinger():int {
return _zinger;
}
//now overrride
override protected function commitProperties():void {
super.commitProperties();
if( zingerChanged ) {
zingerChanged = false;
//do your logic and such here concerning a change in zinger
}
}

Ok, there you have it. Aside from some possible typos, that should get you on your way to better performing components.

Cheers!

DK

We’ve let loose our extensions to the Cairngorm micro-architecture. Have a look and enjoy!
http://code.google.com/p/flexcairngorm/

Jeffry Houser has invited Thomas Burleson to his show to discuss them. You can give it a listen here

DK