Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
April 28, 2017, 10:25:35 PM
Home Help Search Login Register
News: ATTENTION: Spambots must die! Humans must visit http://contact.futurescale.com to request forum access.
Pages: [1]
Print
Author Topic: Can a module route notification to itself?  (Read 5396 times)
spacetimer
Jr. Member
**
Posts: 10


View Profile Email
« on: August 05, 2010, 07:01:35 AM »

Hi,
   I have a logger module that accepts and stores routed log entries from other modules. To do this I write a logger class that serves as a common utility and the code looks like this:
   ...routeNotification(RECEIVE_LOG_MESSAGE, logMsg, null, "LoggerModule/LoggerModule0);
   This works fine except that the logger module itself cannot send log messages. So I guess routeNotification cannot be used to route message to the host module itself?
   thanks~
   
Logged
manuraj.dhanda
Jr. Member
**
Posts: 13


View Profile
« Reply #1 on: August 10, 2010, 12:34:28 AM »

I also have a similar question.
My understanding about notifications( with respect to modules) is that,

"sendNotification()" works for notification interests for intra-module communication (within the same module),

where as "routeNotification()" works for inter-module communication(among multiple modules). And any notification sent through routeNotification can not be listened in same module.

Now again, the question arises that why we can not use routeNotification() only for both the purposes??
Logged
rafal.szemraj
Moderator
Full Member
*****
Posts: 41


View Profile WWW
« Reply #2 on: August 10, 2010, 01:54:24 AM »

Hi guys,

sendNotification is "native" method form PureMVC so it should remains untouched in my opinion. I don't know exactly original plans and thoughts about routers etc. ( because I didn't speak with Darshan about this ) but I think he wanted to have cleary separated methods for in/out communications.
If you want to notify a sender about note you can always trigger sendNotification after routeNotification with the same parameters ( noteName, body, type ). I think about putting sendNote call inside routeNotification method body, but I don't think if routing note to others modules and notifying sender itself is very common operation. What dou you think about this?

Logged
manuraj.dhanda
Jr. Member
**
Posts: 13


View Profile
« Reply #3 on: August 10, 2010, 11:37:09 PM »

Here I have a scenario where you need routeNotification to be handled in the same sender module as well.

Say my proxy made a call to some service and got the updated results ( a collection). Although I know I can update the same module localCollection in that resultHandler and dispath a routeNotification for other modules to update themselves.

But instead of that, I want to update the localCollection in a respondToXYZ(), so that it can update the localCollection always. Doesn't matter if the call happened in the same module or in a different module. Because I have to have this respondToXYZ() in any case(to handle the localCollection updates from other modules), then why shouldn't I move my logic for localCollection update from resultHandler to this respondToXYZ for all the use cases.

I am not sure if I am clear enough OR I did confused you with all this text. Let me know if you are confused then I 'll try to put some code to explain this.

Thanks,
Manu.
Logged
rafal.szemraj
Moderator
Full Member
*****
Posts: 41


View Profile WWW
« Reply #4 on: August 10, 2010, 11:59:09 PM »

If I understand this well, calling:

routeNotification( "someNote", results, null, "* );
sendNotification( "someNote, results );

should do the work. If you call this in any place in any module, every respondToSomeNote handler should be called in every mediator in your app. Is this ok?
Logged
manuraj.dhanda
Jr. Member
**
Posts: 13


View Profile
« Reply #5 on: August 11, 2010, 06:24:49 AM »

Agreed.
The only thing I was saying that instead of these 2 calls, why can't we just have routeNotification() to do the job.
Logged
Pages: [1]
Print
Jump to: