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: How to manage notifications?  (Read 10133 times)
yancaoshi
Newbie
*
Posts: 4


View Profile Email
« on: October 14, 2008, 07:20:51 »

Hi,

I  am still on the way to pureMVC and I find it's really tough to trace who is processor to some notification. Since notifications are broadcasted to the whole application, there's no clue to know who will process the notification from the broadcaster. Therefore, it's not easy to trace.

Anybody has suggestion to manage notifications?

Best regards,
yancaoshi
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #1 on: October 14, 2008, 07:59:32 »

Since notifications use static var names [SOME_NAME], and you must declare a mediator to listen for a notification inside the listNotificationInterests method, you should be able to simply search your code base for the static var [SOME_NAME] and see what mediators are registered as listeners for that notification.

Or am I misunderstanding the question?
Logged
yancaoshi
Newbie
*
Posts: 4


View Profile Email
« Reply #2 on: October 14, 2008, 09:06:41 »

Thanks for replying.
You provide a feasible way I should say, though it doesn't direct. As far as I know, it's impossible to trace that easily due to the broadcast mechanism.
Am I right?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: October 14, 2008, 06:35:26 »

What is needed is a diagnostic utility that can be used to log regisrations and removals and provide a view component showing all the commands, mediators and proxies that are registered for which notifications at any given moment. The trick would be to have an 'intercepting Facade', which overrides all the registration and removal methods of the framework facade and before calling super, caches what actor and notification is being registered or removed. The view component that displays this info would need to be hooked to the data being collected in an out-of-band way that doesn't use the notification system so as not to affect it, if possible.

I've been meaning to write this for a whils but haven't had time. If someone would like to be a hero and do so it'll be appreciated. Otherwise, eventually I'll get to it... :)

-=Cliff> 
Logged
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« Reply #4 on: October 15, 2008, 07:56:12 »

@Cliff,

I could see the framework simply using a logger class to log this sort of information. Would this be sufficient are you are looking for something a bit different? I'm thinking this sort of output would be similar to say the Model Glue framework in CF where it implements a trace() function just like in Flash, but it by default will also trace debug whatever the framework is doing so you can see what is happening in what order. I know you have some experience with CF so I bring this up as an example to see if its suitable. I'd be happy to work on this.
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #5 on: October 15, 2008, 08:19:01 »

What is needed is a diagnostic utility that can be used to log regisrations and removals and provide a view component showing all the commands, mediators and proxies that are registered for which notifications at any given moment. The trick would be to have an 'intercepting Facade', which overrides all the registration and removal methods of the framework facade and before calling super, caches what actor and notification is being registered or removed. The view component that displays this info would need to be hooked to the data being collected in an out-of-band way that doesn't use the notification system so as not to affect it, if possible.

I've been meaning to write this for a whils but haven't had time. If someone would like to be a hero and do so it'll be appreciated. Otherwise, eventually I'll get to it... :)

-=Cliff> 

I put something together. It is completely flexCentric. You have to extend your ApplicationFacade with NoteTrackerFacade and there is a viewcomponent to put someplace. The class that monitors registrations is a singleton, so you can grab it with NotificationRegistrar.getInstance() and its notificationMap property is where the command and mediator notification interests are stored. I made it to fit into a tree view, so it uses some of those flexy structures to fit into that dataProvider model.

I banged it out pretty quick, so I don't know if it will be that useful. I'm happy to enhance it if it is worth pursuing.
« Last Edit: October 15, 2008, 08:21:02 by Joel Hooks » Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
rideforever
Newbie
*
Posts: 2


View Profile Email
« Reply #6 on: October 16, 2008, 07:01:19 »

The first thing I did with PureMVC was implement a logging system for notifications (I modified the framework) ... so that when a notification occurs it is logged something like

Notification Raised : name : CHANGE_THE_THING, args : 1,2,3
> executing observer : 1 of 4
> executing observer : 2 of 4
> executing observer : 3 of 4
> executing observer : 4 of 4
/ Notification End


So ... when you switch this logging on, you can easily see where the application is at.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: October 19, 2008, 07:42:48 »

There is a functioning logger module in the PipeWorks demo for MultiCore.

That's useful, not what's needed for visualizing the map of Observer lists in a running app.

The problem is that Commands are registered for their corresponding Notifications in a different place from the Mediators. And since Commands and Mediators can be registered and removed dynamically, it is important to be sure that when an application is in a given state, that a specific map of Notification Observers are registered.
 
So its not a running log we want to see but a static display showing that map. And it might be useful for such a tool to evolve to the point of optimizing the registration order based upon notification traffic while performing ordinary use cases.

-=Cliff>
Logged
Pages: [1]
Print