Thanks for the feedback Cliff. I'll implement your suggestions and hopefully have some code + unit tests and a sample application in a couple days.

I've rethought some of my initial approach, borrowing the JunctionMediator idea from pipes.  Instead of having the facades themselves participate in sending messages, I've made an IChannelAdapter interface. This interface extends the IMediator interface, so that it can listen for Notifications.  Its sole purpose is to broker communication between the MessageBus and the Module/Application.

With this approach the only parts of the original application that need to be modified are the startup command (to handle creating the ChannelAdapter). Naturally the notification to message and message to notification logic will need to be implemented, but that's now part of the ChannelAdapter implementation. Once the channel adapter is in place, module to module and module to application communication should be transparent to the rest of the application.

The only thing that bothers me about this approach is that it is more difficult to send a message for a special case. Forcing one to send a notification just for the sake of sending a message doesn't seem reasonable.

For now I'll just create an IMessageSender interface that can be implemented by an application facade, command, etc. and hope a best practice comes out of using it more.

Hi All,

I have an alternative idea (and basic implementation) for communicating between modules. I have dabbled with j2ee web services and enterprise message buses before, and the problem seems similar. One service needs to talk to another, and to mitigate coupling between the services, they communicate via a Message Bus.

Here's a (hopefully) brief description of what I've implemented thus far.  I want to get feed back to see if this is a utility that could be contributed to puremvc.  I will use the utility regardless, but I wanted to contribute if possible.

The utility consists of the following classes:
MessageBus : Facades register themselves with this singleton class upon creation. In addition, facades will declare here what messages they are interested in, and optionally a transformer to translate the Messages into Notifications.

IMessageTransformer : interface that can be implemented to provide a way of transforming message types into notifications specific to each Module's ApplicationFacade.

MessageTransformer : a default implementation of IMessageTransformer.  This is added by default if no transformer is specified.


Here's an example of how to interact with the MessageBus in my current implementation:

:

override protected function initializeFacade() : void
{
super.initializeFacade();

// Setup message bus connection.
var messageBus : MessageBus = MessageBus.getInstance();
messageBus.registerFacade(NAME, this);

messageBus.registerTransformer(NAME, SessionMessage.LOGIN, new SessionMessageTransformer());
messageBus.registerTransformer(NAME, SessionMessage.LOGOUT, new SessionMessageTransformer());
}

And here's an example of sending a message

:

MessageBus.getInstance().sendMessage(new SessionMessage(SessionMessage.LOGIN));

The message bus receives the message, uses the module-provided transformer to transform the message into a notification specific to the module, and uses the module's facade to send it.

In this way, all messages sent are propagated as notifications to each Facade registered to the message bus.

The only coupling between modules is to the MessageBus, and to the Messages that will be shared between Modules of an application.

Let me know if this would be a valuable contribution to the project!
Russ

Thanks for the quick response.  I came up with an alternative solution that's pretty clean.

For those that are interested, here's an explanation.

First, I've been using mx.rpc.IResponder implementations to handle remote service responses. To make these implementations useful to puremvc they extend the framework provided Notifier object.

Second, I created a URLParametersProxy. URL parameters, like any other data in an application are a model. After realizing that it was an easy decision on where to put & how to get the parameters.

Last, I moved the logic of deciding whether to confirm the user's registration or show an error message to the IResponder implementation. Since the Responder has a reference to the Facade, I can get the email token via the URLParametersProxy. At that point its a simple matter of either calling the AccountProxy to confirm the registration, or sending a notification to show the error message.

This eliminates a number of objects and moves the logic of how the remote service is interacted with back into its Proxy.

Thanks again for the framework, its been a pleasure to work with so far.

Hi!

I have the following scenario and haven't found any examples where this is done.

I have an account management application that sends out emails to users to confirm registration. In this email is a link to the account management application with an encrypted token used to verify that the user received the email.

The user uses this link to open the flex application and log in. Based on the account status, the flex application gets a signal telling it that the registration needs to be confirmed.

I wanted to get suggestions on how to implement this with puremvc and have the responsibilities in the right place.

