View Emits Events While Controller Commands

Skip to “Who Runs Commands?” to get to the meat.

Background

I’m a young engineer, and as such I’ve yet to fully appreciate all the work that goes into certain API’s and frameworks. As such, I’ll constantly re-invent the wheel since I don’t trust the assumptions and standards others thrust upon me and want me to be believe. This is bolstered when I find some do not hold up in real-world scenarios, whilst others do. The former usually because some implementations are usually for extremely explicit scenarios, and rather than having 2 pages of documentation describing such, you usually get 2 sentences which unfortunately gives false impressions.

One such scenario I’ve been testing the boundaries of for the past year and a half is ARP and Cairngorm. Cairngorm, a framework for Flex, and ARP, a framework for Flash (& Flex if you work it in). By their very nature, frameworks and even components abstract low-level details away, so you have something more simple to deal with. H&R Block for example is a company in the US that you go in, hand them some papers, answer some questions, and they file your taxes for you with a guarantee to be protected from any IRS inquires for that tax year.

CPA’s on the other hand recognize that there are significant things that H&R Block won’t always take into account or do for you, so when filing their own taxes, CPA’s will know what effect their actions have. While more involved, they have a greater outcome.

So why not do what a CPA does? Investing the plethora of time, research, money & education as well as the yearly certification only to save $100 on my taxes every year doesn’t seem to be worth it, specially when finances aren’t my thing. Granted, I could learn more, but it’s not readily apparent.

Same thing with code. A lot of the lower-level details are not what most programmers are interested in. While they may find it “neat”, most are interested in accomplishing a task, albeit getting something done. Why spend 3 months coding & QA’ing a component set when a perfectly good CheckBox and ScrollBar is already written for you in Flash 8? If you’re a JSP programmer, why invest the time to learn the bowls of Flex and adapt your practices with Cairngorm already provides an attractive & familiar in?

I’m the guy who used to write his own components… until I wrote my 3rd scrollbar, and realized mine STILL didn’t have all the functionality that the Flash MX one did, nor did it integrate with the rest of the set. But I learned a lot about how things work, and learned to respect the writers of the components.

Frameworks are a little different than components. They are the 2nd tier. Components take low-level code, and build UI widgets for you to utilize in Flash. Coding a button is pretty brainless in Flash; you draw a circle, select it, convert it to a button symbol, and put an on(press){ trace(“do something”); } on it… done. But, for real applications, that won’t suffice. You need state management, events, skinning, labeling, etc. A plethora of other things that all need to integrate into a whole.

I’d even argue the v1 components originally introduced in Flash MX were a mini-framework since as soon as you use one component, the nature of how Flash Player works changes; more pronounced in Flash MX 2004’s v2.

Bottom line, though, they are just UI widgets. They themselves do not implement Model View Controller (MVC) separation of your code; they do 1 thing, and are good at it. They work together to a point, but they aren’t an app on their own, just like a bunch of wood, nails, and a hammer aren’t a house. Both have the potential to be greater than the sum of their parts, but with no initiative to build with them, they are just tools.

Frameworks, on the other hand, at least in my experience, tend to be more of application building guides to a point. Your interface goes in Views. All communication with our back-end goes into Delegates. All of your data goes into ModelLocator. All of your user interactions go into Commands. Everything’s brought together in your Controller. Both ARP and Cairngorm capitalize on a specific implementation of MVC in Flash/Flex, and accentuate the best parts to those developer audiences they cater to.

ARP & Cairngorm – The Differences

The only 2 really hard-core differences I can really find between the two are ARP doesn’t have a ModelLocator, nor any form of ViewHelpers. The former is because you can only bind to Array’s in Flash MX 2004 with the help of DataProvider, a mixin class. There are other binding classes, but no one uses them… and if they do, they don’t blog about it or speak about it on email lists (MXNA & Flashcoders). There are ways around this, using getter/setters as well as watchers to dispatch events, but it’s quick hackish.

From my preliminary research, ARP also doesn’t have ViewHelpers because most Flash applications, what ARP was originally designed for, did not have an inordinate amount of Views, nor a multitude of developers. Inordinate meaning above 30 or whatever a typical Flash Developer would consider “I can manage.” Secondly, most Flash Developers were, from what I can from being involved in the community, extremely involved in the Views’ creation & maintenance, so knowing how they worked as well as working with others was not an issue.

I found ways to get ModelLocator to work using ARP in Flash; just ensure all of your data is arrays. If it’s not, such as a string or number, don’t expect to be notified when it changes. I’ve discussed things with a developer at work and still don’t see the point to ViewHelpers, mainly because I’m currently the only one on the client portion of the project, and pieces of my app will in the future be integrated into other parts of various applications as new Views, necessitating those developers “know what they are getting”.

