Matt's blog

Flex Builder 3 - project references

Simply put, they don't work!!
If you've ever developed a Java application in Eclipse, you'll be well aware that if you set a project reference of Project B in Project A, the code in Project A will be able to "see" the code in Project B.
However, Flex Builder (which we all know is based on Eclipse) does not work this way. You have to manually add Project B's source directory to Project A via the Flex Build Path project settings. The most frustrating part of this is that Flex Builder stores the actual directory of the other project, so if you have multiple developers working off a single codebase, it's highly likely that each developer will have to change the source path to match their environment.
Shame, eh?

Mate - abstracting the business logic/data communications and presentation

When I first wrote about Mate vs Cairngorm, the main concern I stated with both was that in any MVC architecture there's little consideration given to splitting out the data/business code from the presentation code.
Here is my solution.

Mate gotcha - events not being picked up by EventMap

I've been using Mate heavily over the last few weeks and am really enjoying implementing the architecture. However there are a few gotchas that caught me out and I'll write about them here.

Flex microarchitectures - Cairngorm vs Mate

I've recently been comparing various Flex architectures for managing business logic and server communications. The two main systems I've been looking into are Cairngorm and Mate.

Custom renderer skin inheritance in Tree and List controls

I just spent most of the day trying to figure out a problem with a custom item renderer skin, so I thought I'd write it down here in case anyone else comes across this.

Data binding with setters/getters

There are a few gotchas when trying to get setters and getters to data bind. The first one has been covered elsewhere, basically it's essential that you have both set and get methods in order for Flex to bind to setter/getter changes.
The other is less documented. It's pretty obvious when you think about it but took me a while to figure out what was going on. Generaly, most setter/getter functions are public accessors to private variables, for example:
private _myString:String = "";

[Bindable]
public function get myString():string { return _myString; }
public function set myString(s:string):void { _myString = s; }
In my previous work with this structure, when I change the value from within the class itself, I always modify the private _myString variable directly rather than going via the setter function. This is slightly more efficient as less code is run, and in some circumstances I do not want the setter to run if it includes additional logic. However, this method will not fire the data binding event, you must call the setter explicitly, for example:
private function changeString():void {
_myString = "hello"; // This will NOT fire the event and data binding won't work
myString = "goodbye"; // This WILL fire the event and data binding will work as expected.
}
Hopefully this information may save someone a bit of time!!!