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: General practice for "daisy chained" notifications  (Read 6156 times)
realien
Jr. Member
**
Posts: 16


View Profile Email
« on: August 03, 2009, 10:46:16 »

Hey guys,

I'm looking for some guidance/best practice here, I seem to be running into a common pattern in the larger pureMVC apps we create ( >300 hours), and I don't like the "ad hoc" solution I seem to be using.

A simple example :

I have a shell application for a set of games, the user can choose which game to play, when various "events" in the app occur, a game may loose "focus", the games are implemented as fabrication modules so I'm dispatching events to modules using routeNotification, I have the shell manage focus as follows :

  • The shell captures focus when someone clicks on the main application
  • The shell knows which game is active through the ShellGameProxy
  • When the main view receives a mouse click, it dispatches a notification ShellConstants.SHELL_REQUEST_FOCUS
  • The FocusRequestCommand, receives this notification and looks at the ShellGameProxy to see which game is active, when it determines that, it routes a notification directly to that module using MODULE_REQUEST as the note name, and RESUME_FOCUS as the note type
  • The modules all have their own ModuleRequestCommand, it receives the MODULE REQUEST, and the switches on the RESUME FOCUS, it then re-dispatches so it can figure out what to do with as MODULE_RESUME_FOCUS, the ModuleFocus command, receives this and determines if the module should receive focus and if so sends a RESUME_FOCUS notificaiotn, the GamePlayMediator is listening for this and tells the main view to "take" focus.

The thing I don't like is I have the shell sending focus resume notifications that differ from the module's resume focus notifications so that the module's can process the request in a command to make a decisions rather than the notification going directly to the mediator and affecting the view without any "businesss logic"

But I feel like I'm daisy chaining notifications and changing their names just so that I can control "who" hears them, and it feels "messy".

shell gets focus -> shell sends focus to module -> modules receives request and figures out if it needs focus -> modules sends focus to its mediator which applies it to the view

I seem to have

SHELL_REQUEST_FOCUS as notificaiton
MODULE REQUEST with RESUME_FOCUS as type
GAME_RESUME_FOCUS as notification

This seems to occur a lot on large apps where some "action" requires a few decisions and information to be "passed around" before a final "do it" notification can be dispatched for a mediator to actually apply.


Any thoughts would be most welcome :) ???





« Last Edit: August 03, 2009, 10:52:13 by realien » Logged
Pages: [1]
Print