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: updating notification interest list after mediator registration  (Read 9022 times)
krange
Newbie
*
Posts: 8


View Profile Email
« on: February 16, 2011, 08:10:06 »

I will be adding support to our existing PureMVC application where we will be loading in a module (not-nessesarily puremvc) built by our customers. In addition, one of the features they want to add is the ability for the custom module to listen for notifications from our shell application as well as send out notifications to our shell. To do this will be creating an interface between the two and passing information to and from (just like a view would normally).

The question then arrises in my head, what happens if they want to listen to a notification at some future point in their module (not at registration). Only the notifications they could register at startup would be available to them. This seems like a highly likely use-case in this scenario for us.

I've gone through the PureMVC classes and it looks as if from within a mediator, you can't update it's notification list after registration. I've done a search through the forums as well but none that really give any guidance in this case.

Anyone have ideas?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: February 16, 2011, 01:21:00 »

The Mediator's registration interests are not something that should change over time.

Regarding the passing of notifications between modules running PureMVC and the shell, you absolutely need to be sure you're building on MultiCore and not Standard edition, otherwise it will not work. And if you are using MultiCore and plan to pass notifications between cores, the best way to do that is with Pipes and a common message protocol. Especially in the case of third party modules, if you don't share a message protocol, you cannot know what notifications the module core has registered otherwise.

-=Cliff>
Logged
krange
Newbie
*
Posts: 8


View Profile Email
« Reply #2 on: February 16, 2011, 03:11:12 »

Hi Cliff,

Thanks for responding. I understand the multicore/pipes setup and have used it many times before. My fault for not stating my question a bit clearer.

The use case is that our clients will be creating a SWF (most likely NOT a PureMVC application) that will need to respond/send notifications to our PureMVC multicore application. Now, of course if they aren't in PureMVC they can't directly send/receive notifications. So instead, we will be creating a wrapper PureMVC module which will provide this connection through an interface we have set up. This interface that their SWF will need to implement will at the very least provide us a method similar to PureMVCs listNotificationInterests():Array. That way we know find out what notifications their SWF is interested in when the wrapper mediator is registered (aka, similar to the normal PureMVC setup).

I guess my question is, is there a way to add notification interests more dynamically as their SWF may not know once it "load completes" all the notifications it will need. We could force them to be more static and maybe that is the solution, just trying to see if there is a way to provide them more flexibility.

Thanks again for responding and reading my ramblings :)
Kris
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: February 20, 2011, 11:39:53 »

our clients will be creating a SWF (most likely NOT a PureMVC application) that will need to respond/send notifications to our PureMVC multicore application
Are you saying

A) Their swf actually has compiled in at a minimum the PureMVC Notification class or INotification interface and you'll be passing an actual INotifications to the swf and expect them to somehow send them (without having a facade).

OR

B) Their swf will have some sort of API of events, methods, and message classes that you will be communicating with and your mediator needs to mediate this swf, turning the events it gets from the module into outbound notifications and inbound notes into messages and/or method calls on the swf.

HINT: B is the sane option here. Create a protocol that includes an interface and some message classes. Mediate their module like any other view component.

I have a hard time understanding why path A would be a requirement.

is there a way to add notification interests more dynamically as their SWF may not know once it "load completes" all the notifications it will need.
When will it know? At what point in its lifecycle will it know everything it's interested in? Mediate at that point and not until. Mediator interests are fixed.

Also, this situation raises some serious encapsulation and dependency issues. How is the third-party swf supposed to know the actual notification names that your application is sending around internally? How is the protocol defined and enforced? Do the third-party swf and your application both share a common constants or configuration file?

-=Cliff>
Logged
krange
Newbie
*
Posts: 8


View Profile Email
« Reply #4 on: February 21, 2011, 01:25:30 »

We are definitely going down path B, path A is not a requirement. Setting up an Interface and transforming the notifications into our own Messages and vice versa for their communication to our application. We don't want them to know about PureMVC even if they happen to use it themselves. Regardless, there is a forced barrier there.

I guess the best is, like you say, mediate when the SWF knows all the notifications it is interested in...

Thanks,
Kris
Logged
Pages: [1]
Print