Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Getting started  (Read 17372 times)
Darcey
Newbie
*
Posts: 8


View Profile Email
« on: January 18, 2011, 07:37:27 »

Hi,

I have just created a hello world example and have a few questions if anyone can clarify a few things before I proceed that would be great.

Q1. I have a stage mediator registered from my ApplicationMediator, this stage mediator dispatches mouse up notifications. I am randomly placing the hello world text on x and y. Where should the random x and y be calculated? Is it best practice to place the random positioning logic for the placement of the hello world view component in the ApplicationMediator via its handleNotification function where the view component is instantiated or should this be done via a command? If it's a command how do I get the reference of the view component added to the stage for x and y placement?

Q2. Registering mediators inside mediators is this correct? or should they all be registered in a centralised place for better management?

Q3. If mediators register and handle other mediators, should they be able to obtain references to other mediators? If yes how do we get the reference to the created mediator?

Q4. If for example I am building an application that has an empty container as a view, to which I add views to it later. Where would the logic go for adding view components to a view? If this is a mediator, im guessing a command would be created for listening to added for listening to events from the mediator for handling things to do when added and when removed?

Q5. If I have a 3D Scene as a view (which is default blank), and then create separate view components which can be added to the 3D Scene view, should the 3D scene view be a view or a mediator? Im guessing mediator for calling the view component (3D scene), then same mediator to listen to events and have code in it to add 3D objects to the view component or is this a more complicated scenario of many commands, mediators and views?


For a moment there while typing this I thought I clarified things for myself, then I re-read it and now think the opposite lol...


To visualise things I created some process flow class diagrams to illustrate how I think the PureMVC is actually laid out.

So the main application would be laid out like so:


Mediators would all be like so:


and all commands like so:



This look correct?


Any info is much appreciated.

Thanks

Darcey
« Last Edit: January 18, 2011, 09:01:17 by Darcey » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: January 18, 2011, 10:15:28 »

Q1. I have a stage mediator registered from my ApplicationMediator, this stage mediator dispatches mouse up notifications. I am randomly placing the hello world text on x and y. Where should the random x and y be calculated? Is it best practice to place the random positioning logic for the placement of the hello world view component in the ApplicationMediator via its handleNotification function where the view component is instantiated or should this be done via a command? If it's a command how do I get the reference of the view component added to the stage for x and y placement?

I'd probably have the StageMediator be interested in a PLACE_OBJECT_RANDOMLY note, and handle it by taking the DisplayObject out of the body of the note, adding random x/y coords and adding it to the stage. Any other actor could create the display object and send the note.

Q2. Registering mediators inside mediators is this correct? or should they all be registered in a centralised place for better management?
Well, it depends on a number of factors. If the view hierarchy all exists at startup, is very flat (only one or two levels deep) then for expediency you might register all the mediators in one shot in your view prep phase. But that isn't an across-the-board, works-in-all-situations answer.

If your hierarchy is deep, and/or some of the mediated components have creation deferred, then it's better to let mediators register mediators.

The philosophy here is that encapsulation of the view is violated by that one command that knows the whole hierarchy. A mediator's relationship with its view component, is by design somewhat more intimate. We can say that the first level of children under the view component in question are top level public properties of that component, part of an API of sorts. The mediator can access them without being considered too intrusive. When it then wraps a mediator around that component, the same concept applies.

