Mediator Extension

[Dal]

Hi Guys,
I have a quick question and hope that someone can point in the right direction.

Flash/AS3 standard core version, no fancy flex or anything.
I basically want to create a set of base mediators, which contain certain listNotificationInterests and the corresponding handleNotification's, these base mediators have common notifications throughout such as adding its component to the stage, using tweener to move it round, so on......

Then build all custom mediators out this set, that way if I want to extend anything I just extend the base mediator and everything using it has the new functionality.

Problem I ran into was that Mediator sets up abstract public classes listNotificationInterests and handleNotification to be over-ridden by custom mediators, I didn't really want to start playing round with the frame work, I wanted the custom mediator to extend the base - not override them......
Please forgive any ignorance - as I'm sure there is already a way - i just can't follow at the mo.....
Should I be using a controller to setup and pass the notifications array to the mediator?
Has anyone done something like this?
Is there a better way?


Chur
~D

[Joel Hooks]

In all of my projects (fancy Flex or otherwise ;P ) I use an AbstractMediator, AbstractController, and AbstractProxy as a base for their corresponding concrete classes. In my abstract mediator, if I wanted all of my concrete application specific mediators to listen for a notification, I would override the listNotificationInterests and handleNotification methods. Then, in my concrete mediators, I will override them again, but make sure to use super.listNotificationInterests() in the methods. You may have to use super.listNotificationInterests.concat([ MyInterests ] ), but the switch statement in the handleNotification should work without any special treatment outside of the super call.

I generally do this in my concrete classes with onRegister() because I use the ApplicationSkeleton utility and all of my proxies and mediators want access to configProxy and localeProxy. The same principle should apply to your situation.

[Dal]

Cheers Joel,
Your way seems like it may be nicer than mine, not adjusting the frame work.....

My workaround evolved all my custom mediators extending there BaseMediatorType instead of Mediator, BaseMediatorType being a new Mediator Class based on the pureMVC Mediator which has a new private function BaseHandleNotifications - this takes care of all the base functionality - I need for that particular mediator type i.e. BaseMovie has different functionality from BaseImage.

Within each new custom mediator I do a switch case on the notification coming in and if it does not match anything - in the default I call BaseHandleNotifications function and away we go......

That's a lot of bases.... don't know if I covered them all though?
Whats the general practice with playing with the framework Cliff??
I might try to implement yours Joel, it seems like it might be more scalable.....


Cheers
~D

[puremvc]

Hi folks,

For an example of this have a look at the MultiCore Pipes utility and the PipeWorks demo.

Pipes defines a JunctionMediator which extends Mediator and is used to add ACCEPT_*_PIPE handling. Then there is a LoggingJunctionMediator that extends it adds logging handlers, or defaults to super.handleNotification. Then there is a subclass for the Prattler rss reader module which gets logging and pipe acceptance inherited. You can subclass till the cows come home this way.

Also, you have to deal with enumerating the interests of the entire inheritence tree. So rather than just returning an anonymous array of constants, you call super.listNotificationInterests to get the array of all your ancestors, pust your interests onto the array and return that. QED, no utilities or special math needed.

-=Cliff>

[puremvc]

woops

... call super.listNotificationInterests to et the array of all your ancestors' *interests* ...

-=Cliff>

[Dal]

Sweet cheers Cliff,
Being able to look at some coding helps me get it.


Chur
~D