Custom Messages - my code looks cleaner now

[mariusht]

Hi Cliff,

You can see here handlePipeMessage method from PipeWorks demo (LoggerJunctionMediator.as)

:

override public function handlePipeMessage( message:IPipeMessage ):void
        {
            if ( message is LogMessage )
            {
                sendNotification( ApplicationFacade.LOG_MSG, message );
            }
            else if ( message is UIQueryMessage )
            {
                switch ( UIQueryMessage(message).name )
                {
                    case LoggerModule.LOG_BUTTON_UI:
                        sendNotification(ApplicationFacade.CREATE_LOG_BUTTON)
                        break;

                    case LoggerModule.LOG_WINDOW_UI:
                        sendNotification(ApplicationFacade.CREATE_LOG_WINDOW )
                        break;
                }
            }
        }
and the source code for one of your custom messages

:

package org.puremvc.as3.multicore.demos.flex.pipeworks.common
{
    import mx.core.UIComponent;
   
    import org.puremvc.as3.multicore.utilities.pipes.messages.Message;

    public class UIQueryMessage extends Message
    {
        public static const GET:String = 'get';
        public static const SET:String = 'set';
       
        public function UIQueryMessage( action:String, name:String, component:UIComponent=null)
        {
            var headers:Object = { action:action, name:name };
            super( Message.NORMAL, headers, component );
        }
       
        public function get action():String
        {
            return header.action as String;
        }

        public function get name():String
        {
            return header.name as String;
        }

        public function get component():UIComponent
        {
            return body as UIComponent;
        }
       
    }
}
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
{
import com.mariusht.contactmanager.common.model.vo.ContactVO;

import org.puremvc.as3.multicore.utilities.pipes.messages.Message;

public class ContactMessage extends Message
{
protected static const NAME:String = 'ContactMessage';

public static const ADD_CONTACT:String = NAME + '/message/contact/add';
public static const CONTACT_ADDED:String = NAME + '/message/contact/added';
public static const CONTACT_ADD_FAILED:String = NAME + '/message/contact/add/failed';

public static const UPDATE_CONTACT:String = NAME + '/message/contact/update';
public static const CONTACT_UPDATED:String = NAME + '/message/contact/updated';
public static const CONTACT_UPDATE_FAILED:String = NAME + '/message/contact/update/failed';

public static const REMOVE_CONTACT:String = NAME + '/message/contact/remove';
public static const CONTACT_REMOVED:String = NAME + '/message/contact/removed';
public static const CONTACT_REMOVE_FAILED:String = NAME + '/message/contact/remove/failed';

public function ContactMessage(type:String, contact:ContactVO=nulll)
{
                        // add headers if needed
super(type, null, contact);
}

public function get contact():ContactVO
{
return body as ContactVO;
}
}
}
JunctionMediator.as

:

override public function handlePipeMessage(message:IPipeMessage):void
{
switch(message.getType())
{
case ScreenMessage.GET:
//
break;
case ContactMessage.CONTACT_ADDED:
contactsProxy.addContact( ContactMessage(message).contact );
break;
case ContactMessage.CONTACT_UPDATED:
contactsProxy.updateContact( ContactMessage(message).contact );
break;
case ContactMessage.CONTACT_REMOVED:
contactsProxy.removeContact( ContactMessage(message).contact );
break;
case ItemMessage.ITEM_ADDED:
itemsProxy.addItem( ItemMessage(message).item );
break;
case ItemMessage.ITEM_UPDATED:
itemsProxy.updateItem( ItemMessage(message).item );
break;
case ItemMessage.ITEM_REMOVED:
itemsProxy.removeItem( ItemMessage(message).item );
break;
}
}
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/

[puremvc]

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¹, all the protocols are defined on the messages themselves. It makes much more sense.
-=Cliff>

¹http://imajn.net

[mariusht]

Imajn looks interesting. I signed up for beta test program.

Mariush T.
http://mariusht.com/blog/

[puremvc]

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>