Keeping track of data associated with display objects

[toadrage]

Hi there,
I'm a first time board poster and currently working on my first project using PureMVC!  It's slightly intimidating but I'm taking it slowly so I don't accidentally use any of my non-PureMVC based habits.

Anyways, I have a couple of questions if you can spare a moment...

Basically, I have a Papervision3D scene (called WallScene)...

:

package view
{
import org.papervision3d.cameras.CameraType;
import org.papervision3d.objects.DisplayObject3D;
import org.papervision3d.view.BasicView;

import flash.events.Event;

/**
* @author davidfox
*/
public class WallScene extends BasicView
{

private var _cameraPoint : DisplayObject3D;
private var _cubes : Array;

public function WallScene()
{
super( 900, 700, true, false, CameraType.DEBUG);
camera.focus= 300;
camera.zoom= 10;
camera.z= -3000;
startRendering();

_cameraPoint = new DisplayObject3D();
_cameraPoint.z = -1000;
}

public function init(cubes : Array) : void
{
_cubes = new Array();
for (var i : int = 0; i < 8; i++)
{
var thisCube : WallCube = new WallCube(cubes[0]);
thisCube.x = i * 110 - (3.5 * 110);
thisCube.lookAt(_cameraPoint);
scene.addChild(thisCube);
_cubes.push(thisCube);
}
}

override protected function onRenderTick( e : Event = null ):void
{
_cameraPoint.x = camera.x;
_cameraPoint.y = camera.y;
_cameraPoint.z = camera.z;
for (var i : int = 0; i < _cubes.length; i++)
{
_cubes[i].lookAt(_cameraPoint);
}
super.onRenderTick( e );
}
}
}

Now most of this is just using test data.  What I want to concentrate on is where I'm adding instances of WallCube.as.  As far as I understand, I shouldn't be accessing (even if I CAN!) the facade or any proxies inside the above class.  So, I created a Mediator...

:

package view
{
import org.puremvc.as3.multicore.interfaces.INotification;
import org.puremvc.as3.multicore.patterns.mediator.Mediator;

public class WallSceneMediator extends Mediator
{
public static const NAME : String = "WallSceneMediator";

public function WallSceneMediator(viewComponent : Object = null)
{
super(WallSceneMediator.NAME, viewComponent);
}

override public function listNotificationInterests() : Array
{
return [ApplicationFacade.CREATE_CUBES];
}

override public function handleNotification(note : INotification) : void
{
switch( note.getName() )
{
case ApplicationFacade.CREATE_CUBES :
wallScene.init(note.getBody() as Array);
break;
default :
break;
}
}

public function get wallScene() : WallScene
{
return viewComponent as WallScene;
}
}
}
Now during my startup, when I've finished collating my data, I do a sendNotification(ApplicationFacade.CREATE_CUBES, arrayOfCubeVOs).

How am I doing so far?

Anyways, WallCube simply extends the Cube Papervision primitive. 

Now, here's the question... I'm going to want to store data about each of these cubes and they'll have to be able to find out/accept information about each other.  For example, clicking on one will make another one spin etc.

I was thinking of creating a proxy to store an array of WallCube instances but where would I do that?  The cubes themselves are created in the WallScene class and surely it shouldn't be accessing the facade to start storing proxies...

If you made it this far, thanks so much for taking the time to read!  Any help you could give would be brilliant.  I'm just starting out but am seeing the advantages of PureMVC already!

[puremvc]

Looks good so far. I wouldn't store WallCube instances in a Proxy, but rather the data for those cubes, and event that may not be necessary, if you're only storing it as a way to have them communicate.

If the cubes need to communicate, then give them each a uniquely named Mediator. See the HelloFlash demo for the idea of multiple visual objects all having unique instances of the same Mediator. Moving the scrollwheel sends a note where all the mediators for the little HelloSprites tell their sprites to scale up or down.

