Deja-vue.net

ActionStep (plugin View) / Pixlib (MVC FrontController + Remoting) SUSHI Service

Written on 2006-05-25 – 10:06 am | by Mike |

The Chief Cook is back ^^. On the menu: Sushis and MVC "on steroids".

Whisk your application with MVC until it peaks form. When your MVC is stiff enough, stuff it with a FrontController. Sprinkle with some MovieClipHelpers. Finally, depending on mood and preferences, baste with a ModelLocator and/ or a ServiceLocator...

Pixlib Remoting SUSHI service ? I hear some people saying: you creatively recycle dude....

In this article I will introduce you to a jewel of Pixlib (there are so many... it' s an Ali Baba's cavern !).
SUSHI service was made up following an extremely powerful and polyvalent application receipe based on the MVC pattern. "Receipe" because it's all about ingredients. According to the ingredients and the inspiration we can, for example, pump up a traditional MVC until reaching a multiple Models' one (ModelLocator) or like in our case, make the whole thing rise up to a "Super MVC" (FrontController and ServiceLocator).

sushisService.zip (88)

- The User Interface

It's ActionStep (I wish I could test ASWing but no time):
This time, the "forms" or "states" are bundled into an external swf loaded at runtime. Opting for this design supposed a new UI instantiation strategy.

- A system that is totally generic

The addition of the FrontController, MovieClipHelpers and ModelLocator (classe core.Model) to the MVC architecture gives our application an examplary level of modularity. The essential of this article will focus on the description of this "Super MVC". I will look at the aspects that, from my point of view, are the more relevants.

- The Remoting service

Based on an alpha version of the Pixlib remoting package. He is gracefully deployed from a Singleton ServiceLocator.

------------------------------------------------------------------------------------------------------

Note:
The "state" word refers here to the differents views contained into views.swf. You shouldn' t take it on the strict sense of the word (meaning the "state of an application" generally stored into a SharedObject, ValueObject, memento instance or other techniques).

Let's take our marks in images:

The project structure

Sushi service flp

(Homemade) diagram of the relationships between FrontController, MovieClipHelper, ServiceLocator & ModelLocator

Sushi Diagram

------------------------------------------------------------------------------------------------------

A standalone UI

Dissociated from their previous host (ARP), the differents "states" (order, viewOrders and navigation) inherit once again from MovieClip and are stripped from all event dispatching capabilities.

Conceiving the UI as a "Plug-and-Play" candidate implied to change the way the "states" container initialize. Imported at runtime into a MovieClip (via GraphicLib), the view then, should already come instantiated without any reference to _root.

The trick ? package the classes and place the view on stage using Swfmill

First step: compile the classes

/**
* @mtasc -version 8 -swf "classes.swf" -header 390:270:60:FCFCFC -trust
*/

// Imports...

class org.actionstep.view.sushi.Application extends MovieClip
{
// MovieClip linkage
static var id = (id="__Packages.org.actionstep.view.sushi.Application")+(Object.registerClass(id,Application)?"":"");

private var navigation : MovieClip;
private var order : MovieClip;
private var viewOrders : MovieClip;
private var dataPreloader : MovieClip;

function onLoad()
{
// ActionStep theming
org.actionstep.ASTheme.setCurrent(new
org.actionstep.themes.plastic.ASPlasticTheme());

// Set the initial display state of the application
setInitialDisplayState();

// Views Instantiation (no FLA here)
navigation = attachMovie(Navigation.id,"navigation", 1);
viewOrders = attachMovie(ViewOrders.id,"viewOrders", 2);
order = attachMovie(Order.id,"order", 3);
}
// ...
}

Second: instantiate the Application

<?xml version="1.0" encoding="iso-8859-1"?>
<movie version="8" width="390" height="270" framerate="60">
<background color="#ffffff"/>
<frame>
<library>
<clip id="Application" class="org.actionstep.view.sushi.Application" import="classes/classes.swf" />
</library>
<place id="Application" name="app" x="0" y="0" depth="1" />
</frame>
</movie>

-----------------------------------------------------------------------------------------------------

The MVC initialization

The main application (Application.as) is launch as usual with a static main().
The Model is instantiated first. Our unique view, a MovieClipHelper subclass, register to the Model. The controller, a Singleton and FrontController subclass is then initialized. The controller is the backbone of the application. He has the responsability to associate typed events and commands.

