Blog

Installed Firefox 1.5 late in the week, and found that external links (like when you click on a link in email) default to opening in a new tab, whereas before they would open in the most recent window or tab. Usually, I’d have to use precognition techniques to know this was going to happen. Thus, I’d either open a new blank window, or tab, and THEN click on the external link.

When compiling in Flex Builder 2, she opens up the most recent HTML & SWF in your most recent Firefox tab or browser window, same as external links. With 1.5, however, it opens in a new tab. A really subtle addition to the new Firefox that really helps when developing in Flex Builder 2.

Now, I can actually keep the documentation open in one Firefox tab while I play in Flex Builder 2.

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.

Learned something this weekend about how to do multiple inheritance in Flex after going through the FileIO examples from this DevNet article. It’s something very fundamental to how Flex works, and the fact that I’ve made it this far in my Flex career without knowing it either A, clearly illustrates how powerful composition is in Flex, or B, how rarely I extend more than 1 base class.

Extending a class in Flex via MXML is easy. If you want to extend any class, you merely make it the root tag in your MXML. Below, I’m extending mx.containers.VBox:

<?xml version="1.0" encoding="utf-8"?>

<mx:VBox 

xmlns:mx="http://www.macromedia.com/2003/mxml"

width="400" height="400">

  <mx:Form>

    <mx:FormItem label="Username:">

      <mx:TextInput id="username_ti" />

    </mx:FormItem>

    <mx:FormItem label="Password:">

      <mx:TextInput id="password_ti" />

    </mx:FormItem>

  </mx:Form> 

</mx:VBox>

When mxmlc.exe, the command line compiler Flex uses, converts that to ActionScript, you are basically doing:

import mx.containers.VBox;

class Login extends VBox
{
        // create children code
}

Both would look like this:

I’d save this as Login.mxml. However, from this point on, I’d usually use Login.mxml as a component in another component/class. I’d never want to “extend” my Login component to do something else… until recently.

Flex 1.5 uses a lot of mixins, since it’s based off of a lot of the Flash MX 2004 v2 component codebase. As such, most mixins are best used by being applied to an abstract base class, with which you later extend the abstract base class. It’s called abstract because you never actually instantiate the class itself; it’s merely there for inheritance purposes only; it was made only for being extended, not for being used.

Since ActionScript currently does not support multiple inheritance, the easiest way to fake it in ActionScript 1 and 2 is to utilize mixins; classes that utilize the Decorator pattern to add methods and properties to a class at runtime.

The downside to this is, even though you can define the properties and methods in your class so your compiler doesn’t bitch, adding event listeners for events that don’t yet exist is problematic, ecspecially if you don’t have control of the mixin. Case in point, mx.controls.listclasses.DataSelector.

This class adds basic list functionality to your class as well as support for dealing with dataproviders. The problem? The class the mixin is applied to cannot use modelChanged after the first listener. Quite frustrating, as I’ve written about before. You can use a static initializer that is run after the mixin’ to further overrwrite the modelChanged function on the class’ prototype to force it to call yours.

While that works, you’re still left with a quite unweidly class to start writing your own logic. The class itself works mind you, but if you’ve seen the DataSelector template your supposed to copy so your class will compile, it’s a LOT of stuff.

So, best to extend.

…problem was, I didn’t know how to do that in Flex, nor really know how to ask the question. So, I used the prototype hack. This was really the ONLY time I wanted to actually ever extend one of my components, and while I could of fallen back to using pure ActionScript, it’s just too much work to write all of that GUI interaction in ActionScript when MXML is faster, and easier to change without breaking my code.

So, looking through the FileIO examples, and I see they build a component, and then extend it by using the component’s name as the root tag. Well… DUH! Of course, how could I be so short-sighted? That is exactly how you extend, and have been, extending existing built in components, why would it NOT work for MY components?

Example:

<?xml version="1.0" encoding="utf-8"?>
<Login
  xmlns:mx="http://www.macromedia.com/2003/mxml"
	xmlns="*"
	initialize="initLogin()">

  <mx:Script>
  <![CDATA[
		
    private function initLogin():Void
      {
        var so:SharedObject = SharedObject.getLocal("username");
        if(so.data.username != null)
        {
          username_ti.text so.data.username;
        }
      }
  ]]>
  </mx:Script>

</Login>

I managed to code Director for a year before learning how to return values from function calls. Apparently, one can go longer than that in Flex without knowing how to do more than 1 level of inheritance.