ResourceManager is only as good as the components you use it with

The flex framework provides many conveniences out-of-the-box, one of them being the ResourceManager. It works wells and until recently I thought one could do no wrong by it.

Yet, as I recently found out, even the most fool-proof components are only as good as the developer using them. Being someone who started working directly with Flex 4, I have had it way too easy. And sometimes I miss out on the bigger picture as I lack the fundamentals that someone who predates the flex 4 framework, would naturally have.

Recently I was faced with a surprising scenario where the ResourceManager had all the translations in various languages for a given key, yet it would always only load one set of translations. After loading the initial translation for a given language, it would simply refuse to update the label, even as I flipped through and tried to change the locales one by one.

The resources for the resource manager were being downloaded from the server side and loaded on the fly into the ResourceManager instance. Adobe has a very nice example of this on their live docs website. But the first translation for the first language to have appeared would stick around and not change!

Another colleague, who was not so naive as to simply take things at face value, pointed out to me that I was trying to use the ResourceManager too soon so perhaps the translation in my label was from a point in time when the rest of the translations had not made it over. But looking at IResourceManager we realized what a well-behaved component it is! As it makes an effort to fire-off change events in order to alert its users that perhaps now there are more exact/locale-specific translations for them to lookup. So what could possibly be wrong?

The AHA moment: my pre-flex-4 colleague noticed that the over-arching component containing the ResourceManager bindings was actually and since it did not implement, extend or mixin the event dispatcher functionality, it would NOT receive property change events! And as soon as I started using something like the problem disappeared.

It just goes to show you that frameworks cannot replace a competent and well-versed developer who excels in his/her area.