Q3. If mediators register and handle other mediators, should they be able to obtain references to other mediators? If yes how do we get the reference to the created mediator?
The best practices doc points out that you should not retrieve mediators and invoke methods on them, but rather send notifications to them. This is their intended form of communication with the rest of the application, and you should follow it wherever you can, because it keeps things loosely coupled in the view, which makes for more reusable mediator/view component pairs. I'm working in an app right now where the big media creation app has been developed over several years. Now that it's grown so large, they're building a lightweight viewer app in Flex and offline viewing app in AIR, both of which need to reuse many pieces of the bigger creation app. Because of tight coupling in the original code, we're finding it difficult to reuse many of the pieces because it was always assumed that they would only ever be used in the creation app. So, the point is if you keep things loose by default (sending notes rather than retrieving a mediator and invoking a method, then if you ever do need to reuse things you'll thank yourself.

Q4. If for example I am building an application that has an empty container as a view, to which I add views to it later. Where would the logic go for adding view components to a view? If this is a mediator, im guessing a command would be created for listening to added for listening to events from the mediator for handling things to do when added and when removed?
No, don't make commands into event listeners. They're intended to be instantiated, executed and garbage collected. This is their lifecycle; they are not long-lived objects. The mediator listening to the container that just had objects added to it IS a long-lived object and is the perfect place for such a listener.

Q5. If I have a 3D Scene as a view (which is default blank), and then create separate view components which can be added to the 3D Scene view, should the 3D scene view be a view or a mediator? Im guessing mediator for calling the view component (3D scene), then same mediator to listen to events and have code in it to add 3D objects to the view component or is this a more complicated scenario of many commands, mediators and views?
A 3D scene is just a view hierarchy. Mediate it accordingly. The scene probably has a mediator. If you put some player or nonplayer actors in there, they probably have mediators. A table or a wall or a tree, probably not so much unless those objects are going to be interacting with the rest of the app in some complex way, generating events that in turn have effects on other objects in the scene.

To visualise things I created some process flow class diagrams to illustrate how I think the PureMVC is actually laid out. This look correct?
More or less, yes this is your basic flow. Getting into MultiCore or using the StateMachine may change this picture a little bit.

-=Cliff>
« Last Edit: January 18, 2011, 10:17:34 by puremvc » Logged
Darcey
Newbie
*
Posts: 8


View Profile Email
« Reply #2 on: January 18, 2011, 02:03:02 »

Excellent thanks for info :)

However I'm not 100% on the vocab of the pureMVC, not quite sure on:

I'd probably have the StageMediator be interested in a PLACE_OBJECT_RANDOMLY note, and handle it by taking the DisplayObject out of the body of the note, adding random x/y coords and adding it to the stage. Any other actor could create the display object and send the note.

 "PLACE_OBJECT_RANDOMLY note"? - I assume by this you mean a "placeObjectRandomly(do:DisplayObject)" function but where? I assumed a command which would have been run in the "NotificationHandler" function of the ApplicationMediator?



Any other actor could create the display object

"Actor"? Is this the pureMVC communities ref to a Mediator?





And finally my picture of what happens in my applications mediators is now this, just to clear things a little more, is this correct?


Application Mediator (On my hello world application)
   - Register any mediators required
   - Instantiate any views
   - Setup "notification handler"
   - "Notification handler" exec commands via sendNotification via the facade to position "sprite"
            - "Mouse button stage up" notification:
               Instantiates hello world view text component and sends a notification
               via sendNotification for a command to position HelloWorld text randomly on x & y
               (how can the command get the view components reference for positioning?
               & how can the command get the stage? or reference to any required mediators?)





and for my next test build with preloader, closer to a template I will work from would be something like





Application Mediator (On my preloader application)
   - Register any mediators required for preloader UI
   - Setup "notification handler"
   - sendNotification(STARTUP,{setup}); to trigger Notification Handler here to setup preloader UI
   - "Notification handler" exec commands via sendNotification via the facade to handle
            - "Preloader UI setup" notification
            - "Preloader animation in" notification
            - "Preloader animation progress" notification
            - "Preloader animation out" notification
            - "Preloader ui dispose" notification
            - "Setup global UI components" notification (for nav etc)
            - "Start main application" notification
            - Application nav shared event adjust ui for nav option 1 press (also handled in Navi mediator)
            - Application nav shared event adjust ui for nav option 2 press (also handled in Navi mediator)
            - etc
« Last Edit: January 18, 2011, 02:11:51 by Darcey » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: January 19, 2011, 11:07:26 »

"PLACE_OBJECT_RANDOMLY note"? - I assume by this you mean a "placeObjectRandomly(do:DisplayObject)" function but where? I assumed a command which would have been run in the "NotificationHandler" function of the ApplicationMediator?
That is a notification named PLACE_OBJECT_RANDOMLY. Notifications are commonly referred to as notes for short.

And finally my picture of what happens in my applications mediators is now this, just to clear things a little more, is this correct?

Application Mediator (On my hello world application)
   - Register any mediators required
   - Instantiate any views
   - Setup "notification handler"
   - "Notification handler" exec commands via sendNotification via the facade to position "sprite"
            - "Mouse button stage up" notification:
               Instantiates hello world view text component and sends a notification
               via sendNotification for a command to position HelloWorld text randomly on x & y
               (how can the command get the view components reference for positioning?
               & how can the command get the stage? or reference to any required mediators?)

Well, you'd actually instantiate any views before registering mediators, presumably you'd be passing those views to their mediators.

