Archive for December, 2008|Monthly archive page

Introducing Kashi

I’ve been working on what I’m gonna call a radical branch/sect of Cairngorm. It’s currently code-named Kashi because that is the brand of cookie that I was eating at the time. The idea is to keep the basic Cairngorm pattern, but rethink the pieces.

    The Front Router

    The most significant change so far is a FrontRouter mxml class. This let’s you map events to routes. Routes consists of one or more commands.

    Not only does this fix the messy state of Cairngorm’s SequenceCommand, but it adds the ability to set properties on commands before they execute. This makes the commands a lot more portable. You can use the same command multiple times with different models to push the results into.

    Added bonus: multiple events can trigger a single command. The view layer doesn’t need to know about this. 😛

    Name-wired Dependency Injection Defaults

    Okay. I need a more catchy name for this feature. Here’s the deal: injecting an instance of a model into views and commands is the best practice… better than locking the code into a singleton (Cairngorm) or even singleton factory (our current system). But it’s annoying to specify for “fooView” that you want “fooModel”. So, Kashi figures it out for you. If you have an instance named “fooView” it will automatically look for a model instance named “fooModel”. Also, if a route is named “fooStartupRoute” it’s commands will default to use “fooModel”. These are defaults, so you can always set them manually.

    I’ll post some concrete examples with code shortly.

    Advertisements

    PureMVC-like Notification Mediator in Cairngorm

    Caveat: My experience with PureMVC is limited to reading the excellent docs and a few blogs. Also, this post is total bait to get Ben Rimbey and Benjamin Corliss to blog a bit. 😛 

    So, PureMVC has a “Mediator” that sits between your UI and the View singleton. One of it’s jobs is too respond to PureMVC Notifications. Here’s what that looks like from the docs:

    override public function handleNotification( note : INotification ) : void {
     switch ( note.getName() ) {
      case ApplicationFacade.SEARCH_FAILED:
        controlBar.status = AppControlBar.STATUS_FAILED;
        controlBar.searchText.setFocus();
        break;  
    
     case ApplicationFacade.SEARCH_SUCCESS:
        controlBar.status = AppControlBar.STATUS_SUCCESS;
        break;  
    
      }
     }
    }

    So when you get a Notification with the name ApplicationFacade.SEARCH_FAILED or ApplicationFacade.SEARCH_SUCCESS it’s handled in the switch. I have a couple philosophical problems with this approach because the View should be a representation of the Model and the Model should maintain the state of the application. Adding the ability for the View or Control to talk directly to the View seems dangerous.

    I’m not saying Cairngorm is teh awesomes, but here’s an easy way to achieve the same affect and maintain the state in the Model. I’ll use a for-reals life example…

    In the mxml:

    <?xml version="1.0" encoding="utf-8"?>
    <behind:AutofixBehind
        xmlns:mx="http://www.adobe.com/2006/mxml"
        xmlns:behind="views.behind.*"
        xmlns:ui="views.components.*"
        backgroundColor="#ffffff"
        currentState="{ model.complete ? 'complete' : 'scanning' }"
        > 
    
        <!-- State changes are handled in the code behind -->
        <behind:states>
            <mx:State name="scanning" enterState="enterScanningState( event )" />
            <mx:State name="complete" enterState="enterCompleteState( event )" />
        </behind:states>
    ...

    Okay. So this particular example binds the state to model.complete, but you could just as easily bind it to model.currentScanState or whatever. Then the code-behind AutofixBehind.as has the enterScanningState and enterCompleteState handlers in it. Meh?

    The Swiz Framework

    The Swiz framework has some good ideas, there is no doubt about that. The mission statement “Swiz imposes no JEE patterns on your code, no repetitive folder layouts, and no boilerplate code on your development.” sounds like a direct reaction to Cairngorm.

    So first of all… “imposes no JEE patterns”, what’s a _bean_ loader? Are we talking about a soy bean? I suspect a bean that starts with a j, ends with ava. 😛 That’s cool though, because I like the looks of Swiz’s bean loader. (I’m guessing the JEE they are referring to is the locator pattern that Cairngorm uses.)

    Next on the list: “no repetitive folder layouts”. Well, crap. I actually don’t think this is a good idea. One thing I like about both Cairngorm and Ruby on Rails is that you always know where code should go… even 6 months down the road or jumping into someone else’s project. As far as repetitive goes, Flex is missing a tool as good as rake. There is nothing wrong with a well-structured set of directories.

    “… And no boilerplate code on your development”. Now we’re talking. 🙂

    However, I think much of Cairngorm’s boiler plate can be fixed by writing some bases classes. Delegates, for example, are the worst offenders. Often each one is loading some xml, sending it to a factory for parsing, and then returns a result or fault object. That could be easily fixed (and I’ll post the code for that in a future blog on my own Cairngorm-derived framework).

    I spotted one potential area of tight-coupling that I did not like. The autowiring metatags [Autowire(bean="foo")] hardwire a controller to a specific bean by id inside the controller. I think you could achieve a more reusable design by injecting the beans from outside of the controller.

    All in all, Swiz looks very promising with some innovative ideas– once the kinks are worked out.

    Mate Framework (an unfair review)

    My initial and totally unfair impression of the mate framework: meh.

    All ya gotta do is look at a sample “event map” to see that you have an unmanageable glob of xml code that is going to grow into a massive disorganized pile of poo.

    Even if the map was somehow trimmed down, organized and specialized– you gotta question whether a block like this:

    <resultHandlers>
        <!-- parse results into an array collection the photo coordinator can use -->             
        <MethodInvoker generator="{FlickrHelper}" method="parsePhotos" 
    arguments="{resultObject}" />                
        <!-- set the photos --> 
        <MethodInvoker generator="{PhotoCoordinator}" method="setUp" 
    arguments="{lastReturn}" />    
        <!-- start show --> 
        <MethodInvoker generator="{PhotoCoordinator}" method="start" />
    </resultHandlers>

    really is more readable than the same calls made in pure actionscript code. The fact that you need a comment over every line of xml code should be warning enough.

    Code Reviews

    Our teams haven’t instituted any formal process around code reviews. It’s more of an informal chat about code. I’ve been reading/skimming Practical C++ Programming (in preparation for C running in the AVM) and came across these metrics:

    • The number of lines reviewed
    • The time spent reviewing the code
    • The number of defects found
    • The defect density (defects per line of code) — computed
    • The review rate (# lines reviewed per hour) — computed

    So, on the one hand it’s nice to have these numbers. It helps you prove the idea to the business and also stay on task. On the other hand, the author (Steve Oualline) only is getting metrics against bugs. And this is intentional on his part. He wants to keep style and even architecture comments entirely out of the code review.

    I’m not sure I agree. I think some of the best feedback I have received have been design or style comments. Comments like “it’d be cool if that we had an interface class for that” or “why is that a singleton?” can really help improve the design of the code. What about adding this metric?:

    • The number of design suggestions implemented upon refactor