private function _init() : Void
{
var model : Model = new SUSHIExpert();
model.addListener( new SUSHIListUI() );
Controller.getInstance().init();
}

I. THE VIEW

Loading of the view

Using GraphicLib (unit-preloading) or Libstack (mass-preloading), 2 concrete implementations of AbstractLib, the loaded views are automatically pushed onto a stack. We later retrieve/ handle each item through a corresponding string identifier. Here, the identifiers are defined as constants (static variables) of the sushi.uis.UIList class. This way we enforce a better tracking of the coupling between the views and their 'accessors' .

var gl : GraphicLib = new GraphicLib( this, 20 );
gl.setName( UIList.SUSHI_List );
gl.addEventListener( GraphicLib.onLoadInitEVENT, this, _init );
gl.load( "deploy/views.swf" );

var libs = new LibStack();
libs.enqueue(new GraphicLib(this, 20, false), UIList.SUSHI_List, "deploy/views.swf");
libs.addEventListener( LibStack.onLoadCompleteEVENT, this, _init );
libs.execute();

Views are accessible globally in many ways:

- From the Singleton GraphicLibLocator:

var myView:MovieClip = GraphicLibLocator.getInstance().getGraphicLib( UIList.SUSHI_List ).getView();

- From a MovieClipHelper subclass:

// SUSHIListUI.as

class sushi.uis.SUSHIListUI
extends MovieClipHelper
{
public function SUSHIListUI ()
{
super( UIList.SUSHI_List );
}
}

- From a ViewHelper subclass

import com.bourre.data.libs.GraphicLib;
import com.bourre.visual.ViewHelper;
import sushi.uis.UIList;

class sushi.uis.SUSHIListUI
extends ViewHelper
{
public function SUSHIListUI ( gl : GraphicLib )
{
super( gl.getView(), UIList.SUSHI_List );

view.app.showDataPreloader();
gl.show();
}
}

Global access to the views is very handy. We can, for example, trigger a behavior from a Command:

Using GraphicLibLocator:

import com.bourre.data.libs.GraphicLibLocator
import sushi.uis.UIList;

class sushi.commands.PlaceOrder
implements Command
{
public function execute( e : IEvent ) : Void
{
var myView:MovieClip = GraphicLibLocator.getInstance().getGraphicLib( UIList.SUSHI_List ).getView();
myView.app.orderProcessed();
}
}

Using MovieClipHelper

import com.bourre.visual.MovieClipHelper
import sushi.uis.UIList;

class sushi.commands.PlaceOrder
implements Command
{
public function execute( e : IEvent ) : Void
{
var myView = MovieClipHelper.getMovieClipHelper(UIList.SUSHI_List);
myView.view.app.showDataPreloader();
myView.traceTest(); // calling a method on SUSHIListUI
}
}

In our case, Sushi service has only one View , a subclass of MovieClipHelper.

From a MovieClipHelper instance we typically:

- define the behavior of the objects (TextField, MovieClips, v2 components...) using their instance names.

In SUSHI service, the View is not an empty shell.

The external view comes with the following methods:

hideDataPreloader();
showDataPreloader();
orderFormSelect();
viewOrdersFormSelect();

Plus, in each "states" ( Navigation, Order, ViewOrders ), buttons eventHandlers are already defined:

// NSButton
placeOrderButton = (new NSButton()).initWithFrame(new NSRect(300, 205, 80, 22));
placeOrderButton.setStringValue("Place order");
placeOrderButton.setTarget(this);
placeOrderButton.setAction("placeOrder");
view.addSubview(placeOrderButton);

But we have nothing to be worried about ^^. We will manage all this (behaviors and scopes) from our MovieClipHelper subclass.

class sushi.uis.SUSHIListUI
extends MovieClipHelper
{
private function _initBehaviors() : Void
{
_pbCancelOrder.setTarget(this);
_pbCancelOrder.setAction("cancelOrder");

_dSelectViewOrders = new Delegate(view.app, view.app.viewOrdersFormSelect);
_dShowPreloader = new Delegate(view.app, view.app.showDataPreloader);
}

private function _gotoViewOrders() : Void
{
_dSelectViewOrders.execute();
_dShowPreloader.execute();
}

private function cancelOrder() : Void
{
_dShowPreloader.execute();
_fireEvent(new BasicEvent(EventList.cancelOrderEVENT, view.app.viewOrders.getOrder() ));
}
}

