flex bug makes 9-slice seem slippery

an especially relevant bug to anyone skinning, 9-slice is non-operative on bitmap assets imported from flash. this lost me a couple hours while skinning tonik.

SearchCoders Dashboard: apollo app integrates as3 dev’s

Find code & commentary.  Provides mail list tracking, RSS feed pulls, Search, plus Chat about Flex/Apollo/Flash.

Bindings to E4X don’t work as expected

Our current application uses a large XML structure to send data back and forth between the frontend and backend. This is a legacy interface which was created 2-3 years ago by the developers of a Flash 6 version of the same application and has stuck with the system since then. If I had my druthers I’d use Flex Data Services to retool this into asynchronous micro-transfers to speed up the whole process but we haven’t been able to convince anyone to buy a license for FDS yet.

To get the data into and out of the XML structure I decided to try Flex’s Bindings. This would mean we’d just have to specify the relationships and whenever the values changed the data/UI would be automatically upated. This worked fine for each individual page I created but once I started running through the entire application each additional page created caused the application to slow down noticeably. By the 20th page or so the UI was nearly unresponsive when touching any element attached to a binding. Typing text into a TextInput was a laborious character-by-character process.

It was obvious that adding the bindings has caused this but at first I couldn’t understand why. Each element was tied to its specific place in the XML and so should have been firing a single binding. Looking closer I noticed that all of the bindings from the XML to the UI were getting fired *every time* a bound UI element changed.

It appears that the reason for this is that an E4X XML object fires a change event on the top-level XML object whenever anything inside it is changed and that bindings which have an E4X source fire when the top level changes. This means that every time I updated a UI element and the binding into the XML changed the value that all of the bindings *out* of the XML to the UI were fired, causing a huge slowdown.

I ended up writing the “bindings” as simple “=” statements and calling them when a page is navigated to or away from. This introduced extra work to make sure these happen at the right time, but it’s far faster and will be simpler to maintain given the structure of the code.

Only one Validator per element??

Further work with Flex Validators has lead me to find yet another limitation. You can have only one Validator per element. If you attempt to apply multiple Validators for one element you end up with the last one fired usually taking precedence as its errorString and valid/invalid events are the last set/fired. I do see the framework limitations making this happen but it is still very frustrating to not be able to combine Validators to their full potential. Things get even worse when you attempt to use a single-field validator and a multi-field validator on one element. This leads to nasty work-arounds which are nearly as bad as rewriting the validation code manually.

RadioButtonGroup is not an IValidatorListener

While building out a new framework for a series of highly form-centric applications in Flex 2 I ran into a strange problem. Seeing as I’m now using Flex I wanted to do things the right way and use a Validator to make sure that a value was selected. Imagine my surprise when the validation didn’t seem to happen. After some debugging and tracing through the Flex framework’s code I finally found that the Validator was firing and getting the correct result but failed to set the errorString property or fire the invalid event on the RadioButtonGroup being validated. Further tracing lead to the problem. The RadioButtonGroup was failing a test for “is IValidatorListener”. In other words, the RadioButtonGroup, which is conceptually a form element, does not respond at all to the events fired by a Validator.

Eventually through documentation and perusal of the RadioButtonGroup code I also realized that the RadioButtonGroup is not a UIComponent. This is understandable as the concept of a RadioButtonGroup is not linked to a specific layout of the radio buttons and the “group” really has no set physical presence. This explains why the IValidatorListener interface isn’t implemented in the same way as the other form elements as the UIComponent base class implements this for most of them. It doesn’t explain why the RadioButtonGroup does not implement it itself, however.

Of course you can always set the listener on the Validator to one of the radio buttons but I’d rather have all of the radio buttons show the error to let the user really know what’s happening.

To this end I created a RadioGroup class which implements IValidatorListener and sets the errorString and fires the valid/invalid events on each of the radios within the group.

1997: when filters were cool

actual splash screen for a beta of dreamweaver 1

editing page content without leaving the page

we should have immediate user feedback working on our flash sites.  ely greenfield’s flex controls provide one means to the end.  his classes allow on-page field editing.

navigation via landscape

although posted as an example of easy charting in flex. i like macro view & zoom for user navigation.

a flex landscape component, with several examples, shows landscape navigation through its flickr image search.  press “go.”