Some goals I wanted to achieve were:

1. As little code as possible to wire up and unwire events.
2. Lean more toward convention over configuration.
3. Easy to see which events were being listened for (remotely like the delegate concept in Objective-C)
4. It’s not a goal, but I didn’t care about proper use of accessors (one drawback of Hotwire)

The source for Hotwire is 62 lines long, so you could probably clone it and analyze it quicker than I can describe it, but I’ll outline a few use cases anyway.

Usage 1: As Simple As Possible

This is as basic as it gets. You store a reference to an instance of Hotwire, which sets up at least a Event.REMOVE listener, then you call unwire(), which removes all the event listeners setup by the wire() call.

By default, Hotwire attempts to register the event with a listener with the prefix “handle” then a properly-cased version of the event name. Therefore, since Event.ENTER_FRAME is the string “enterFrame”, the listener that Hotwire will wire up is “handleEnterFrame”.

Usage 2: Listening to Other Dispatchers

In the Hotwire constructor, the first argument is the dispatcher, and is the only required argument. The second argument is the handler, and if it is not specified or null, Hotwire will consider the handler and the dispatcher the same object. In my projects, I used custom bubbled events a-plenty for child display objects, and never specified a different handler from my dispatcher until I needed to handle Stage events, which don’t bubble. (I haven’t run across another instance where I couldn’t simply use bubbled events the way I wanted to, but I’m sure I will.)

Usage 3: If you don’t like “handle”

Personally, I like the word “handle” as my handler prefix. I can type handle+Ctrl+Space and get a list of all my handlers, and it’s descriptive. I know that many people like to use “on” however. If you want to change your prefix for one instance, it’s the third argument in the constructor, as you may have noticed in the example above. If you hate “handle” just change the source code. It’s 62 lines. Don’t hate.

Finally

So that’s it. I think Hotwire might be useful if you wanted to wire / unwire groups of events easily also, just by creating separate instances of Hotwire. (Although, I might argue your class is getting too complicated?)

There are some cons to Hotwire that may make your architecture blood boil (for some reason I’ve been much less OCD about all this, so I’m just letting it roll and enjoying the short time of non-obsession):

1. Public handlers. Yeah, if you make private or protected handlers, the instance of Hotwire can’t wire them up. Well, hey. It’s a mixin-y class. Put some Baileys in your latté and discuss architecture with me when I come back to my senses.
2. Handler names derived from constants. This could be pretty bad if you are wiring up to Event.ENTER_FRAME which is currently “enterFrame” but Adobe decides to change to “zomgAppleSucks”. Yes, this might be a problem. In the remote chance this happens, :%s/handleEnterFrame/handleZomgAppleSucks/g and go back to your latté.

If you find it useful, let me know. If you have improvements, fork it. If you think it’s horrible and want to throw your latté at me, please do, I love constructive criticism and alternative perspectives. I’ll just passively-aggressively unfollow you on Twitter.

If you still aren’t clear on how to get Hotwire, even though I linked to it like a million 3 times, it’s hosted on GitHub, and you can get it here.

As someone who has worked with Flash since FutureSplash was acquired by Macromedia, and as someone with both a design / animation and programming background, I agree with Adobe’s decision to go with a more structured implementation of ActionScript in Flash with AS3. I believe it is a strategic move to position Flash as a viable platform for true RIA development.

There’s no reason that a toolkit couldn’t be written that abstracts the API to provide some of the functionality mentioned in the article. It would streamline development for designers / animators, yet maintain the architectural integrity of AS3.

It’s undeniable that the new VM is harder, better, faster, stronger. The level of complexity of the API needed to increase to provide access to the host of new features–not only for the contemporary version of Flash, but also to elegantly scale for the future.

Consider even the nomenclature of the AS2 display object hierarchy. “MovieClip”? Think about how someone from a development background (not Flash) would approach the idea of an interface comprised of “MovieClips.” They’re not interested in frame-based animation. They don’t want to play a movie. They want to draw vector graphics on the screen. So they create a “MovieClip”? I think Adobe has done a fantastic job of maintaining cohesiveness between a logically engineered AS3 API and the legacy AS2 API that anyone who has evolved as a designer / developer with Flash would be familiar with.

I believe that AS3 allows a developer to logically approach Flash as a UI platform with some amazing capabilities. I think AS3 alone may prove to be a challenge to a designer without any programming background, but this is not unmitigable with a well-written toolkit for designers. Maybe that’s the core of what I’m saying–that you can go one way but not the other. You can abstract an API to make it easier for a designer to use, but you can’t go the other way and take an abstracted API and make it more powerful for developers.

Specifically related to Charge #6–that’s definitely biting the hand that feeds you. SOME errors are better than NO errors. I think it was incredibly cumbersome to code to AS2 for the example that was cited in the article. I agree with the verdict NOT GUILTY.

I would also like to say that I concur with the other, arguably non-AS3, issues mentioned in the article, specifically “Failure to Unload,” which has caused me much grief in the past.

My intent is not to come off as a pretentious “real Flash developer” to all you “plebeian designers” or something, nor is it to slam Colin, whom I hold in very high regard, but I hope that this provides some counter-rationale.

The “come and get it” policy file typically looks like this:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*" />
</cross-domain-policy>

However, we noticed that an intranet project we’ve deployed stopped working on certain computers, throwing the following error:

[RPC Fault faultString="Security error accessing url" faultCode="Channel.Security.Error" 
faultDetail="Unable to load WSDL. If currently online, please verify the URI and/or format
of the WSDL (***YOUR WSDL ENDPOINT HERE***)"]
      at mx.rpc.wsdl::WSDLLoader/mx.rpc.wsdl:WSDLLoader::faultHandler()
      at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
      at flash.events::EventDispatcher/dispatchEvent()
      at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/mx/internal::dispatchRpcEvent()
      at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/mx/internal::faultHandler()
      at mx.rpc::Responder/fault()
      at mx.rpc::AsyncRequest/fault()
      at ::DirectHTTPMessageResponder/securityErrorHandler()
      at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
      at flash.events::EventDispatcher/dispatchEvent()
      at flash.net::URLLoader/flash.net:URLLoader::redirectEvent()

When you check out the XSD for policy files, you’ll notice that (among other things) they’ve added a “allow-http-request-headers-from” element. So the new “come and get it” policy file looks like this:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*" to-ports="*" />
    <allow-http-request-headers-from domain="*" headers="SOAPAction"/>
</cross-domain-policy>

This should allow you to consume your services from basically anywhere. Remember to lock your stuff down when you deploy.

new Array();
var attributes:XMLList = _data.Attributes..AttributeDescriptor;
for each(var attribute:XML in attributes)
{
	trace(attribute.@ID);
}

This doesn’t (outputs nulls):

var attributes:XMLList = _data.Attributes..AttributeDescriptor;
for each(var attribute:XML in attributes)
{
	trace(attribute.@ID);
}

Any questions?

Update: Kudos to Larry (developmentastic.com) for beating his head against this brick wall on the Winestore project.