Tuesday, June 10, 2008

Flex: Objects in Views

Imagine the following requirement:
The application needs a combo box that has the following options:
  • delete
  • mark as spam
  • bounce
When delete is selected the current email (the one being viewed) needs to be moved from the inbox to the trash.

When mark as spam is selected the current email should be tagged as spam.

When bounce is selected the server should send a reject message to the server where the email originated.
Assume you are using the web. The traditional approach is to create a drop down with unique values that can be used on the server side (generally as a case statement). The unique values are strings, which represent keys, which are used to determine what the correct course of action is. This scenario works, and is familiar to most web developers, but it's not the most elegant solution.

Flex offers you a better solution. The Flex ComboBox allows you to set the dataProvider to an array of anonymous objects which can contain pretty much whatever you need. Even if you don't know Flex and ActionScript, the following code should still be readable, and interesting.

function init() {
comboBox.dataProvider = [{label: "delete", command:DeleteCommand}, {label: "mark as spam", command:MarkAsSpamCommand}, {label: "bounce", command:BounceCommand}];
comboBox.addEventListener("change", function(){ new comboBox.selectedItem.command().execute(); });

function init() {
comboBox.dataProvider = [{label: "delete", execute:delete}, {label: "mark as spam", execute:markAsSpam}, {label: "bounce", execute:bounce}];
comboBox.addEventListener("change", function(){ comboBox.selectedItem.execute(); });

function delete() {
// delete implementation

function markAsSpam() {
// mark as spam implementation

function bounce() {
// bounce implementation

This is one of the things I really like about Flex. Since I'm not tied to HTML and strings, I can put whatever I like in the view. The first example keeps all the logic out of the view and simply creates a new command and executes it immediately. It's nice and clean without worrying about converting from strings to classes. The second solution relies on functions to handle processing. In this case you could be doing something as simple as showing or hiding components in the view (not something you'd need a class for).

Either way, I'm working with first class concepts, instead of string representations of first class concepts. The result is cleaner code that's easier to work with.


  1. You can easily do that in Javascript by extending the option DOM elements using jQuery (for example). Granted, you add the behaviour at runtime on the client side (so it is not nicely encapsulated in one place), but it has the added benefit of allowing you to fallback to the less elegant solution in case the client does not support Flash and/or has some accessibility issues.

  2. A nice example of functional programming that we often overlook in JavaScript, but adore in Ruby (and Haskell and Scheme and ...)!

  3. Hi Jay - Any chance we'll see a post outlining your take on the state of testing/testability in Flex? I'd love to hear your thoughts on that topic.

  4. Anonymous5:54 AM

    Hi Jason,
    Maybe in the future, but not just yet. Here's a sneak peek though.

    It's very similar to early JUnit. It's not great, but here's a few reasons I'm not so concerened:
    - There's little logic in my views anyway, the current app is Flex front end to Rails resources.
    - Anything that's annoying, I move out of my way by generating with some ruby scripts (for example: creating the file that lists all the test cases).
    - Anonymous objects in flex have been 'good enough' stubs

    It's mostly a "good enough, but not ideal scenario"

    There's one big win in my opinion though. With HTML & Javascript you have to test in browser to ensure that it works. This isn't true of Flex since there aren't browser issues. So, you can test in other ways that don't require long running browser based tests.

    More on this in the future... as I get more experience with it and solidify my opinions.

    Cheers, Jay

  5. Thanks for the preview. I seem to recall Neal Ford (well, I'm *pretty* sure it was Neal, but I'm not positive) saying that he wouldn't touch Flash due its horrible testing story. That makes good sense to me, so I was curious where Flex fell in the testability spectrum. It sounds (thankfully) like the story is better than I expected. Thanks for the insight, and I'll look forward to future updates.


Note: Only a member of this blog may post a comment.