Update: Please see my announcement of a project based on the ideas in the post here

Uncontrolled browser pop ups suck, and I’m very thankful for pop up blockers. There are times, however, when you want controlled pop ups. It’s these times – the times when a user initiates the call to action – when the browser’s pop up blocker should let them through. Browsers are pretty good at managing this when the user initiated action starts in HTML, and most also do a good job when the action starts in a SWF. There’s at least one big exception – Safari.

The standard path in Flash to open a browser pop up is to use ExternalInterface to call a JavaScript function in the wrapping HTML page that contains a window.open call. This path works in all the browsers I tested in except for Safari, which leads me to believe this a Safari bug.

Luckily, if you want to open browser windows from a SWF in Safari there’s a workaround other than disabling the “Block Pop-Up Windows”! Check it out:

The workaround works by:

Besides the opportunity to hang with so many great Flex developers and Adobe engineers, the part of Flex Camp I enjoyed most tonight was clarifying the multiple levels of participation available to the community now that the Flex framework is open source. Basically, there are three levels of participation. They are researcher, adviser, and contributor. Details follow…

Over the years, Ali and I have spent quite a lot of time trying to sort out when to use static classes, when to use the Singleton pattern and when to do the work required to avoid them.

There has been a long and ongoing discussion in the OOP and patterns community on this subject by people far more intelligent and experienced than I am. It is really their knowledge and experience that will be essentially repackaged for ActionScript development here.

Following are the primary arguments that compel me to look for a better way.

We’re working on a modular application in Flex and until recently were having issues with embedded fonts in modules. The main issue was that we wanted fonts embedded in the main CSS to be available in the loaded modules, and we were having a heck of a time getting this to work.

Some research led me to Alex Harui’s post about how to use embedded fonts in modules and late-load the embedded font. Alex’s example demonstrates Flex 2.0.1’s new runtime CSS approach and uses the StyleManager class.

We’re not, however, interested in loading the CSS at runtime (although we reserve the right to change our mind, because it’s a really handy thing to be able to do), so I modified Alex’s example to more closely represent our application structure with hopes of finding my mistake. After the modification, it became clear that I wasn’t making a mistake, but that I had run into a bug. Can you spot it? Here’s the code…

Eloy Duran posted an interesting idea on his blog today about behaviour-driven development in ActionScript 2. According to http://behaviour-driven.org/:

Behaviour-Driven Development (BDD) is an evolution in the thinking behind TestDrivenDevelopment and AcceptanceTestDrivenPlanning.

For people familiar with the concept of DomainDrivenDesign, you could consider BDD to be a UbiquitousLanguage for software development.

Interesting…

Eloy’s idea, ASpec, is based on Ruby’s BDD framework RSpec. If you’re a student of test-driven development (TDD) or an AsUnit user, you might want to check it out.