However, everything else, I’m slowly but surely confirming each has it’s usefulness vs. calling bs on something being abstracted just so you can say your’re a purist at LAN parties & industry events.

Class Breakdown – Who Rocks, Who Doesn’t

ServiceLocator, the class which abstracts who your conneting to and how? Check. He rocks the fuggin’ mic. Changing 1 line of code in him does wonders in converting your entire back-end from using PHP to ColdFusion for example. Yes, yes, you may have to change methods in your Delegate, but then who was the goob who forgot to write a document for the methods to use?

Commands? Hell yeah. My Controller has enough to worry about; encapsulating chunks of code pertaining to a specific user task that is callable, does it’s thing, and let’s me know when it’s done… straight bangin’.

Delegate’s? Not convinced. While it certainly cuts down on the complexity of my commands, this is only 10% of the time, the other 90% merely causing my commands to be bloated unnecessarily. My advice; opt-in to using Delegates vs. opting out later when you realize only 2 out of 40 do something beyond making a webservice call and returning the response.

ValueObjects? Sure… unless you’re using ColdFusion, at which point you’ll have to convert it back to a vanilla object before you send it back via Flash Remoting, and convert objects to their appropriate type when you get them coming in from the server. In AMFPHP, .NET, and OpenAMF, heck yeah, helps ease communication, even when using CF.

ModelLocator? Can’t live with out it. Used with binding in Flex, it’s off the chain.

So, that covers all the good stuff. One thing I’ve done differently in my build of ARP is de-couple the “Application” class and “Controller”. I threw Application away, and re-named Controller to CommandRegistry. It merely provides a string alias to a command class, and acts as a Singleton to allow you to call commands from anywhere.

Who Runs Commands?

I’ve started to realize, though, that my original decision for doing this (making a CommandRegistry) wasn’t the best thing to do. The reason I did it was, I didn’t like how all events that the Application class received automatically ran commands. I could of implemented my own handleEvent function and routed them myself, but… this felt wrong, still to pinned. To me, if you get a constraining feeling from a framework, you’re best bet is to drop it, and that’s what I did, only using the parts I liked.

Now, however, I realize why it was a bad idea… to a point. When certain milestones have a deadline looming, what I’ll do is allow some deeply nested View, say an input form in a popup window generated by some parent form, to run a Command via the CommandRegistry. Why not? He’s the only one who uses it.

Time and time again, however, I’m starting to find there are certain “things” I need to do before a command is run, as well as after. For example, when the user is submitting data to the server, I need to update some global variables (ModelLocator), generate some app wide events, and pull data from other sources. When they are done, I sometimes need to update other parts of the app.

What this caused is my Views started to have data management in them, like manipulating ValueObjects. This got worse when the same conversion code was duplicated in other Views, and even the same code in 3 different Delegates. Five different versions of code going, “Dude, you’re from the server, right? Are you a BusinessObjectTypeA or TypeB?” led to serious debug headaches, and got really frustrating to manage when I fixed 1 bug, only to find it re-surface later from the same bloody code.

It was kind of frustrating, because, for some Views, say the Tree I’ve been using the pretty much drive the entire application, he knows a LOT about how his tree nodes work, and how they relate to other events. There is a fine line between what a View can do best, and where his manipulations of data is better handed off to the controller. When there is a deadline, there is no question; you just leave a comment:

// TODO: move this Command to the Controller,
// this View should not be doing all of this logic

However, for some, it required a lot of thought into how much context the event should have so when whoever gets it (since I make all events in Flex bubble by default), they know what to do with it if they so choose to handle it. Better to give too much information in an event vs. not enough.

So, yesterday after lunch, I was moving some commands like the TODO statement above suggested, and suddenly found myself deleting more code than creating. Trimming the fat as it were. Since the Controller had most of the common data & view handling code, it also made it more readable, and you started to see common patterns; always a good sign!

…and suddenly, I found little use for my CommandRegistry being so flexible. Granted, it’s nice when you’re under the gun, you can just empower a View to “be all he can be”, and just clean up the mess later with a well built event.

So, I can clearly see now the point of why View’s should only emit events. Do your job; show pretty things, and let me know when the user did something, or I the Controller should know about something… period.

Secondly, the only point of my CommandRegistry now is flexibility during development… and really don’t know how it’ll fly with multiple developers, either… probably not.

Anyway, it’s great to have these glorious ideas actually tested on the field of battle and proven to be worthy.