AaronHardy.com » nimbus

Nimbus – Macro Commands

Aaron Hardy — Thu, 30 Apr 2009 01:53:17 +0000

UPDATE: Since the writing of this post, I’ve converted to and fully endorse Robotlegs as my MVC framework of choice. I invite you to check it out. I have likewise since converted the concept of macro commands to Robotlegs in a extension called Macrobot.

In my recent intro to Nimbus, I mentioned that one of the features of Nimbus is macro commands. In complex applications, macro commands can be a huge time saver and allow you to have a lot of control over handling a group of service calls with minimal code.

Two types of macro commands exist. The first is a SequenceCommand. This means its subcommands will be executed sequentially. In other words, the second subcommand won’t begin executing until the first subcommand has finished executing. The SequenceCommand won’t be considered complete until the last subcommand has finished executing.

The other type of macro command is a ParallelCommand. As you may have guessed, this means its subcommands will be executed in parallel. In other words, the first command and second command will execute at the same time. The ParallelCommand won’t be considered complete until all subcommands have finished executing.

Just as the synergy of the Planeteers can work miracles, so can the synergy of the SequenceCommand and ParallelCommand. Nesting macro commands can give some enhanced control as we’ll see here:

package controller
{
	import nimbus.commands.ParallelCommand;
	import nimbus.commands.SequenceCommand;
 
	public class MyMacroCommand extends SequenceCommand
	{
		public function MyMacroCommand()
		{
			this.subcommands = [
					new CommandA(),
					new ParallelCommand(
							[
							new CommandB(),
							new CommandC()
							]),
					new CommandD(),
					new ParallelCommand(
							[
							new CommandE(),
							new SequenceCommand(
									[
									new CommandF(),
									new CommandG()
									]),
							new CommandH(),
							new CommandI()
							]),
					new CommandJ()
					];
		}
	}
}

It’s probably easier to see what’s going on just by looking at the code, but here it is in narrative form:

CommandA executes. CommandA completes. CommandB and CommandC execute. Both of them complete in whatever order. CommandD executes. CommandD completes. CommandE, CommandH, and CommandI execute. While they’re executing, CommandF executes, CommandF completes, CommandG executes, and CommandG completes. After CommandE, CommandH, CommandI, CommandF, and commandG all complete, CommandJ executes and then completes.

Note that these subcommands could also be macro commands of their own. For example, CommandH could be extending ParallelCommand and executing several subcommands within itself. Macro commands can be a very powerful tool when managing the order and timing of your application’s processes. Bon appetit!

Nimbus – MVC Framework Intro

Aaron Hardy — Sat, 25 Apr 2009 22:51:45 +0000

UPDATE: Since the writing of this post, I’ve converted to and fully endorse Robotlegs as my MVC framework of choice. I invite you to check it out.

For those who don’t know, Nimbus is a Flex MVC framework (or micro-architecture for the technically-inclined). Sponsored by Rain, we develop it primarily for use on our applications but make it available for public use and encourage the community to contribute.

Nimbus pulls core concepts from Cairngorm but is meant to cut out a lot of the plumbing developers groan about when they hear “Cairngorm.” It’s light, but it’s not fluffy. Baked in are those rare and tasty flavor morsels you thought only existed in those Funfetti cupcakes your grandmother bakes with love on your birthday.

Until the end of 2008, Nimbus had been shaped, re-shaped, patched, and plugged. A complete re-write was merited so that’s what we did. And really, what makes for a better Christmas than sitting down with your stocking stuffed with jelly beans and re-writing an MVC framework. A few months later, the code is settling down along with the sugar and we’re ready for action.

Here are some features of Nimbus:

Notification system of command completion so portions of the application can know when a command has finished executing.
Nestable “macro” commands. Think “I want commands A and B to run in parallel, then C, then D and E in parallel, but inside D I want F and G to run sequentially…”
Undo/Redo functionality.
Progress feedback system. You as a developer can associate a processing message with each command or macro command to provide feedback to users.
Interaction blocking system. While commands are executing, easily disable user interaction to protect your service calls.
Combinable commands. Ensure that similar command instances can be grouped appropriately in the undo/redo history.

