flashMVC

flashMVC is a minimalistic Flash and Flex framework that has an extensive range of scalability and easily adaptable with pre-built applications.

Current Status: stable (be sure to update often)
SVN Repository for Download: http://svn.jadbox.com/public/
Updated with new utility ActionBinder (more info).

Documentation (ASDocs) | Bugs & Feedback

The model-view-controller framework flashMVC is a system I constructed to quickly and efficiently build small to large scale applications and with the second requirement of easily re-factoring currently built classes into flashMVC without any major modifications. All of the development I have done on my own time since I would like to get the greater community feedback on this library. The two current mainstream MVC framework solutions out there are: cairngorm and pureMVC. However, the main problem with these solutions is that they usually require total application controller rewrites and also demands the user to define multiple layers of initialization code to just get to a “hello world” stage. In flashMVC, I aim the user to be able to setup a single test for all the MVC in about a half-dozen lines of code… while providing some very powerful functionality. The basic principle of this framework is that controllers (called actions) are registered to ‘SuperModel’ classes that act as a core model for a piece of an application’s feature set. The view would then tell SuperModel to perform an action and harvest the data that the action changes in the model.

flashMVC rundown:

  • Flash AS3 and Adobe Flex compatible… also allows moving applications built on flashMVC to be ported to Flash or Flex painlessly back-n-forth.
  • Add/replace whole sets of actions to your application without breaking views
  • ONE import statement for most cases
  • Lightweight (3 classes currently)
  • action classes do not extend or interface another class! The only change needed is to change the first parameter in your constructor function with “act:ActionHelper” and call act.complete() when the class did its job. (meaning I use composition rather than inheritance for hooking functionality into the framework which seems to make sense)
  • Uses the SuperModel classes that acts as a model and holds references to action classes that are associated with it. The view tells the model to execute functionality and waits to change its state when the SuperModel data gets updated.
  • Built in system logging and controller error handling
  • Provides a clean interface for Flash views to update (bind) to models and action statuses
  • SuperModels do not have to be singletons which would allow easier unit testing than cairngorm

Documentation: (ASDocs Here)

Files:

  • com.jadbox.flashmvc.SuperModel - Your model extends from this
  • com.jadbox.flashmvc.SuperModelEvent - Events that get dispatched on your SuperModel during model and controller changes.
  • com.jadbox.flashmvc.ActionHelper - The object that gets passed into your controller constructor for talking to the framework.
  • /flex projects/flashMVC examples/simpleApp/ - simple working example used for testing and development

Language example:

// SuperModel:
  1. public var data:int; // for example
  2. public const LOGIN:String = "Login";
  3. public function myConstuctor():void {
  4.  addAction(Login); // Login is your controller class reference
  5. }
  6.  
  7. // Controller class Login:
  8. public function Login(act:ActionHelper, param1, param2, etc) {
  9.  // Do the logic of an application inside
  10.  // this class and call the below line when done.
  11.  act.complete();
  12. }
  13.  
  14. // View:
  15. mySuperModel.gi.perform("Login", onComplete, …data);
  16. // or
  17. mySuperModel.gi.perform(SuperGallery.LOGIN, onComplete, param1, param2, etc);
  18. function onComplete(e:*):void {
  19.  // update view here
  20. }

Benefits:

  • Make functionality/actions easily portable from project to project
  • Spend less time thinking how the application should be put together
  • Consistent way the view uses actions… meaning less time to figure out other people’s code

Best practices:

  • Add action classes to a SuperModel from inside the SuperModel (optional, but it keeps complexity down)
  • Keep action constructor parameters short, concise, and strongly typed
  • If the SuperModel is holding more than a dozen variables, it means your SuperModel is trying to handle too much information about the state of the application and should be broken into smaller SuperModels. For example, instead of MainSuperModel, have like WindowModel and StylingModel.
  • Action classes should only do one solid defined action in the application and nothing more (mmm, clean!)
  • Avoid using the callback function in the SuperModel.perform method and instead add an event listener for SuperModelEvent.ACTION_COMPLETE. This will modularize your application more.
  • More to come

Copyright (c) 2008 Jonathan Dunlap, http://www.jadbox.com,
licensed under MIT

Bug submission and suggestions