Blog

The development tool for for Flash, FDT could replace the “A” in FAME. Typically, one would use ASDT (ActionScript development tool) for code hinting, coloring, and creation/recognization of ActionScript in Eclipse.

They have a lot of great demos done in Captivate, and documentation if you care to read instead.

Check it out!

Good discussion over my blog that spilled to email with Grant Davies. He did a coup de grace whilst I drank watered down coffee on my ARP mods. He called my modified ARP Controller a glorified hashmap, and he’s right.

The Controller in ARP responds to events made from View’s, and runs Commands when those events happen. You click the Submit button, it dispatches the click event. The Controller is listening for the click event, and runs the Login command. Your atypical MVC Controller; listen to events, trigger code to respond to those events.

I’m faced with a challenge which I’ll probably solve while writing this. Since my changes, the Controller is no longer a controller in the traditional sense. It merely holds command classes in a hashmap (ActionScript Object), and allows you to run them (instantiate the class, optionally passing parameters). That is not a Controller.

To reiterate the reason I did this to give some history and context, I felt that when writing dispatchEvent in my View’s, it shouldn’t imply anything. To me, event names are spur of the moment, just like naming variables; “What should I call this that’ll make sense, fall more to the verbose side vs. the brief side, and overall make sense?” In ARP, however, this choice carries with it the addition of knowing this event may eventually end up being mapped to calling a Command in the Controller. I didn’t like this, at least for those high level View’s that would be considered emitting system events. Granted, you wouldn’t have to worry about a Button’s click event triggering a command, but your Login component could trigger a command by its click event.

Peter Hall and I had Aral note our distress, and he in turn suggested we use handleEvent which would allow us to intercept any events and do the mapping ourselves if we so chose. Since handleEvent is called before the actual event on an event listener using EventDispatcher in Flash/Flex, it’s a nice, low-level way to get more control of your events.

At this point, I may have to re-examine that as an option.

Typically what I’ve been doing is making an Application class; whether extending my ApplicationTemplate, or Flex’ Application.mxml. This holds all initial logic to create the main GUI’s, who in turn holds all other View creation/destroying, and manages listening to events and running commands; in effect, it’s a Controller and a View in 1; not so strange in Flash. Many purists do not like doing this since a Controller should be a controller and just a controller, and I understand perfectly why. ARP being lightweight enough allows me to bend the rules to my liking.

However, I don’t think I can bend word definitions however; Controller is no longer such, and without multiple inheritance, I cannot have mx.core.View & Controller become one and the same without using an mix-in which most people, except me, hate.

…ok, that didn’t work, writing it out didn’t solve it. Perhaps if Controller extended mx.core.View instead of Object, I could use it as my base View/Controller class since most of my apps are Form based anyway, this would work out well. Back to the lab.

Community input, rocks!