Flashbelt, Robotlegs – JXLTV Episode #4






JXL TV Episode 4

Registration for Flashbelt, a Flash conference for the midwest, is open!  Also, a brief overview of Robotlegs, a new MVCS application framework.

Mentioned links:

Beers

10 thoughts on “Flashbelt, Robotlegs – JXLTV Episode #4”

  1. Great episode Jesse.
    I keep hearing good things about Robotlegs I’m gonna check it out this weekend.

    Here are some beers I really like:
    Yakima Twilight
    Starr Hill Pale Ale
    Dogfish Head 60 min IPA

  2. Great episode again. I’m not really using the MVCS reference quite yet, so it was helpful to hear some of the deeper inner workings as I plan to move closer to that implementation later.

    Left Coast’s Asylum Tripel Belgium FTW!

  3. Space cadet.. he he.

    You don’t happen to be looking for a flash developer job in Sweden, perchance? We’re in need of a cool guy!

  4. Cool info, I’ll look into Robotlegs.

    You should also try Fullers Honey Bee and Badger Golden Champion, if you can get hold of it.

  5. Jesse,
    Great breakdown for those curious to hear what all the hubub on robotlegs is about. You also nailed a bunch of the best practices that were too ambiguous in PureMVC. Two things. a.) I would love to have a blog off about Service pattern best practices, since that seems to be where I see most of the deviation in approach in applications ( Cairngromets use asynTokens in stateful commands, Flashkiddies use typed events, PureMVCers use proxies OR commands ) b.) I have seen some Really powerful implementations of the command pattern, complete with contextual undo/redo macros etc. and robotlegs seems to not have that fleshed out.

    again, Awesome

  6. Thanks Kristofer!

    Good idea about service layers… that’s definitely something I’d need to blog about since it has 4 distinct parts as well as multiple ways to integrate into the existing frameworks. Hopefully next week.

    Regarding Commands/Robotlegs… they have the same “if you have need of DRY, re-factor to a Command” that PureMVC had. Thus, they don’t play a central role like they did in Cairngorm AND aren’t capable of handling asynchronous events like Cairngorm did. They are really a helpful base class with DI & and the EventBus; everything else you’d need to build on top or borrow from another framework.

Comments are closed.