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: Quetion for "respondTo"?  (Read 10805 times)
marks416
Sr. Member
****
Posts: 52


View Profile Email
« on: March 16, 2009, 02:06:15 »

I read the doc for respondTo, that means respondTo<NotificationName> .

But I see the following code  in simple_routing demo

public function respondToModuleMessageCountProxy(note:INotification):void {
   .....
}

I can not find "ModuleMessageCountProxy" as NotificationName.it is a Proxy Name. I am confuse for this.
Please help

Thanks

Mark
« Last Edit: March 16, 2009, 02:08:40 by marks416 » Logged
devin_acosys
Newbie
*
Posts: 2


View Profile Email
« Reply #1 on: March 16, 2009, 11:36:32 »

Yes, I got the same question 1 hour before. now recognized that the method responsTOBlaBla automatically handle the notification with "BlaBla" in the framework.
Logged
devin_acosys
Newbie
*
Posts: 2


View Profile Email
« Reply #2 on: March 16, 2009, 11:45:12 »

Take a look for this, from Fabrication Feature:

Notification extensions : Fabrication provides mediators to detect notification interests based on intent. You no longer need to declare notifications that your mediator is interested in with listNotificationInterests. Instead you simply write a handler function like, respondToChanged. Fabrication automatically interprets this as a mediator's interest in the "changed" notification name. This feature reduces the complexity in switch cases that can result in a Mediator's handleNotification.

Logged
marks416
Sr. Member
****
Posts: 52


View Profile Email
« Reply #3 on: March 17, 2009, 06:55:35 »

I know "respondTo" is used for handle Notification and the syntax is respondTo<NotificationName>.

My question is for the special function in simple_routing demo.

public function respondToModuleMessageCountProxy(note:INotification):void {
   .....
}

ModuleMessageCountProxy should be a notification but it is proxy name,do you think if "respondTo"  can used for handle proxy name?

Thanks

Mark
Logged
marks416
Sr. Member
****
Posts: 52


View Profile Email
« Reply #4 on: March 18, 2009, 06:54:12 »

Hi,

It seems the documentation should have the following:

respondTo<ProxyName>

"this handle all the notifications that send from <ProxyName>"

Do you think if my understanding is right?

Thanks

Mark
Logged
pavelj
Newbie
*
Posts: 2


View Profile Email
« Reply #5 on: March 29, 2009, 04:38:04 »

I have the same problem. The simple_fabrication_routing drives me crazy. I tried to find how exactly routing works. I know about respondTo<NotificationName> and that's probably why I don't understand this demo:
Scenario: I launch demo load 1-2 mosules and then I press notify all modules.

Now I wanted to find out how exactly this works...

in MessageControlBarMediator I have function
private function messageAllButtonListener(event:FlexEvent):void {
         routeNotification(FabricationRoutingDemoConstants.RECEIVE_MESSAGE, "Message From Shell");
      }
this is fired when I press notify all modules.
...
FabricationRoutingDemoConstants.RECEIVE_MESSAGE is stated as: "receiveMessage"
...
that should route note across modules and module with listener respondToReceiveMessage should be fired, but nothing like that exists.

but there is function in MessageCountMediator called:

public function respondToShellMessageCountProxy(note:INotification):void {
         updateShellMessageText();
      }
this display updated number in module
...
but how this is fired?? have no idea. I tried to play with CounterProxy and this nearly bring me to maddness. I found function:
public function changeCount(newCount:int):void {
         if (count != newCount) {
            setData(newCount);
            sendNotification(COUNT_CHANGED, newCount);
         }
      }
there is sendNotification call. I noticed that when I comment this out it does not fire respondToShellMessageCountProxy in module but when I change it to ie sendNotification("blaBla", newCount); it fires anyway!? even I call just sendNotification() it still fires module respondTo.

still have no idea where is listening for respondToShellMessageCountProxy created.
SimpleModuleConstants.SHELL_MESSAGE_COUNT_PROXY seems has the right syntax but can't find where is implemented as note name.

Most irritating thing about that is that I have this in front of my eyes and it works but bloodyeel can't find why:)

Any ideas??

Thanks

PS: thanks to Cliff and Darshan for creating something what brought real joy into flex programming for me
Logged
Darshan Sawardekar
Sr. Member
****
Posts: 85


View Profile Email
« Reply #6 on: April 01, 2009, 08:28:03 »

Hi pavelj,

Thanks for trying Fabrication. And sorry about the "simple_routing" demo. That demo started off as a basic demo. But the different routing features have grown in size and I am afraid that demo is a little complex now.

still have no idea where is listening for respondToShellMessageCountProxy created.
SimpleModuleConstants.SHELL_MESSAGE_COUNT_PROXY seems has the right syntax but can't find where is implemented as note name.

To answer your question. The missing link is that notifications can also be handled via registering them with commands. The startup command of the module does this,

:
registerCommand(FabricationRoutingDemoConstants.RECEIVE_MESSAGE, UpdateMessageCountsCommand);

As a result the UpdateMessageCountsCommand is fired when the RECEIVE_MESSAGE notification is routed into the module. This command then increments the corresponding proxy based on the source of the notification. Hope that helps.

peace,
darshan
Logged
pavelj
Newbie
*
Posts: 2


View Profile Email
« Reply #7 on: May 04, 2009, 10:04:24 »

Thanks Darshan,
Little bit late response as I was snowed by work stuff. Don't understand why I didn't look into commands registration as first:). Demo is probably harder to get on begining but is great way to get into it in bigger scale. I had longer play with fabrication and I'm still impressed how well this ulity is coded. Intensive crossloading of flex and flash modules and still no issues. Everything works as expected. Great stuff!
cheers

Pavel
Logged
Pages: [1]
Print