Here's what I'm planning so far:

• AccountProxy receives signal from the server and sends a notification.
• ApplicationMediator reacts to the notification, getting the email token from the mx.core.Application.application.parameters Array.
• ApplicationMediator sends a new "confirmRegistration" notification with the data needed to confirm the registration.
• ConfirmRegistrationCommand reacts to the "confirmRegistration" notification and either calls the AccountProxy to confirm registration with the server, or if the email token isn't set (the user didn't use the email link to log in) sends notification to display a message to the user.

Something about it just seems odd, since the ApplicationMediator is involved only to pick up data needed to confirm the registration. Any suggestions on a cleaner solution?

Thanks!
Russ

I agree with you about the Mediator's responsibilities. I like your comparison of it to a fitting between the view and the framework. In the application I'm developing, I've made sure to keep any view logic in the view, and simply invoke it through the mediator.

As for the ViewHelper and code-behind patterns, after using Cairngorm for several projects, I decided ViewHelpers added complexity that wasn't helpful. Code-behind sounds like it does something similar for the sake of keeping behavior and markup separated.

I forgot to mention that in the scenario I described for using functions as handlers for notifications, the functions would be declared as private on the Mediator, and certainly not exposed to the rest of the system.

Having said that, I think we're on the same page conceptually on the 'Dead Mediator' so I'm done piping in on it.

I'm happy to hear that there will be a contribution site.  This is one thing that the other flex frameworks out there are missing, and will definitely help boost PureMVC's success.

Hi Guys,

First, great job on PureMVC, Cliff.

I wanted to pipe in on this discussion because today at work I implemented an alternative Mediator.  From the looks of the discussion, someone else has had the same idea.

Here's a quick overview...I extended the Mediator provided by the framework and added a method registerNotificationHandler(notificationName : String, handler : Function) : void. Internally, the mediator maintains a Dictionary of notification names, each with an associated ArrayCollection. Each time registerNotificationHandler is called, the function passed in is added to the corresponding Dictionary entry. This allows a generic implementation of listNotificationInterests and handleNotification. listNotificationInterests now simply returns the keys in the Dictionary. Similarly, handleNotification gets the Dictionary entry for the notification and loops through the collection, calling each handler function.

This adds a little bit of power to the mediator, since now you can add multiple handlers for each notification.

Relating to the current discussion, I'd like to offer an alternative way of looking at the switch statement.  Each case, no matter how simple the actions inside may be, is still a unit of work.  As a matter of preference, I like to put units of work into functions. However, at the end of the day, to switch or not to switch is a matter of preference.

That having been said, I would suggest allowing users to contribute alternative implementations of PureMVC interfaces to expand the framework. As a user of the framework, I'd like to have the option of using one implementation over another when I have a use for it. As Cliff has said, the user can take it or leave it as they please.  Allowing contributions to the framework, however, gives users access to common solutions instead of having to roll their own.

I realize that accepting contributions would need to under go some review process to make sure the appropriate unit tests and documentation are provided.  If PureMVC was mine, I wouldn't want contributed code marring its reputation.

At any rate, I guess my overall thought on this discussion is, "Why not have both?"

Cliff, what are your thoughts?

I work in a team environment where I believe it will be beneficial to have custom Notification objects with typed payloads.  For example, I'll have a LoginNotification that would carry a username and password.

The primary reason is so other developers on my team can look at the Notification's definition and know exactly what information they can expect from it.  This way once all the notifications are laid out for an application, my team can code away without needing to check with one another to know what information a notification will contain etc.

The decision I'm faced with is where to put the Notification classes.  Initially I thought that I would put them with the components that send them, but soon found that locating a particular Notification wasn't intuitive.

A second approach is to put the Notification classes in the same package as the ApplicationFacade.  This is similar to defining all the names of your Notifications as static constants within the ApplicationFacade.as file.

A third possibility is to simply add a 'notification' package along with the 'model','view', and 'controller' packages.

Has anyone else had taken the custom notification approach?  Have any suggestions on how to organize the Notification classes?