Title: Custom Messages - my code looks cleaner now Post by: mariusht on January 20, 2010, 09:41:04 Hi Cliff,
You can see here handlePipeMessage method from PipeWorks demo (LoggerJunctionMediator.as) override public function handlePipeMessage( message:IPipeMessage ):void and the source code for one of your custom messages package org.puremvc.as3.multicore.demos.flex.pipeworks.common Below you can see one of my custom messages and the way i access their types in any JunctionMediator package com.mariusht.contactmanager.common.messages JunctionMediator.as override public function handlePipeMessage(message:IPipeMessage):void I really like using 'switch case' rather 'if, else if' statements in handlePipeMessage method. It makes my code cleaner. Let me know what you think. Mariush T. http://mariusht.com/blog/ Title: Re: Custom Messages - my code looks cleaner now Post by: puremvc on January 21, 2010, 09:16:31 Thanks for bringing this up Mariush. It points out the error of my ways with regard to pipe message handling in a few demos.
I agree that the switch/case construct is the right one to use in the JunctionMediator. PipeWorks was the Proof of Concept for Pipes. So it's a first draft. My first thought about that handler was (in that particular JunctionMediator) that I needed to shunt the log messages one way and then based on message name, handle the UIQueryMessages. And I didn't know if I would have other message types coming though that I would handle differently based on another attribute of the message or not. Another thing was where the message name constant came from. Several times I've fallen into the trap of defining them on the module. While coding it *seems* handy to know where the message came from to keep everything straight in your head. But that's not good, because it makes dependencies between the modules themselves. A refactor of PipeWorks and of Sea of Arrows (which both did this) would definitely be to move the message names to the message itself, make both modules know the message and not each other. So the messages end up defining the protocol and the message handling ends up being more straightforward, as your example clearly shows. In the soon-to-be-entering-beta Imajn Modular Client system1, all the protocols are defined on the messages themselves. It makes much more sense. -=Cliff> 1http://imajn.net Title: Re: Custom Messages - my code looks cleaner now Post by: mariusht on January 21, 2010, 09:56:30 Imajn looks interesting. I signed up for beta test program.
Mariush T. http://mariusht.com/blog/ Title: Re: Custom Messages - my code looks cleaner now Post by: puremvc on January 22, 2010, 11:32:22 I'm getting pretty close to opening the beta program. Building the forums and putting license-control into the Flex and AIR clients, and auto-update into the AIR client. This is going to be a really fun platform to build for. I'll ping everyone who signed up when it's ready.
-=Cliff> |