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 system
1, all the protocols are defined on the messages themselves. It makes much more sense.
-=Cliff>
1http://imajn.net