Nimbus may not be right for everyone. Call your system administrator if your scalability problem worsens or is not better within 7 to 10 days. This may mean that there is another condition causing your RTE problems. Do not take Nimbus with alcohol. Call your system administrator right away if after taking Nimbus you are unable to walk, drive, eat, or engage in other activities. In rare cases, severe allergic reactions can occur. Most MVC frameworks carry some risk of dependency. Do not use MVC frameworks for extended periods without first talking to your system administrator. You are encouraged to report negative side effects of Nimbus. Visit http://code.google.com/p/nimbus-as3 for more information.

The best Flex MVC framework

Aaron Hardy — Mon, 01 Sep 2008 02:26:32 +0000

UPDATE: Since the writing of this post, I’ve converted to and fully endorse Robotlegs as my MVC framework of choice. I invite you to check it out. Even so, the content of this post still remains relevant.

There isn’t one. At least not for everyone. That’s the bottom line and hours of googling won’t change it. I’ll explain what I mean–but first, here’s a real intro:

If you’re not acquainted with what MVC is and are interested in learning more, I’d recommend starting off with Wikipedia’s Model-view-controller entry. Simply put, MVC is a pattern of keeping portions of code where they belong, especially when it comes to code dealing with the model (data), view (user interface), and controller (operations/communication). While MVC can simply be a development process or how a developer thinks while creating an application, communities of developers have often formed frameworks, or basic code structures, whereon a developer can base his/her code when creating an application. They’re not always necessary, but many developers have favored frameworks because they help enforce good coding practices, eliminate “boiler-plate code” (repetitive code needed in each application), and create standards whereby developers can easily catch up to speed when joining a new, unfamiliar project.

With Flex, it seems there are more MVC architectures than there are developers. There are plenty to choose from and their implementation can vary widely. With so many frameworks, the inevitable question seems to always pop up: Which is the best one? To truly find an answer, you have to consider who’s asking the question.

For a great illustration of this point, take a look at Cairngorm, the most widely-used Flex MVC framework. It’s supported by Adobe so many developers naturally gravitate toward it. It also uses, by most accounts, great programming principles. By great principles I mean the ones you might learn in a programming theory computer science course. And just as you might expect for feedback from students in a programming theory course, you can expect similar responses from developers who use Cairngorm. Most of the time, such developers appreciate the fact that such a framework exists and that it promotes good coding principles. However, if you ask them if they actually enjoy developing with Cairngorm, you’ll usually hear a an animate “no.” Why? Because theory does not always mean practicality or productivity. This is even more true when dealing with projects of varying complexity, timeframe, maintenance, and team size.

The most often-heard complaint about Cairngorm is that it requires too much code duplication. For most development teams (including my own,) this is certainly true. The various layers, from the Cairngorm events, to the controller, to the commands, to the delegate, require a lot of code duplication for little gain…for us. For those with large systems, heterogenous backend services, high employee turnover, long-term maintenance, or other such attributes (what Adobe consultants might be dealing with,) such a framework may be exactly the ticket. When it comes down to it, your choice of MVC framework should come down to what drives your bottom line, not what others consider to be good theory or what works for them.

Because of this disparity in needs vs. fulfillment, each MVC framework is going to have a bucketload of both good reviews and bad reviews. Some frameworks may be better than others at solving problems for the greatest number of developers. In such a case, ask yourself if a good generic solution is really better than a not-as-good customized solution. What may be “not-as-good” for others may be exactly what you need.

Many other questions can help pinpoint what you’re really looking for in a framework. Does one framework have a strong following that will fix bugs and implement functionality when needed? How much is this development community worth? Is the framework too heavy for your application’s simple needs? Can your application really take advantage of a large number of code layers or does it make sense to cut out the plumbing? How difficult will it be for new hires to grasp the application’s architecture? Are you handing the application off to a team that’s acquainted with a specific framework? Are your developers skilled enough to recognize when they’re writing spaghetti code or do they need strong guidance and tight restrictions from the get-go?

To sum up and repeat what I’ve said before, there is no best Flex MVC framework. First determine what your development team really needs and then find the framework that best fulfills those needs.

So you may be wondering what my team over at Rain chose for our MVC needs. After researching and evaluating Cairngorm, PureMVC, Mate, Guasax, and Fake, amongst others, we decided to go with a solution built in-house and customized for our needs. It’s based off Cairngorm with a couple layers cut out as well as a few features tossed in (such as undoable commands.) Good luck on your quest to find “the best” Flex MVC framework!