November 2008 Archives

Some colleagues and I are drifting (I mean "striding resolutely") into the tail-end of a project involving considerable amounts of Flex code. This has led us to look back and try to map the best approach for upcoming Flex-centred projects (aka "Impending Doom"). Part of that discussion has involved punting around the need for and benefits of using an MVC framework with Flex. We've talked about scale and complexity as a driver, as well as client preferences and timelines... no definitive answer has been found, as of yet.

In the middle of all this, I came across this article, "MVC As Anti-Pattern" by Brian Lesser of Ryerson (a fine learning establishment that has escalators, for crying out loud!). As University Types are wont to do, he mentions Smalltalk a lot. If you can overlook that fact, however, you'll find that Brian's points are quite well put (even if you disagree).

(In honour of University Types everywhere, I will now endeavour to use as much Latin as I can in a single paragraph.)

My inadequate summary: the author plants the seeds of doubt as to the usefulness of formal MVC in Flex RIAs given that the Flex framework itself provides in situ constructs that cover most of what a controller does (ex generis: data binding, validation, program flow control). In the end, Flex lends itself better to "MV" -- id est: split out the Model and View, with the Controller implied but not really a concrete entity.

If you to are pondering the benefits of using MVC in designing your next Flex app, then please read this article and click through to the "References" links he includes. I welcome any opinions you'd like to voice on the matter, since I'm still in the middle of forming an opinion on the issue.

One thing about code is that it follows an asymptotic path... it's never quite where you want it to be. Because of that, developers often like to add comments to their code describing the level of completeness, dropping notes of what still needs to be done or fixed, leaving breadcrumbs on the point to which they'd like to eventually bring the code.

Over the past few years, I've been using the Eclipse's built-in TODO and FIXME comment plug-in for Java and with the move to Flex, wanted one for FlexBuilder (none is built-in). Well, the search is over, I've found one and it works great.

Dirk Eismann from richinternet.blog has come up with a fully-functional version of the plug-in that you can get here. It will add icons in the margin of your source files and coloured indicators in the vertical scroll bar, allowing you to quickly jump to your TODOs. It also provides a "Tasks" tab that will list the TODO/FIXME items, allowing you to check them off as you complete them. (The tab that can be used to view all TODOs can be added to your Flex perspective by going to Window > Other Views > General > Tasks)

To add a TODO or FIXME to your Flex source code, just put a double-slash style comment (JavaDoc style not supported), followed by the keyword and a message.

e.g.:

// TODO: TB - Have lunch and get a raise.

or

// FIXME: TB - I've fallen and I can't get up.

You might notice that when working in a team, I've gotten into the habit of putting my initials next to any TODO I add. If anything, it tells the person who eventually cleans up your mess who to blame.

Now how's that for team-work!?

This is interesting.

Over at Adobe Developer Connection, they've put together a Flex app that provides access to the bulk of Adobe's in-house Flex/Air training materials -- i.e. the Flex Learning Path (tm). The resources available include all kinds of tutorial videos, walkthroughs, example apps and web pages... including your daily dose of Adobe buzzwords and marketing happy talk thrown in.

They've broken it down by subject are and have created different streams for designers, programmers, architects and managers. It doesn't remember what you've already visited, so keep notes, because there are a lot of materials to go over.

Check it out here.