And what I was suggesting in my previous post was that the StageMediator would respond to the PLACE_OBJECT_RANDOMLY note by setting the object's x and y to random values and setting it on the stage. You don't need to send it off to a command for that.

Quote
Any other actor could create the display object

"Actor"? Is this the pureMVC communities ref to a Mediator?
No, that's a general OOP term for a class with some clear role. In this case it would be a Command or a Mediator.

Application Mediator (On my preloader application)
You can't mediate the preloader. It comes before Flex has finished initializing, and creating its view hierarchy. Only after that do we startup the PureMVC apparatus.

-=Cliff>
Logged
Darcey
Newbie
*
Posts: 8


View Profile Email
« Reply #4 on: January 19, 2011, 10:55:40 »

Excellent! thank you for all this help and info, has been pivotal, I find so many contradictions in what should go where googling all this stuff..

I have a framework called the AFTC, which is a modular framework which is a combination of factory, singleton and observer patterns. Included are 1 x XML doc for sprite/mc application container structure, 1 x XML config, embedded assets manager, preloader via bulkloader, various managers for assets and fonts etc. The AFTC simply allows a dev to simply copy and paste the base template and create a folder for each module of the application to work within for each module of their application. All of this weighs in around 12Kb, I am wishing to re-create this using the PureMVC so I can just copy and paste my template app and have access to all the essential managers, assets and utilities from my AFTC framework, so I can keep Rapid Application Development just using the PureMVC.

Hopefully last question before I get back into test app city.

Narrowing down things in a more general sense would lock my application and all future applications I build into this layout:

Commands
  • Call functions from proxies
  • Send notifications for mediators to update their view components on data notifications received from proxie (failed or changed)

Mediators
  • Add view components to the stage/display (to give references to their relative mediators)
  • Instantiate other mediators
  • Perform logic for positioning and animation of view components (eg tweens etc)
  • Handle events from commands
  • Handle events from other mediators when required

Model (not coded any self test examples yet but I think its)
  • Loading of data
  • Loading error event dispatching caught by commands
  • Loading success event dispatching caught by commands
  • Loading progress event dispatching caught by commands (would a command dispatch another event for a mediator to pick up for progress loading for example or would a developer skip this and let the mediator listen to the proxies progress event?)
  • Vo (not quite sure on this classes role, just a list of variable declerations which are accessible?)
  • Proxy (not quite sure on this classes role, just a list of variable declerations which are accessible?)



Regarding my template app for future projects, I would:
  • In prep model - I will setup proxy for config xml (local file)
  • In prep model - I will setup proxy for assets xml (local file)
  • In prep model - I will setup proxy for containers xml (local file)
  • In prep model - I will setup proxy for accessing assets from bulkloader
  • In prep view - I will init embedded assets (0kb swf containing assets for preloader only - after flex prelloader init (if flex))
  • Application mediator - Init blank view component for preloader (calls success as default to proceed)
  • AssetPreloaderMediator - Execute preloader mediator
  • AssetPreloaderMediator - On preloader mediator complete - proceed with main application
  • MainApplicationMediator - Ini global stage ui views
  • MainApplicationMediator - Ini nav view
  • MainApplicationMediator - pass global ui views and nav views to their mediators via mediat init
  • MainApplicationMediator - Call starting module mediator to start homepage for target project


Let me know if I am going down the wrong path here. or am I thinking in the wrong way in implementation.

Thanks again

Darcey
« Last Edit: January 20, 2011, 02:07:34 by Darcey » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: January 21, 2011, 06:40:50 »

Perform logic for positioning and animation of view components (eg tweens etc)
Mediators are not code-behind classes. They shouldn't perform much if any logic. If it's complex at all, send the component of in the body of a command to be processed instead.

Loading progress event dispatching caught by commands (would a command dispatch another event for a mediator to pick up for progress loading for example or would a developer skip this and let the mediator listen to the proxies progress event?)
Yes, feel free to have mediators listen directly for proxy notifications. The view is unavoidably dependent upon the model; it has no other reason in life than to display and let you interact with the model.

AssetPreloaderMediator - Execute preloader mediator
As I mentioned in the previous response you can't mediate the preloader.

MainApplicationMediator - Call starting module mediator to start homepage for target project.
Is this a multicore project? If you're loading a module that uses PureMVC, it needs to be, so that there is a separate facade for each module.

Otherwise this looks ok.

-=Cliff>
Logged
Darcey
Newbie
*
Posts: 8


View Profile Email
« Reply #6 on: January 23, 2011, 11:17:31 »

