David,

I'm excited to hear you talking about building a game with this. I started out writing games back when dinosaurs (like the trash-80, vic-20 and apple ][ ) roamed the earth. Somehow I wandered astray over the years and found myself doing scads of business related stuff.

This is not going to turn into another ramble down memory lane (In my day I once had to write a word processor in ones and zeros. Ones AND zeros? why we would've killed to have em both! WE had to work on unary systems where we could only use ones OR zeros. Had to write a shuttle control system for NASA in nothing but ones!)

Seriously, I was just thinking it would be great to see a game driven by the same framework that can drive an enterprise application. Though there are certainly many challenges in the enterprise, I remember being far more challenged by game work, or perhaps it was just that the use cases were so different in terms of the real-time nature of anything beyond tic-tac-toe. And it would really show off the ubiquitous nature of PureMVC. When AS3 hits the phones bigtime, it'll be a blast, since game development will be a big driver.

Unfortunately at this moment, there are a lot of questions you open there that I wouldn't want to extemporaneously suggest solutions for without a little more thought. But I did want you to know I wasn't overlooking this topic.

I will toss out a few thoughts though, that might help guide in the short term.

You're spot on about needing to employ other patterns. It's all about how do they fit or interact with the over-arching MVC pattern. The Model, View and Controller axes define the core nature of the application and should not get lost in a wash of other pattern package branches that show up as siblings to model, view and controller.

The first thing you should ask yourself when integrating another pattern is whether you really need it or if you can do it without a stretch within the patterns already in the framework. Not that the current pattern set solves everything, but just make sure there's a good argument why its too much of a stretch for the existing system. As simple as possible, no simpler.

Secondly, if you need to add the new pattern, which wing of the MVC suite does it belong in. A good example of integrating a simple helper pattern is the use of Enums and VOs in the model package of the Architecture 101 demo. They are accessed at the view, but clearly should be defined in the model for the model to be portable.

Consider a bunch of bullets flying around on independent trajectories. There are also a bunch of stationary and or moving objects that may collide with each other or a bullet.

I think this can all be managed by the mediators of the sprites themselves.

The mediators listen for a notification sent by a Timer managed by a TimeProxy. The big clock at the center of the universe. (Why a proxy? You might want to ask it the time. That's data, transient as it may be. This will be useful in the enterprise where we might want to add some date math helper methods as well.)

So, each sprite mediator, upon hearing the TIMER_TICK notification sent by the TimeProxy, advances its sprite and then sends a SPRITE_MOVED notification, with the sprite in question as the body.

All interested sprite mediators, handle the SPRITE_MOVED notification by doing a hitTest call on their sprite to see if there is a collision. ( (mySpriteInstance.hitTest(notification.getBody() as MySprite) )

Then its a rock / paper scissors game. If its a tank who's just heard that an anti-tank missile has collided with it, then the TankMediator instance will remove the event listeners from its view component, set the viewComponent property to null, and then call facade.removeMediator(this.getMediatorName()), freeing up the memory from the tank sprite and its mediator for the GC.

The TankMediator might send a TANK_EXPLODES notification, which fires a TankExplodesCommmand that plays a sound and bumps the score by a thousand by retrieving the ScoreProxy and doing scoreProxy.score+=1000.

Of course the ScoreProxy class's score property would actually be an implicit getter/setter pair. The setter would add the incoming value to the score and check to see if you crossed a level where you get a new weapon, more ammo, an extra man, etc.

You might have to have the StageMediator listen for keystrokes and mouse events from the stage, and send corresponding notifications. In the case of a FIRE event you might send a USER_FIRES notification which causes a bullet to appear at a given Point with a given vector.

Woops, I thought I'd decided to go off and think about this first. Hmm. Ok, well, it's really late, but I do believe this makes sense. Enough for you to get started with. I'll rejoin this discussion soon. Please keep us all updated on what you find.

-=Cliff>

Beautiful demo!   The link says CairngormLoginExampleWebORB.zip instead of PureMVCLoginExampleWebORB.zip but the contehts are correct.

-=Cliff>

You can handle this with the AsyncToken pattern.

Whenever you make a service call in Flex, you get back an AsyncToken object. This is a dynamic class that you can add properties to. When the service returns, this token will be available on the ResultEvent or FaultEvent as the property event.token.

So the Proxy (or Delegate) sets a property on the Token when the call is made. When the service returns, the Proxy sends the notification name that is stored in the token.

Instead of calling nextCommand() you set a property on the Proxy, which is an implicit setter, with the name of the notification to send if the user is authenticated. If the authentication hasn't happened yet, then it takes place, and the continuation of the use case is accomplished by sending the notification that was specified to the proxy earlier.

This methodology is more compatible with the PureMVC gestalt because the controller region doesn't don't talk to services, the model does.

The idea is that we want to present the data model to the rest of the application as if it were always present, and further, that it maintains its own integrity. The Proxy pattern achieves this and has the responsibility of hiding the fact that data may not in fact be present, and that requests for data that isn't there may involve remote service calls. Authentication is just another part of the model. Credentials are set, and if correct, the model should respect your requests for data, otherwise it may send notifications indicating that the credentials are not valid.

Of course we know that some use cases against the model are going to be async and some sync.

If the use case is async, we set a property or call a method on a Proxy, then the use-case is continued when the Proxy sends a notification, either predetermined by the proxy, or one we tell it to send when it's ready.

If it's synchronous, then we just set and get.

The nice thing about the async use case being continued by a notification is that multiple mediators often listen for the same notification, allowing them to do their own state management in response, rather than concentrating knowledge in a Command. This makes the view more reusable. It also leads to less state representation needing to be done on the model.

But never do we concern ourselves (in the controller and view regions) about services. This is fully a part of the model region in this implementation of MVC. Delegates may be used but by Proxies, not Commands. Thus, though the idea of an asynchronous command chain may make sense in another framework, it doesn't really fit here.

However, there is a quantifiable upside to this implementation, and that is that the model becomes portable. In the upcoming courseware there is a concrete example of this, where we share the same model package between two separate applications. Thus the model (and its communication with services) needs to be as much of a black box as possible. The job of Commands and Mediators then is merely to implement a unique view and carry out different use cases against a common model.

-=Cliff>

Tom,

You might want to have a gander at this thread ('first project with PureMVC') http://forums.puremvc.org/index.php?topic=21.0 over in the General Discussion board.

Daniele Ugoletti posted an ApplicationSkeleton app that you can use to get started with. He used the FlashDevelop project template as well.

-=Cliff>

Tom,

For an example of persistent data storage with PureMVC, have a look at the CodePeek application. It's an Adobe AIR app that persists multiple XML databases to the filesystem to store your window metrics and your saved searches by language type. It also talks to a remote service (Google Code) in the same asynchronous manner that you would if you were persisting data remotely using Flex in a browser.

Also, in a tantalizingly short time now, I'll be opening the courseware beta program. I'm working on the signup wizard at the moment.

Stay tuned,
-=Cliff>

Seb,

Good to hear it's been going well for you.

Sounds like you've got a good workflow going there. I wonder if you might have time to document it in a separate post that would possibly guide new Flash programmers coming to PureMVC. There are a lot of ways to do things, but if you've found one that you feel you can really be productive with, I'm sure others would really appreciate it.

-=Cliff>

Sarvanan,

To the View States or ViewStack question, I would suggest the latter. You could dynamically create and add the children (wizard pages) based upon some configuration. Of course it could be done with view states, but they'd all need to be defined in MXML ahead of time.

In PureMVC, the Model is merely a Singleton that caches Proxies. so your question is more likely 'one Proxy or many'? That will depend on how generic or specific your case is. Being something of an Architecture Astronaut (a derogatory term in some circles, yes), I have a tendency to push things toward the former end of the gradient.

If the wizard collects wildly varying data types from many sources dynamically at runtime, then more than likely the answer is many.

If the wizard collects master/detail type data, (imagine a resume wizard, stepping through the sections, sometimes allowing you to loop,  over adding employers for instance) then the answer is probably still several.

In the resume example, you might have a ResumeProxy that contains the master info, then an Employer proxy that contains a single job history entry, perhaps a ReferencesProxy that collects all your references.

The ResumeProxy would have the ability to communicate with the remote service and save the resume, gathering up the data from the other Proxies as needed in the process.

If the wizard is very simple, like an installation wizard that needs to collect a few things like where to install, what parts not to install, whether to add a desktop icon, etc; then its possible view states and a single Proxy would work perfectly fine.

Hope this helps,
-=Cliff>

Seb,

Didn't forget about you. Or the other hundred gajillion Flashers out there in need of a AS3 framework. HelloFlash is here. I'll get more detailed info about how it works up there, but for now it's all internally documented and shouldn't be terribly hard to follow.

Be sure to check out the detailed instructions on the PureMVC download page for setting up with Flash. Then getting the demo up in the Flash IDE is a breeze.

-=Cliff>

Steve,

Don't hurt the springy thingy, its frail and only made of bits. 

In practical terms, first steps to getting a logging system would in my mind, be to get a handle on the Notification traffic.

That would best be done by overriding the notifyObservers method in your ApplicationFacade. It would {do something} then call super with the  Notification, so that everything continues as normal.

What that {do something} part is can be whatever.

It could be that you add a timestamped log entry to a logging proxy, which could in turn log client side activity to a server side resource. 

It could be you send another Notification that is picked up by a Mediator which dumps the data into a View Component that displays Notification traffic. This wouldn't start an infinite loop, because the ApplicationFacade would not use its own notifiyObservers method to send the logging notification, it would use the View's.

By routing everything through the Facade, not only do we essentially collapse the Model View and Controller into a single actor from the developers point of view, but we have a handy place to intercept traffic.

-=Cliff>

If you have a phone with broadband Internet access, and want to view these forums on the go, simply browse to http://forums.puremvc.org

The mobile browser should be detected and you'll get a really nice experience on handheld. Works great on my Blackberry 8830.

-=Cliff>

Daniele,

Have a good time on vacation. I vaguely recall what that's like

-=Cliff>

Daniele,

Sorry, I mistook your #1 in the previous post. Each instance of the reusable component needs its own Mediator instance. Not a separate class.

And with #2, if multiple classes need an assocated popup, you can create an AbstractPopupMediator (extends Mediator) that handles popup management. Then each concrete Mediator that needs to also have a popup can inherit from AbstractPopupMediator.

-=Cliff>

Steve,

I have been low-level processing this idea for a while now.

My idea includes an an 'intercepting facade' that overrides the notifyObservers method and tee's off a stream of info about notifications sent to a logging facility. It might also include regexp crunching of the source code as well.

Ultimately, it ought to analyze everything and spit out something like this:
http://puremvc.org/pages/demos/codepeek/AppGraph.swf

...that shows the layout of your app (note, double click to drill into the model and further into the proxies...).

Further, each node would also when clicked on show you all the notifications it listens for (if a Mediator or Command), those it sends, and link or display to the source code.

Of course this is all add-on tools and packages to come, and not new features for the framework itself.

-=Cliff>

Good summation, Daniele.

That's essentially it. And I will make sure in the courseware to illustrate these cases as well.

Thanks,
-=Clliff>

Daniele,

It is not a good idea to have the View Component create or even know about its Mediator. This makes it less portable, and ties it to the PureMVC implementation. Ideally, View Components should know nothing about the PureMVC system and communicate with it solely by exposing an API consisting of Events and public properties.

In order to closely coordinate a transient popup with a View Component, a good solution is to have the Mediator fully manage the existence of the popup.

In your example, MainScreen.mxml should send an Event instead of the creating the popup.

Then the MainScreenMediator should create the Popup and keep a reference to it in a separate instance property, (i.e. private var popup:MyWindow).

When it creates the popup, it should listen for Events from the popup as well, such as MyWindow.CLOSE, which would be sent by MyWindow when the 'Close' button is clicked. The Mediator would respond to by destroying the popup.

There would likely be other Events that the popup would send as well, such as MyWindow.ADD, or MyWindow.UPDATE, sent when the user clicks an 'Add' or 'Update' button. The Mediator would respond to these by taking the data exposed by the popup (or sent in a custom event), perhaps sending a Notification that triggers a Command to update the model, and finally, closing the popup.

There could be a separate Mediator for this popup if its used in multiple places, but if it's tied to interaction with this one View Component, it makes sense to have the Mediator do double duty of managing its primary View Component as well as its associated popup.

In any case, the transient component should be created, listened to, and destroyed by a Mediator.

-=Cliff>