Sometimes the benefits of a scripting language can come back to bite you in the rump One thing that I’ve seen a lot of recently is the practice of declaring a function to have a single parameter: Void. The intention here is to indicate that the function takes NO parameters, a feature that other languages sometimes support. However, in ECMAScript (and thus ActionScript) it does NOT have that meaning. In fact, the compiler instead declares a local variable called Void! You can debate all you want about how wrong or right this is, but it’s the way the language is designed.

Despite some of the additions to the language in AS2, ActionScript is still a scripting language and still allows you to pass a different number of parameters than what is declared in the function signature. In Flex we added some compiler checking to make sure that if you declare a variable or function that is already declared in the superclass, the type or signature matches between the two. This is to help prevent developers from accidentally overwriting a variable they didn’t know existed in the superclass. However it also catches something like our (Void) problem. All shipped Flex code does not use the (Void) convention. If you then override a function and use that convention (which may have been done a lot in in the V2 components with MX 2004) you will see the compiler give you an error about Void not matching the superclass type.

TheServerSide has posted a sample chapter from Effective Enterprise Java about state and data management within your J2EE application. While the book focuses on J2EE a lot of the concepts discussed apply to general application development. You’ll also get a preview of some of the things I plan on talking about at MAX in a few weeks. The first section of the chapter talks about saving state in the HTTPSession and some of the limitations; it’s practically an advertisement for some of the benefits of RIAs It also discusses data loading techniques coming from a relational database. You’ll recognize some of the issues from the large data discussions we’ve had.

Roger Gonzalez, one of our principal engineers and a regular contributor to flexcoders has written an article that explains how the Flex linker and loader work to deliver your apps. This article is heavy on detail and not for the faint of heart, but useful for those with some Flex experience. It’s especially interesting if you want to understand why I keep talking about dummy variables for linking in classes

Grand Central Communications is about using Service Oriented Architecture to integrate business processes. They’re introducing a developer’s network and as part of that are creating a developer contest where one category is best use of a rich client. Flex is all about rich clients, so if you think you’ve got some skills go ahead and enter!

Someone recently asked how you might intercept changes on an object so that you could know when it is dirty and needs saving. The catch was
that he wants to use binding to populate the object and doesn’t want to put event handlers on his controls just for this monitoring. Finally, he
wants the solution to be generic (meaning that writing your object to have setters and monitor its own dirty state is not acceptable).

I’ve written up one solution to the problem here, using a proxy object to pass changes through to the final object, and using the proxy as the
indicator of when things are dirty.