ok seems I'm not thinking on the right path here.... :\   I'm a bit confused on the roles of the mediator and the command. Is this correct?


Mediators
Mediators do nothing apart from instantiate other mediators passing view components to them and listen to notification events which the mediator would call a function in the corresponding view components to update themselves, animate etc

Commands
Are the applications performance logic.
So, they get references to mediators and view components to perform logic on them (or would the logic of animation be partly done in the views?). How would 2 balls colliding in a 2D or 3D scene work? Would a command hold multiple references to multiple mediators and the view components performing logic on them eg enter_frame events if sometimes necessary? Would a command handle enter_frame logic?


Regarding preloader.
I am wanting to include bulkloader in my puremvc template application, my picture on how to do this now is to, create bulkloader proxy, bulkloader mediator, bulkloader view (progress bar). A command would be run which would setup a proxy, then the command would run a mediator which in turn would setup a preloader ui? Is this correct?



In response to your question:
Is this a multicore project? If you're loading a module that uses PureMVC, it needs to be, so that there is a separate facade for each module.
No, I am in the habit of referring to a RIA,Webpage etc's pages, different sections as modules.


Thanks again.

Darcey
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: January 24, 2011, 10:53:58 »

Would a command hold multiple references to multiple mediators and the view components performing logic on them eg enter_frame events if sometimes necessary?
Remember, commands are short-lived. They are instantiated when they are triggered and when their execution is complete they are GC'd. So they wouldn't 'hold references to mediators', though they could fetch them when need be.

More likely, the view component produces an event which the mediator hears and passes the component in the body of a notification to a command, where the command performs some logic on the component.

the command would run a mediator which in turn would setup a preloader ui? Is this correct?
It's the other way around. Mediators send notes that 'run' or execute commands, which are short-lived actors. Mediators are registered and remain as long-lived actors listening to their view components.

A quick way to clear up confusion about the roles, responsibilities and collaborations of the framework actors is to visit the overview presentations and/or read some of the documentation at http://puremvc.org/content/view/98/189/

Cheers,
-=Cliff>

-=Cliff>
Logged
Darcey
Newbie
*
Posts: 8


View Profile Email
« Reply #8 on: January 24, 2011, 12:36:56 »

ok after watching single core video (got direct link for flv download?), this is what I presume to understand now:


Views
Create the visual elements
Functions for animation on the view component

Mediators
Event notification listener to trigger view functions
Call commands

Commands
Proxy handling
Dispatch notifications for mediators & views to pickup




Question 1
If the above is correct, would a view contain an enter frame event listener and function to handle enter frame animation?

Question 2,3,4,5
For a 3D scene, on collision detection of lets say randomly 10 3d objects, each with different animations depending on the type of object pair collision, where would the enter frame collision detection code be placed, as a mediator shouldn't perform logic and a command is short lived? or is this an exception?


The googling continues...  Thanks again.

Darcey
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #9 on: January 24, 2011, 01:09:39 »

Mediators
Event notification listener to trigger view functions
Call commands
Mediators can also retrieve and interact with Proxies for simple updates.


Question 1
If the above is correct, would a view contain an enter frame event listener and function to handle enter frame animation?
Yes. The View Component can and should encapsulate as much of its own behavior as possible.

It only needs to initiate communicate with the app when it needs to let the rest of the app know something has happened to it (such as a collision or a button press) or it needs data (country and state selected, need specific counties to populate a combo) or wants to add or update data to the Model (form submission).

The app only needs to communicate with the view component to feed it data (inject the country list into a newly shown form or tell it to change to a new view state based on a change in application state).

Question 2,3,4,5
For a 3D scene, on collision detection of lets say randomly 10 3d objects, each with different animations depending on the type of object pair collision, where would the enter frame collision detection code be placed, as a mediator shouldn't perform logic and a command is short lived? or is this an exception?
Collision detection should happen in the component. The component should send an event with the object it's crashed into as a property. The Mediator should hear this event and pass it on to a command (via notification) for evaluation. This command might figure out what the objects need to do; maybe one bounces off and the other explodes. The command could then call the bounce method on one and the explode method on the other or some such. And possibly call a Proxy to bump up the score if this was a missile and an enemy that collided.

-=Cliff>
Logged
Darcey
Newbie
*
Posts: 8


View Profile Email
« Reply #10 on: January 24, 2011, 03:08:09 »

Excellent, ok think I'm on the right path now.

Thanks for all the help with my questions :)
Logged
Pages: [1]
Print