HelloSprites don't talk to each other, but if one cube needs to talk to another, it just needs to know its name. The mediator can then contact the other cube's mediator by retrieving it and invoking a method, or by sending a note that it is interested in (hint, put the mediator name in the type property and have the listening mediator make sure that this note is bound for it by comparing its name to the type property of the note).

-=Cliff>

[toadrage]

Ahaaaa...  I see.  Ok so I'm going to go down the uniquely named mediators route.  However, where should I create those mediators?  I'm actually instantiating my WallCube's inside WallScene which doesn't have access to the facade.  Can I somehow retrieve it inside there?  Is that a correct way of doing things?  If so, maybe I can create the mediator inside the actual WallCube class.  If not, do I have to start creating the cubes inside WallScene's mediator?  I thought that making the cubes would have to take place inside WallScene as it's part of building the view...

[toadrage]

Also, one other thing about how easy it is to share projects with other developers using PureMVC...

Imagine we have a notification being sent from somewhere but it HASN'T had a command created for it (which appears to be normal practice looking at HelloSprite) but we are just listening for that notification in a mediator... How is it possible to keep track of who's listening for what?

If I take on a huge project from somebody else and some action is happening based upon a notification being sent, surely it would be difficult to track down the individual classes and their mediators who are actually acting upon them.

Is it just a matter of "name your display objects and their mediators well so by looking at the app in action, you can see what is changing and then track down the DO's class"?

[Jason MacDonald]

If you are using Flex you can use the PMVC Console

[toadrage]

If you are using Flex you can use the PMVC Console

Whao, that looks amazing!  Unfortunately I'm not using Flex though.  Just Eclipse with the FDT plugin

[puremvc]

Ok so I'm going to go down the uniquely named mediators route.  However, where should I create those Mediators?  I'm actually instantiating my WallCube's inside WallScene which doesn't have access to the facade.  Can I somehow retrieve it inside there?  Is that a correct way of doing things?  If so, maybe I can create the mediator inside the actual WallCube class.

Don't create the Mediator inside the WallCube or WallScene class, we don't want display objects knowing about their Mediators. This helps to keep them portable; you should be able to use them in a non-PureMVC context. Instead expose an 'API' of events, properties and methods that allow a Mediator to take interest in and make changes to the component or its data without breaking the encapsulation of the component's implementation.

The WallScene would have a WallSceneMediator, and WallScene would send a WallScene.CUBE_CREATED event. That could be a custom WallCubeEvent¹ that carries the reference to the created WallCube. The WallCube would have a unique ID.

The WallSceneMediator adds a listener for WallScene.CUBE_CREATED in its onRegister method and in its corresponding handleWallCubeCreated method, creates and registers a new instance of WallCubeMediator, passing in the WallCubeEvent.wallCube on the constructor.

The WallCubeMediator calls super not with a NAME constant, but instead with wallCube.id, the unique id of the cube passed into the constructor.

¹ NOTE: you may not need a custom event here if BasicView does something similar, sending an event with a reference to the newly added object. In which case, you'd listen for that event. Though it still might be nice if you've got several custom things that can happen to a WallCube that you want to listen for, because the event is a great place to hang those constants.
-=Cliff>

[Jason MacDonald]

If you are using Flex you can use the PMVC Console

Whao, that looks amazing!  Unfortunately I'm not using Flex though.  Just Eclipse with the FDT plugin

Sorry, I meant it works with AS3. Just not if you are using Fabrication.

[toadrage]

Ah Cliff, you are THE MAN!
That's a great explanation and really makes sense in my context.  I think my problem was that I was thinking that I should be using FLASH events as little as possible but yes, there is obviously still quite a lot of things they should be doing within the PureMVC framework.

Can't believe I'm only just picking up PureMVC now.  It's awesome!  Separating the functionality of view components into mediators etc really does make my view components reusable in other projects.  Before I was sort of reusing stuff but it would always mean stripping out functionality from their classes, updating the functionality a bit etc.  Now I just copy the view item across and update the mediator!  Nice

Anyways, thanks again for your help Cliff, you're a great ambassador for an opensource project but unfortunately, I will probably be back with more questions as I delve farther into things!