Thanks to this "LEGO Architecture" we have full control over each piece we plug.

From a MovieClipHelper instance we also typically:

- define the Model(s)' callbacks
- broadcast (with our global EventBroadcaster) BasicEvent events or custom events (BasicEvent subclasses) to the commands.

Don't hesitate to extend BasicEvent to make your own custom event objects. It's another cornerstone of Pixlib.

Take a look at the placeOrder() method. You will see how it broadcasts an OrderEvent object.

private function placeOrder() : Void
{
_gotoViewOrders();
_fireEvent(new OrderEvent(EventList.placeOrderEVENT, view.app.order.orderName, view.app.order.orderTicket));
}

Careful, the comparison is unfortunate, but it can helps ARP user to quickly catch the concept :
Think of OrderEvent as a Value Object (VO) that passes the informations to the command.
Okay, you can now cry out loud and clear "Sacrilege" ^^.

II. The FrontController

It's in sushi.commands.Controller (subclass of FrontController) that we associate Events and Commands. Unlike ARP' s ControllerTemplate, the FrontController do not oblige to a direct reference to the views. Less coupling!

FrontController:

public function init() : Void
{
push ( EventList.placeOrderEVENT, new PlaceOrder() );
push ( EventList.getOrdersEVENT, new GetOrders() );
push ( EventList.cancelOrderEVENT, new CancelOrder() );
}

ControllerTemplate:

private function addEventListeners ()
{
app.orderForm.addEventListener ( "orderPizza", this );
app.viewOrdersForm.addEventListener ( "getOrderList", this );
app.viewOrdersForm.addEventListener ( "cancelOrder", this );
}

private function addCommands ()
{
addCommand ( "orderPizzaCommand", OrderPizzaCommand );
addCommand ( "getOrderListCommand", GetOrderListCommand );
addCommand ( "cancelOrderCommand", CancelOrderCommand );
}

III. ServiceLocator and Commands

In the Singleton ServiceLocator we define and store one or multiples Remoting service(s) (according to the needs). The alias of each service name is a static variable.

- Remoting service definition

// sushi.service.ServiceLocator
public static var SUSHISERVICE:String = "dejavue_net.sushi.sushiService";
public function init( remotingURL : String ) : Void
{
gatewayURL = "http://www.deja-vue.net/amfphp/gateway.php";
push( ServiceLocator.SUSHISERVICE, ServiceLocator.SUSHISERVICE );
}

- Command configuration

1. Remoting service localization and remote calls.

At the time of writing, the remoting package is still an alpha release. So, I will not enter into the detail of the API.

// class sushi.commands.PlaceOrder

public function PlaceOrder()
{
_service = ServiceLocator.getInstance().getService( ServiceLocator.SUSHISERVICE );
}

public function execute( e : OrderEvent ) : Void
{
_service.order( new ServiceResponder(this), e.getName(), e.getTicket() );
}

public function onResult( e : BasicResultEvent ) : Void
{

}

public function onFault(e : BasicFaultEvent) : Void
{

}

2. All roads lead to Rome.

And it's here where this is HUGE. From a command (but not only) we can:

- play with any View (remember GraphicLibLocator, MovieClipHelper and ViewHelper).
- broadcast typed events and trigger other commands.

EventBroadcaster.getInstance().broadcastEvent( new BasicEvent(EventList.getOrdersEVENT) );

- call the model of our choice

SUSHIExpert(Model.getModel( ModelList.SUSHI_EXPERT )).onUpdate( e.getResult() );

It' s incredible all this control

Last Words (it is time! ^^):

2 days ago, I was obsessed with the idea to write something about the Pixlib's MVC package . At the same time I couldn't stop thinking it was something deadly boring (who except Scotty doesn't know about MVC ?). Digging deeper into the 'events' and 'visual' packages I came across with FrontController and MovieClipHelper. Pixlib didn't finish to amaze me !

Guess who's coming to cook my next project

Hats off to Francis.

ActionStep (plugin View) / Pixlib (MVC FrontController + Remoting) SUSHI Service

Related Posts

26 Responses to “ActionStep (plugin View) / Pixlib (MVC FrontController + Remoting) SUSHI Service”

1 Trackback(s)

Post a Comment

About

Language

Archives

Categories

Links

Meta

Recent Comments

Recent Post