Dave Keen

Silverstripe – overview and impressions

devdave — Tue, 15 Dec 2009 12:51:41 +0000

I have recently been doing quite a lot of work with Silverstripe, a new(ish) open-source PHP MVC framework with an integrated CMS developed by a company in New Zealand. Silverstripe has been gaining some decent support over the last year due to its interface, usability and extensibility.

How does it work?

Silverstripe is made up of two elements. The first, and most important, is Sapphire. This is a PHP based MVC framework, similar in many ways to Ruby on Rails. It provides support for views (via a custom templating language), controllers and models. Models have a number of special static attributes which provide Sapphire with information about the model; for example, which fields should exist in the database for the model and their datatypes are contained in the $db attribute, one-to-many relationships are defined in $has_many, and many more. Sapphire then implements a database rebuild task which brings the database up to date with any changes in the code; this can either be run in the browser or from the command line for use in deployment and build scripts. On a lower level Sapphire’s base Object.php class implements a kind of PHPified mixin system using the concept of extensions. Unfortunately PHP isn’t really the best language for this kind of thing, but given the limitations and as long as you remember to follow some rules this is a fairly powerful system for extending and decorating objects.

The second part of the system is the Silverstripe CMS module. This is a web application built on Sapphire (just as any site you create will be another web application built on Sapphire) which implements a very nice AJAX based CMS for your site with a tree on the left hand side and a content area on the right hand side. The basic CMS is sufficient for most simple sites, but it can be extended hugely using extensions, decorators and plugins.

The CMS module uses the object extension system to add a number of CMS specific special attributes to the model such as $allowed_children, $icon and $default_child which set various properties and permissions on the tree when that particular model is used in the CMS, and you can override getCMSFields() in the model to specify which fields are editable for a particular page, what kind of editors to use and which database fields they link to. For example, the following in a Silverstripe model will create a natty CMS editor with a checkbox, title and HTML editor (using tiny_mce2) which automatically populates and saves to the database. Nice eh?

   1: static $db = array(   2:     ‘YesNo’ => ‘Boolean’,   3:     ‘Title’ => ‘Text’,   4:     ‘ContentHTMLText’ => ‘HTMLText’,   5: );   6:     7: function getCMSFields() {   8:     $fields = parent::getCMSFields();   9:    10:     $fields->addFieldsToTab(‘Root.Content.Main’, array(  11:         new CheckboxField(‘YesNo’, ‘Check for yes’),  12:         new TextField(‘Title’, ‘Enter title’),  13:         new HTMLEditorField(‘Content’)  14:     ));  15: }

Views and the templating language

Sapphire implements its own basic templating language (in *.ss files). Its quite limited when compared to a more mature product like Smarty, but most of the time it is sufficient for what you will need. You can embed another templates within a template, and access methods in the controller. Occasionally this forces you to put logic in the controller or model that really belongs in the view, but conversely it stops you overloading your views with logic that doesn’t belong there

Impressions

Silverstripe is still a fairly young system and there are a few middling to serious problems with it. Some specific things are problems with using the draft/published versioning system together with has_many relationships, issues with deployment when using staging and live servers, lack of hierarchical URLs and a number of other things that pop up from time to time. However, we have just deployed a global Flash/HTML solution for a large company with multiple content editors; most of the way has been plain sailing and we never encountered an issue with Silverstripe that couldn’t be worked around one way or another.

In summary Sapphire/Silverstripe is a great piece of software and I recommend it to all web developers everywhere! Its open source so it will continue to be improved by the community and I have no doubt that Silverstripe’s major problems will be addressed in the next few iterations. The official ‘Silverstripe book’ has just been released in English which will no doubt help bring the system to a larger market.

Silverstripe (commercial) – www.silverstripe.com

Silverstripe (open source) – www.silverstripe.org

Silverstripe book (Amazon UK) - http://www.amazon.co.uk/SilverStripe-Complete-Guide-Development-Wiley/dp/0470681837

Getting the Class of an object in AS3

devdave — Tue, 04 Nov 2008 15:45:19 +0000

A quick and useful titbit: in order to get the class of an object use the following code:

static function getClass(obj:Object):Class {
    return Class(getDefinitionByName(getQualifiedClassName(obj)));
}

This is great for checking the type of an object. For example, if you have an object myObj1 and you want to confirm that it is of the same type as myObj2 you can write:

if (myObj1 is getClass(myObj2)) {
    trace(“These objects are of the same class!”);
}

Watch and learn - Data binding in Flex

devdave — Wed, 24 Sep 2008 12:36:31 +0000

My apologies to those of you who are watching my blog for updates - I’ve been working flat out on a number of exciting projects over the last few months including a plugin-based XML editor written in Flex which will be released as open source software in the coming weeks.

In the meantime I wanted to point everyone’s attention to this brilliant lecture which explains Flex data binding at the compiler level and finally tells us what [Bindable] really does, why we need to use ArrayCollection instead of Array and all the other internals of Flex architecture which the official docs gloss over.

http://www.onflex.org/ted/2008/08/diving-in-data-binding-waters-with.php

PureMVC Tutorial - Flex, PureMVC, Jabber and XIFF 3: Conclusion, Demo & Downloads

devdave — Sat, 19 Jul 2008 17:19:52 +0000

Introduction
Part 1 - Frameworks
Part 2 - Directory structure
Part 3 - Application and ApplicationFacade
Part 4 - Notifications, Commands & Use Cases
Part 5 - Model & Proxy
Part 6 - The Application View & Mediator
Part 7 - The Login View & Mediator
Part 8 - The Roster View & Mediator
Part 9 - The Chat View & Mediator
Conclusion, Demo & Downloads

Here is a working demo of the application!

If you get a ‘Security Error’ when trying to connect, it means that the particular Jabber server you are connecting to hasn’t implemented its crossdomain.xml file correctly (many servers leave out the content-type which means that the latest versions of Flash Player will refuse to load it). Anyway, this security policy is ignored when running from your local machine so even if you have trouble using it here it will work fine when you compile it yourself.

You can download the full source code for the project here.

If you spot any mistakes, want to have a lively discussion or just want to say how much you enjoyed this tutorial please feel free to leave comments on the appropriate page!

My thanks go out to Jive Software for XIFF, Cliff Hall for PureMVC and all Flashers everywhere

Dave

PureMVC Tutorial - Flex, PureMVC, Jabber and XIFF 3: Part 9 - The Chat View & Mediator

devdave — Sat, 19 Jul 2008 16:34:39 +0000

The final mediator, and the final actor in our application. The job of the chat view is to popup a window where you receive and send message to another user. You should be able to open multiple chat windows at once, and each window is bound to a specific and unique JID.

I’m just going to present the code for this with a short explanation of anything odd rather than explicitly go through the steps. If you have trouble understanding anything go back to the previous sections on mediators and read them through again.

ChatView.mxml

“1.0″ encoding=“utf-8″?>
“http://www.adobe.com/2006/mxml” title=“” showCloseButton=“true”>
    
        
        import mx.formatters.DateFormatter;
        import org.davekeen.xiffer.events.ChatEvent;
        import org.jivesoftware.xiff.core.JID;
        import org.jivesoftware.xiff.data.Message;

        private var jid:JID;

        /**
         * The send button was clicked so dispatch an event to the mediator
         */
        private function sendClick():void {
            var inputText:String = inputTextArea.text;

            if (inputText && inputText.length > 0) {
                dispatchEvent(new ChatEvent(ChatEvent.SEND_MESSAGE, jid, inputText));
                inputTextArea.text = "";
            }
        }

        public function setJID(jid:JID):void {
            this.jid = jid;

            title = jid.toBareJID();
        }

        public function getJID():JID {
            return jid;
        }

        /**
         * Format and add a message to the chat pane
         * 
         * @param    message
         */
        public function addMessage(message:Message):void {
            var dateFormatter:DateFormatter = new DateFormatter();
            dateFormatter.formatString = "HH:NN";
            chatTextArea.text += "[" + dateFormatter.format(new Date()) + "] " + message.body + “\n”;
        }

        ]]>
    
    
        “false” width=“270″ height=“200″ id=“chatTextArea” />
        
            “210″ height=“40″ id=“inputTextArea” />
            “sendButton” width=“50″ height=“40″ label=“Send” click=“sendClick()” />
        
    



ChatMediator.as

There is something slightly different about this view compared to the Login or Roster views. The chat windows are dynamically created when needed and thrown away when they are closed by the user so we can’t have a permanent view component as the viewComponent of ChatMediator.as. Instead we’ll pass the top level Application.mxml component since this is what’s required in the arguments of PopupManager.addPopup.

/*
 Mediator - PureMVC
 */
package org.davekeen.xiffer.view {
    import flash.display.DisplayObject;
    import flash.display.DisplayObjectContainer;
    import flash.events.Event;
    import mx.managers.PopUpManager;
    import mx.managers.PopUpManagerChildList;
    import org.davekeen.xiffer.ApplicationFacade;
    import org.davekeen.xiffer.events.ChatEvent;
    import org.jivesoftware.xiff.core.JID;
    import org.jivesoftware.xiff.data.Message;
    import org.puremvc.as3.interfaces.IMediator;
    import org.puremvc.as3.interfaces.INotification;
    import org.puremvc.as3.patterns.mediator.Mediator;
    import org.davekeen.xiffer.view.*;
    import org.davekeen.xiffer.view.components.ChatView;

    /**
     * Chat Mediator - controls and stewards all popup chat windows
     */
    public class ChatMediator extends Mediator implements IMediator {

        // Cannonical name of the Mediator
        public static const NAME:String = “ChatMediator”;

        /**
         * An associative array of open ChatViews
         */
        private var chatViews:Array;

        public function ChatMediator(viewComponent:Object) {
            // pass the viewComponent to the superclass where 
            // it will be stored in the inherited viewComponent property
            super(NAME, viewComponent);

            chatViews = new Array();
        }

        /**
         * Get the Mediator name.
         * 

         * Called by the framework to get the name of this
         * mediator. If there is only one instance, we may
         * define it in a constant and return it here. If
         * there are multiple instances, this method must
         * return the unique name of this instance.

         * 
         * @return String the Mediator name
         */
        override public function getMediatorName():String {
            return ChatMediator.NAME;
        }

        /**
         * List all notifications this Mediator is interested in.
         * 

         * Automatically called by the framework when the mediator
         * is registered with the view.

         * 
         * @return Array the list of Nofitication names
         */
        override public function listNotificationInterests():Array {
            return [
                    ApplicationFacade.OPEN_CHAT_WINDOW,
                    ApplicationFacade.RECEIVE_MESSAGE,
                    ApplicationFacade.VALID_LOGIN,
                    ApplicationFacade.DISCONNECT
                    ];
        }

        /**
         * Handle all notifications this Mediator is interested in.
         * 

         * Called by the framework when a notification is sent that
         * this mediator expressed an interest in when registered
         * (see listNotificationInterests.

         * 
         * @param INotification a notification 
         */
        override public function handleNotification(note:INotification):void {
            switch (note.getName()) {
                case ApplicationFacade.OPEN_CHAT_WINDOW:
                    var jid:JID = note.getBody() as JID;
                    showChatWindow(jid);
                    break;
                case ApplicationFacade.RECEIVE_MESSAGE:
                    var message:Message = note.getBody() as Message;

                    // Add the message to the view
                    chatViews[message.from.toBareJID()].addMessage(message);
                    break;
                case ApplicationFacade.VALID_LOGIN:
                    // Enable all chat windows
                    for each (var chatView:ChatView in chatViews)
                        chatView.enabled = true;

                    break;
                case ApplicationFacade.DISCONNECT:
                    // Disable all chat windows
                    for each (chatView in chatViews)
                        chatView.enabled = false;

                    break;
                default:
                    break;
            }
        }

        /**
         * Open up a chat window for this particular JID
         * 
         * @param    jid
         */
        private function showChatWindow(jid:JID):void {
            // If the window exists already don’t do anything
            if (!chatViews[jid.toBareJID()]) {
                var chatView:ChatView = new ChatView();

                PopUpManager.addPopUp(chatView, viewComponent as DisplayObjectContainer, false);
                PopUpManager.bringToFront(chatView);
                PopUpManager.centerPopUp(chatView);

                chatView.addEventListener(Event.CLOSE, onChatViewClose);
                chatView.addEventListener(ChatEvent.SEND_MESSAGE, onSendMessage);
                chatView.setJID(jid);

                // Add the chat view to the associative array
                chatViews[jid.toBareJID()] = chatView;
            }
        }

        /**
         * The user has typed a message and sent it
         * 
         * @param    chatEvent
         */
        private function onSendMessage(chatEvent:ChatEvent):void {
            var chatView:ChatView = chatEvent.currentTarget as ChatView;

            // Construct a XIFF message
            var message:Message = new Message(chatEvent.getJID(), null, chatEvent.getMessage(), null, Message.CHAT_TYPE);

            // Echo it to our own view
            chatViews[chatView.getJID().toBareJID()].addMessage(message);

            // And send off a notification
            sendNotification(ApplicationFacade.SEND_MESSAGE, message);
        }

        /**
         * The chat window has been closed
         * 
         * @param    event
         */
        private function onChatViewClose(event:Event):void {
            var chatView:ChatView = event.currentTarget as ChatView;
            chatView.removeEventListener(Event.CLOSE, onChatViewClose);
            PopUpManager.removePopUp(chatView);

            // Delete the chat view from the associative array
            delete chatViews[chatView.getJID().toBareJID()];
        }

    }
}

SendMessageCommand.as

/*
Simple Command - PureMVC
 */
package org.davekeen.xiffer.controller {
    import org.davekeen.xiffer.events.ChatEvent;
    import org.davekeen.xiffer.model.XMPPProxy;
    import org.jivesoftware.xiff.data.Message;
    import org.puremvc.as3.interfaces.INotification;
    import org.puremvc.as3.patterns.command.SimpleCommand;
    import org.puremvc.as3.patterns.observer.Notification;

    /**
     * Send a message to the proxy
     */
    public class SendMessageCommand extends SimpleCommand {

        override public function execute(note:INotification):void {
            var message:Message = note.getBody() as Message;
            var xmppProxy:XMPPProxy = facade.retrieveProxy(XMPPProxy.NAME) as XMPPProxy;

            // Send the message
            xmppProxy.sendMessage(message);
        }

    }
}

And there it is! A working Jabber, Flex and PureMVC application of your very own.

Let’s wrap it all up with a conclusion, a working demo and the full source code.

PureMVC Tutorial - Flex, PureMVC, Jabber and XIFF 3: Part 8 - The Roster View & Mediator

devdave — Sat, 19 Jul 2008 16:33:29 +0000

By now you should be becoming a bit of an old hand at this PureMVC lark, so I’m going to be explaining stuff in a bit less detail. If you get stuck re-read the previous sections until you have everything clear in your head.

The Roster is very simple. We want a Flex DataGrid displaying usernames and login status and we need a ‘Start chat…’ button that opens a chat window.

In order to implement this view we’ll need a new event called ChatEvent.as. The JID class is part of the XIFF framework and is used to identify a Jabber user. The RosterView will only use START_CHAT, but we’ll need SEND_MESSAGE in the next and final view.

   1: package org.davekeen.xiffer.events {   2:     import flash.events.Event;   3:     import org.jivesoftware.xiff.core.JID;   4:        5:     /**   6:     * This event is related to the ChatViews   7:     *    8:     * @author Dave Keen   9:     */  10:     public class ChatEvent extends Event {  11:           12:         public static const START_CHAT:String = "start_chat";  13:         public static const SEND_MESSAGE:String = "send_message";  14:           15:         private var jid:JID;  16:         private var message:String;  17:           18:         public function ChatEvent(type:String, jid:JID, message:String = null, bubbles:Boolean=false, cancelable:Boolean=false) {   19:             super(type, bubbles, cancelable);  20:               21:             this.jid = jid;  22:             this.message = message;  23:         }   24:           25:         public function getJID():JID {  26:             return jid;  27:         }  28:           29:         public function getMessage():String {  30:             return message;  31:         }  32:           33:         public override function clone():Event {   34:             return new ChatEvent(type, jid, message, bubbles, cancelable);  35:         }   36:           37:     }  38:       39: }

We’ll also need to define one new notification in ApplicationFacade.as called OPEN_CHAT_WINDOW:

   1: public static const OPEN_CHAT_WINDOW:String = "open_chat_window";

Next we create our RosterView.mxml file in components:

"1.0" encoding="utf-8"?>
"http://www.adobe.com/2006/mxml" xmlns="*" width="100%" height="100%">
    
  5:         import flash.events.Event;   6:         import mx.events.ListEvent;   7:         import org.davekeen.xiffer.events.ChatEvent;   8:         import org.jivesoftware.xiff.core.JID;   9:           10:         private function onChatClick():void {  11:             if (rosterGrid.selectedItem) {  12:                 // Get the selected item and convert it to a JID  13:                 var jid:JID = new JID(rosterGrid.selectedItem.jid);  14:                   15:                 // Dispatch an event for the mediator  16:                 dispatchEvent(new ChatEvent(ChatEvent.START_CHAT, jid));  17:             }  18:         }  19:           20:         ]]>  21:       22:     "titleWindow" title="Buddy list" enabled="false">  23:         "rosterGrid" editable="false" width="160" height="300" showHeaders="true">  24:               25:                 "displayName" headerText="Username" />  26:                 "online" width="55" headerText="Online?" />  27:               28:           29:         "160" label="Chat…" click="onChatClick()" />  30:       31: 

Add this component to the display list of our top-level Application.mxml component so that the component now reads:

   1: "0" top="0" right="0" bottom="0">   2:     "loginView" />   3:     "30" id="rosterView" />   4: 

Now we need to create RosterMediator.as in the view folder, and register it with PureMVC. Using the rule we applied in the previous section we can see that we need to do this registration in ApplicationMediator.as:

   1: public function ApplicationMediator(viewComponent:Object) {   2:     // pass the viewComponent to the superclass where    3:     // it will be stored in the inherited viewComponent property   4:     super(NAME, viewComponent);   5:        6:     facade.registerMediator(new LoginMediator(application.loginView));   7:     facade.registerMediator(new RosterMediator(application.rosterView));   8: }

All that is left now is to configure our mediator using the same steps as in the previous section.

1. Add listeners

RosterView.mxml dispatches only ChatEvent.START_CHAT so let’s add a listener in the constructor:

   1: public function RosterMediator(viewComponent:Object) {   2:     // pass the viewComponent to the superclass where    3:     // it will be stored in the inherited viewComponent property   4:     super(NAME, viewComponent);   5:        6:     rosterView.addEventListener(ChatEvent.START_CHAT, onStartChat);   7: }   8:     9: private function onStartChat(chatEvent:ChatEvent):void { }

2. Add notifications

The Roster window need to enable and disable depending on whether or not the user is connected to a jabber server, and also needs to fill in the DataGrid with the list of buddies. To achieve these goals the mediator will need to register an interest in ApplicationFacade.VALID_LOGIN and ApplicationFacade.DISCONNECT.

   1: override public function listNotificationInterests():Array {   2:     return [   3:             ApplicationFacade.VALID_LOGIN,   4:             ApplicationFacade.DISCONNECT   5:             ];   6: }

And here are the clauses for the switch statement:

   1: override public function handleNotification(note:INotification):void {   2:     switch (note.getName()) {   3:         case ApplicationFacade.VALID_LOGIN:   4:              break;   5:         case ApplicationFacade.DISCONNECT:   6:             break;   7:         default:   8:             break;           9:     }  10: }

3. Fill in the event listeners and switch clauses

Firstly we’ll fill in the onStartChat event listener. This will very simply send an ApplicationFacade.OPEN_CHAT_WINDOW with the JID as the argument. Although we could have passed the ChatEvent itself as a parameter in this case there is no need to use a value object as to open a chat window we only require a single item of information - the JID.

   1: private function onStartChat(chatEvent:ChatEvent):void {   2:     sendNotification(ApplicationFacade.OPEN_CHAT_WINDOW, chatEvent.getJID());   3: }

You’ll notice that the ApplicationFacade.OPEN_CHAT_WINDOW notification is not mapped to a command - this is because the only responder to the notification will be the ChatMediator that we are about to create in the next section so there is no need to have a command. However, one of the beautiful things about PureMVC is that if it turned out later in the development that this notification needed to affect the model in some way we could implement this merely by adding a new command and registering it, and there will be no need to make any changes to the rest of the application.

Compile and run the application and enjoy the working buddy list! Only one view left to go…

PureMVC Tutorial - Flex, PureMVC, Jabber and XIFF 3: Part 7 - The Login View & Mediator

devdave — Sat, 19 Jul 2008 16:27:58 +0000

In this part of the tutorial we’ll create the login bar, and by the end of this section our application will be able to connect to any XMPP server with a username & password!

In the components package create a new MXML file name LoginView.mxml and in the view package create a new mediator called LoginMediator.as using Add->New Mediator… (if you don’t see this menu item be sure you’ve installed the PureMVC FlashDevelop templates from PureMVC: First thoughts & FlashDevelop templates correctly).

As we explained in the previous section add a helper method to the LoginMediator to cast the viewComponent:

private function get loginView():LoginView {
    return viewComponent as LoginView;
}

Note that in order to get the application to compile you’ll need to explicitly import the LoginView using:

   1: import org.davekeen.xiffer.view.components.LoginView;

Now we want to add the LoginView to the display list by including it in Application.mxml (giving it an id of loginView so we can reference it from the mediator). Add this MXML within the tag (stick it at the end just before ):

“0″ top=“0″ right=“0″ bottom=“0″>
    “loginView” />


Now we need to register our mediator with PureMVC. Now this point is important to understand as it seems to confuse - since LoginView is a sub-component of Application we need to register the view within the Application’s mediator. This can be made into a general rule:

If the mediator you are registering heralds the top level component (i.e. Application.mxml) register it in StartupCommand.
If the mediator you are registering heralds a child of another component register it in the constructor of that component’s mediator.

Just to confuse things I’d better point out that this rule doesn’t apply in quite the same way if you are dynamically creating and removing mediators, but we’ll save that for another tutorial.

Anyway, the upshot of all that is that we call registerMediator in the constructor of ApplicationMediator:

public function ApplicationMediator(viewComponent:Object) {
    // pass the viewComponent to the superclass where 
    // it will be stored in the inherited viewComponent property
    super(NAME, viewComponent);
    
    facade.registerMediator(new LoginMediator(application.loginView));
}

Here is the code for LoginView.mxml. As this is a PureMVC tutorial, not a Flex one, I’m not going to go in any detail about how it works, but these are the only things you need to care about:

When the user clicks ‘Connect’ it dispatches a LoginViewEvent.LOGIN event containing the username, password and server.
When the user clicks ‘DIsconnect’ it dispatches a LoginViewEvent.LOGOUT event.
It exposes a showInvalidLoginAlert() method that pops up a ‘Invalid username/password’ window.

“1.0″ encoding=“utf-8″?>
“http://www.adobe.com/2006/mxml” xmlns=“*” width=“100%” height=“100%”>
    
        
        import mx.controls.Alert;
        import org.davekeen.xiffer.events.LoginViewEvent;
        
        /**
         * Dispatch a connect event to the mediator
         */
        private function onConnectClick():void {
            dispatchEvent(new LoginViewEvent(LoginViewEvent.LOGIN, usernameTextInput.text, passwordTextInput.text, serverComboBox.text));
        }
        
        /**
         * Dispatch a disconnect event to the mediator
         */
        private function onDisconnectClick():void {
            dispatchEvent(new LoginViewEvent(LoginViewEvent.LOGOUT));
        }
        
        /**
         * Enable or disable the connect button depending on whether or not the user has entered something into both username and password fields
         */
        private function usernamePasswordChange():void {
            connectButton.enabled = (usernameTextInput.text.length > 0 && passwordTextInput.length > 0);
        }
        
        /**
         * Show an invalid login alert and clear the username and password fields
         */
        public function showInvalidLoginAlert():void {
            // Popup an alert
            Alert.show("Invalid username/password", "Error", Alert.OK, this);
            
            // Clear the input fields and notify the change handler (this will disable the connect button)
            usernameTextInput.text = "";
            passwordTextInput.text = "";
            usernamePasswordChange();
        }
        
        ]]>
    
    
    “{connectButton}” paddingTop=“0″ paddingBottom=“0″ paddingLeft=“0″ paddingRight=“0″>
        
        
            
            “Username:” selectable=“false” fontSize=“14″ />
            “usernameTextInput” width=“100″ change=“usernamePasswordChange()” />
            
            “Password:” selectable=“false” fontSize=“14″ />
            “passwordTextInput” change=“usernamePasswordChange()” displayAsPassword=“true” width=“100″ />
            
            “Server:” fontSize=“14″ />
            “serverComboBox” editable=“true”>
                
                    jabber.se
                    jabber.org
                
            
            
            “connectButton” label=“Connect” enabled=“false” click=“onConnectClick()” />
            “disconnectButton” label=“Disconnect” enabled=“false” click=“onDisconnectClick()” />
            
        
        
    
    


We’ll also need to create the custom LoginViewEvent (in the events folder):

package org.davekeen.xiffer.events {
    import flash.events.Event;
    
    /**
    * Events passed between the login view component and its mediator
    * 
    * @author Dave Keen
    */
    public class LoginViewEvent extends Event {
        
        public static const REGISTER:String = “login_view_register”;
        public static const LOGIN:String = “login_view_login”;
        public static const LOGOUT:String = “login_view_logout”;
        
        private var username:String;
        private var password:String;
        private var server:String;
        
        public function LoginViewEvent(type:String, username:String = null, password:String = null, server:String = null, bubbles:Boolean = false, cancelable:Boolean = false) { 
            super(type, bubbles, cancelable);
            
            this.username = username;
            this.password = password;
            this.server = server;
        }
        
        public function getUsername():String {
            return username;
        }
        
        public function getPassword():String {
            return password;
        }
        
        public function getServer():String {
            return server;
        }
        
        public override function clone():Event { 
            return new LoginViewEvent(type, username, password, server, bubbles, cancelable);
        }
        
    }
    
}

Now we’re ready to start the interesting bit - implementing our LoginMediator. These are the steps I take when implementing a mediator:

Add listeners for all the events dispatched from the view component to the constructor and create event listener methods for them.
Identify which notifications this mediator is interested in and add them to the listNotificationInterests method’s array and the handleNotification method’s switch statement.
Fill in the event listener methods and switch statement clauses.

Now we’ll do each of these steps in turn for our LoginMediator.

1. Add listeners

Our view component dispatches LoginViewEvent.LOGIN and LoginViewEvent.LOGOUT event, so we’ll add our listeners in the constructor and add two empty event listener methods:

public function LoginMediator(viewComponent:Object) {
    // pass the viewComponent to the superclass where 
    // it will be stored in the inherited viewComponent property
    super(NAME, viewComponent);
    
    loginView.addEventListener(LoginViewEvent.LOGIN, onConnectClick);
    loginView.addEventListener(LoginViewEvent.LOGOUT, onDisconnectClick);
}
  
/**
 * The connect button was clicked in the view
 * 
 * @param    loginViewEvent
 */
private function onConnectClick(loginViewEvent:LoginViewEvent):void { }
  
/**
 * The disconnect button was clicked in the view
 * 
 * @param    loginViewEvent
 */
private function onDisconnectClick(loginViewEvent:LoginViewEvent):void { }

2. Add notifications

The login view is interest in knowing if a client is connected or not (so that it can enable/disable the ‘Connect’ & ‘Disconnect’ buttons accordingly. It is also interested in knowing if a login attempt was invalid so that it can popup the ‘Invalid username/password’ alert. This translates into listening for ApplicationFacade.VALID_LOGIN, ApplicationFacade.INVALID_LOGIN and ApplicationFacade.DISCONNECT.

Firstly we’ll add these to the listNotificationInterests method:

override public function listNotificationInterests():Array {
    return [
            ApplicationFacade.VALID_LOGIN,
            ApplicationFacade.INVALID_LOGIN,
            ApplicationFacade.DISCONNECT
            ];
}

Now we’ll add empty clauses for each notification in the handleNotification method’s switch statement:

override public function handleNotification(note:INotification):void {
    switch (note.getName()) {
        case ApplicationFacade.VALID_LOGIN:
            break;
        case ApplicationFacade.INVALID_LOGIN:
            break;
        case ApplicationFacade.DISCONNECT:
            break;
        default:
            break;        
    }
}

3. Fill in the event listeners and switch clauses

Let do the switch clauses first. Its all simple stuff - in the event of a valid login we want to enable the ‘Disconnect’ button and disable the ‘Connect’ button, in the event of a disconnect we want to enable the ‘Connect’ button and disable the ‘Disconnect’ button, and in the event of an invalid login we want to popup the ‘Invalid username/password’ alert box:

override public function handleNotification(note:INotification):void {
    switch (note.getName()) {
        case ApplicationFacade.VALID_LOGIN:
            loginView.connectButton.enabled = false;
            loginView.disconnectButton.enabled = true;
            break;
        case ApplicationFacade.INVALID_LOGIN:
            loginView.showInvalidLoginAlert();
            break;
        case ApplicationFacade.DISCONNECT:
            loginView.connectButton.enabled = true;
            loginView.disconnectButton.enabled = false;
            break;
        default:
            break;        
    }
}

And now lets fill in our event listeners. Again, these are very simple - all they do is send the appropriate notification which will then get auto-mapped to the appropriate command - in this case either LoginCommand or LogoutCommand.

private function onConnectClick(loginViewEvent:LoginViewEvent):void {
    sendNotification(ApplicationFacade.LOGIN, loginViewEvent);
}
  
private function onDisconnectClick(loginViewEvent:LoginViewEvent):void {
    sendNotification(ApplicationFacade.LOGOUT, loginViewEvent);
}

Notice that for the parameter of the notifications I am just passing the same LoginViewEvent we received from the view component. It could be argued that this breaks encapsulation as the commands shouldn’t really know anything about events. However, after coding a few PureMVC projects I’ve noticed that its very common for the event you receive from the view to contain the same bits of information needed by the relevant command - in this case LoginCommand needs to know the username, password and server which is exactly the information contained in a LoginViewEvent. Because of this I don’t really see the need to create an extra object, and when passing an event as notification parameter I just think of it as a value object instead of an event, but you are certainly justified in taking another view on this.

Now that we have the mediator calling the LoginCommand and LogoutCommand we’d better fill these in. Commands can do various different things, but a very common pattern for commands, and what we’ll be using here, is:

Retrieve the proxy we want to do something with using retrieveProxy.
Call a method on that proxy, possibly with parameters ripped out of the notification parameter.

With that in mind we can very simply implement LoginCommand.as:

override public function execute(note:INotification):void {
    var loginViewEvent:LoginViewEvent = note.getBody() as LoginViewEvent;
    var xmppProxy:XMPPProxy = facade.retrieveProxy(XMPPProxy.NAME) as XMPPProxy;
    
    xmppProxy.connect(loginViewEvent.getUsername(), loginViewEvent.getPassword(), loginViewEvent.getServer());
}

… and LogoutCommand.as:

override public function execute(note:INotification):void {
    var xmppProxy:XMPPProxy = facade.retrieveProxy(XMPPProxy.NAME) as XMPPProxy;
    
    xmppProxy.disconnect();
}

Guess what? We have a working application! Compile the application and play about with it - you’ll be able to log in and out of Jabber servers to your heart’s content :) If you download a proper jabber client (http://www.jabber.org/clients has a big list of clients for various platforms) you’ll be able to see your user coming on and offline as you click ‘Connect’ and ‘Disconnect’.

Be proud! All that’s left for us to do now is to create a buddy list (called the Roster in Jabber parlance) and the chat windows themselves. If you’ve come this far maybe you’d like to have a go yourself without reading further. If not, read on - Roster view here we come.

PureMVC Tutorial - Flex, PureMVC, Jabber and XIFF 3: Part 6 - The Application View & Mediator

devdave — Sat, 19 Jul 2008 16:23:25 +0000

Congratulations on getting this far - we’re getting closer to our working Jabber client :) Before we get going with our first top-level mediator we’ll talk about views in a little more detail. In PureMVC a view consists of:

One or more view components. This is the thing that the user actually sees and interacts with - in Flash it will be a Sprite or MovieClip, and in Flex it will be an MXML file (or an AS file extending a flex component).
A mediator. This is the PureMVC bit of the view and ‘heralds’ the view components. Any interaction with the rest of the application is done through the mediator. Note that although the mediator knows about the existence of the view components, the view components don’t know about existence of the mediator!
Events. Although not strictly a part of the view, I find it helpful to think of events within the same bundle. View components communicate with their mediator via events and its common to create custom events for various interactions within the view component. For example, when we come to the Login view we’re going to be dispatching a custom LoginViewEvent to the LoginMediator when the user clicks on the ‘connect’ button.

PureMVC makes no assumptions about the way that you structure the tree of views and mediators, apart from requiring that there is one top-level mediator. In the words of our great leader, Cliff Hall (the creator of PureMVC):

It is up to you as a developer to determine the granularity of the View Component that is handled a given Mediator. If a Mediator becomes too bloated dealing with all the children of its View Component simply create a Mediator for the more complicated child. For instance, if the child components of the Application instance are complicated enough to justify their own Mediators, then the ApplicationMediator typically creates and registers the appropriate Mediator for each of those children.

This means that you start off with one mediator for your application entry point (i.e. Application.mxml) and then add extra mediators as needed. In general you tend to have one mediator per visual ’section’ of your application, but this is by no means enforced.

Create our ApplicationMediator.as in the view folder with Add->New Mediator… (if you don’t see this menu item be sure you’ve installed the PureMVC FlashDevelop templates from PureMVC: First thoughts & FlashDevelop templates correctly).

At this point its a good idea to add in a helper method to allow you to retrieve the view component that this mediator is looking after (in this case Application.mxml). To do this add the following private getter:

private function get application():Application {
    return viewComponent as Application;
}

This saves having to constantly case viewComponent to the correct class every time we use it. Unfortunately I couldn’t find a way to get a FlashDevelop template to downcase the class name so we can’t generate this function within the template, but you’ll soon get into the habit of typing it each time you create a new mediator.

Finally we need to add our new mediator to PureMVC using the registerMediator command in StartupCommand. The execute method in this command should now read:

override public function execute(notification:INotification):void {
    facade.registerProxy(new XMPPProxy());
    
    facade.registerMediator(new ApplicationMediator(notification.getBody() as Application));
}

Notice the argument passed to the Mediator - this is the view component that the mediator is supposed to look after (in this case Application.mxml). notification.getBody() retrieves the argument passed along with the notification, and since we sent the notification (in Application.mxml) using facade.sendNotification(ApplicationFacade.STARTUP, this) that argument will be the Application object itself!

Now we’ll create the Login view and mediator.

PureMVC Tutorial - Flex, PureMVC, Jabber and XIFF 3: Part 5 - Model & Proxy

devdave — Sat, 19 Jul 2008 16:19:57 +0000

The model is the ‘data’ of our application and the proxy is our interface onto that data. For our particular application the model itself is basically our Jabber connection object, so the Proxy will encapsulate that and expose an interface with the following methods:

connect(username:String, password:String, server:String):void
disconnect():void
sendMessage(message:Message):void
getRosterDataProvider():ArrayCollection

As you can see, the interface is very similar to our use case and commands, and this in no coincidence; each command is going to call the relevant method in its execute method.

Create a Proxy in the model folder called XMPPProxy.as using Add->New Proxy… (if you don’t see this menu item be sure you’ve installed the PureMVC FlashDevelop templates from PureMVC: First thoughts & FlashDevelop templates correctly).

I’m just going to include the Proxy code here without much explanation as it doesn’t really do anything overly complicated (all of the hard stuff has been done for us in the XIFF library ) Have a read through the comments of each method and everything should be clear.

/*
Proxy - PureMVC
*/
package org.davekeen.xiffer.model {
    import flash.events.Event;
    import flash.system.Security;
    import org.davekeen.xiffer.ApplicationFacade;
    import org.jivesoftware.xiff.core.JID;
    import org.jivesoftware.xiff.core.XMPPSocketConnection;
    import org.jivesoftware.xiff.data.Message;
    import org.jivesoftware.xiff.data.Presence;
    import org.jivesoftware.xiff.events.*
    import org.jivesoftware.xiff.im.Roster;
    import org.puremvc.as3.interfaces.IProxy;
    import org.puremvc.as3.patterns.proxy.Proxy;
    import mx.collections.ArrayCollection;
  
    /**
     * Proxy to XMPP server
     */
    public class XMPPProxy extends Proxy implements IProxy {
        
        public static const NAME:String = “XMPPProxy”;
        
        private var xmppSocketConnection:XMPPSocketConnection;
        private var roster:Roster;
  
        public function XMPPProxy(data:Object = null) {
            super(NAME, data);
            
            setupConnection();
            configureListeners();
        }
        
        /**
         * Create the required XMPP objects and do any configuration on them that we might require
         */
        private function setupConnection():void {
            xmppSocketConnection = new XMPPSocketConnection();
            
            roster = new Roster();
            roster.connection = xmppSocketConnection;
        }
        
        private function configureListeners():void {
            // Add event listeners related to the connection
            xmppSocketConnection.addEventListener(LoginEvent.LOGIN, onLogin);
            xmppSocketConnection.addEventListener(XIFFErrorEvent.XIFF_ERROR, onXiffError);
            xmppSocketConnection.addEventListener(DisconnectionEvent.DISCONNECT, onDisconnect);
            
            // Add event listeners related to messages
            xmppSocketConnection.addEventListener(MessageEvent.MESSAGE, onMessage);
            
        }
        
        /**
         * Attempt to connect to a XMPP server
         * 
         * @param    username
         * @param    password
         * @param    server
         */
        public function connect(username:String, password:String, server:String):void {
            // Attempt to load a crossdomain permissions file
            Security.loadPolicyFile(server + “/crossdomain.xml”);
            
            // Connect using standard profile
            xmppSocketConnection.username = username;
            xmppSocketConnection.password = password;
            xmppSocketConnection.server = server;
            xmppSocketConnection.connect(“standard”);
        }
        
        /**
         * Disconnect from a XMPP server.  If not currently connected this will have no effect.
         * 
         */
        public function disconnect():void {
            xmppSocketConnection.disconnect();
        }
        
        /**
         * Return the roster as a data provider
         * 
         * @return
         */
        public function getRosterDataProvider():ArrayCollection {
            return roster;
        }
        
        /**
         * Send a message to the server
         * 
         * @param    message
         */
        public function sendMessage(message:Message):void {
            xmppSocketConnection.send(message);
        }
        
        /**
         * The user has successfully logged on to the XMPP server
         * 
         * @param    connectionSuccessEvent
         */
        private function onLogin(loginEvent:LoginEvent):void {
            roster.setPresence(Presence.SHOW_CHAT, “”, 0);
            
            sendNotification(ApplicationFacade.VALID_LOGIN);
        }
        
        /**
         * There has been a Jabber error - most likely an incorrect username/password error
         * 
         * @param    xiffErrorEvent
         */
        private function onXiffError(xiffErrorEvent:XIFFErrorEvent):void {
            if (xiffErrorEvent.errorCode == 400)
                sendNotification(ApplicationFacade.INVALID_LOGIN);
            
        }
        
        /**
         * The user has disconnected from the XMPP server
         * 
         * @param    disconnectionEvent
         */
        private function onDisconnect(disconnectionEvent:DisconnectionEvent):void {
            sendNotification(ApplicationFacade.DISCONNECT);
        }
        
        /**
         * Received a message from the server
         * 
         * @param    messageEvent
         */
        private function onMessage(messageEvent:MessageEvent):void {
            sendNotification(ApplicationFacade.RECEIVE_MESSAGE, messageEvent.data);
        }
        
    }
}

One thing you will notice is that the proxy dispatches another few notifications that we haven’t included in our ApplicationFacade:

VALID_LOGIN
INVALID_LOGIN
RECEIVE_MESSAGE
DISCONNECT

So lets go back to our ApplicationFacade and add them in:

public static const VALID_LOGIN:String = “valid_login”;
public static const INVALID_LOGIN:String = “invalid_login”;
public static const DISCONNECT:String = “disconnect”;
public static const RECEIVE_MESSAGE:String = “receive_message”;

The final thing we need to do is register our new Proxy with PureMVC. We do this in StartupCommand.as using the registerProxy method:

override public function execute(notification:INotification):void {
    facade.registerProxy(new XMPPProxy());
}

Its quite easy to forget to do this and end up with all kinds of strange errors, so be sure to remember to register any proxies you create.

We’ve finally got the bones of our application up and running so now its on to the views and mediators!

PureMVC Tutorial - Flex, PureMVC, Jabber and XIFF 3: Part 4 - Notifications, Commands & Use Cases

devdave — Sat, 19 Jul 2008 16:18:27 +0000

Notifications are the nuts and bolts of a PureMVC application and are used to communicate between the various actors of your application. Notifications can be used for the following paths of communication:

Mediator -> Mediator
Mediator -> Command
Command -> Command
Command -> Mediator
Proxy -> Mediator
Proxy -> Command

In other words, Commands and Mediators listen out for notifications, and everything can send them. The ‘pattern’ reason for Proxies not being able to directly listen for notifications is to try and encourage the developer to use a command to do this. In other words, if a mediator wanted to effect a change on a proxy it might send a DO_SOMETHING notification, which would invoke DoSomethingCommand which would then retrieve the SomethingProxy and call doSomething() on it. This is less complicated than it sounds and there will be examples of this in the code we’ll be writing.

PureMVC also makes it possible for a mediator to directly retrieve a proxy and call methods on it that change its state, although this is often frowned upon by MVC purists. Having said that, there are some situations when it makes more sense to do this in simple cases rather than run through the Mediator->Command->Proxy chain (probably creating an extra command along the way). Always remember that MVC guidelines are just that - guidelines

Use case diagram

Here’s the use case diagram for our user. Its useful to map these out at the start of the project as there is often a 1-1 mapping between use cases and commands. So now lets create these commands and map them to some notifications (we’ll leave them empty for the moment, but fill them in later).

To add an empty command right-click on the controller folder in the project area and select Add->New SimpleCommand… (if you don’t see this menu item be sure you’ve installed the PureMVC FlashDevelop templates from PureMVC: First thoughts & FlashDevelop templates correctly). Add these three commands:

LoginCommand.as
LogoutCommand.as
SendMessageCommand.as

Now we need to setup our notification. Notification names are just strings, so we need to setup static constants for each one. For larger projects with a lot of notifications its usual to create extra classes to hold the constants, but since we are only going to have a few of them we’ll put them in ApplicationFacade.as.

public static const LOGIN:String = “login”;
public static const LOGOUT:String = “logout”;
public static const SEND_MESSAGE:String = “send_message”;

Now we need to map these notifications to their associated commands. This means that whenever one of these notifications is sent PureMVC will automatically invoke its mapped command. To do this we call the registerCommand method in the initializeController method of ApplicationFacade (note that the STARTUP->StartupCommand notification was already setup in the FlashDevelop ApplicationFacade template).

// Register commands with the controller
override protected function initializeController():void {
    super.initializeController();

    registerCommand(STARTUP, StartupCommand);

    registerCommand(LOGIN, LoginCommand);
    registerCommand(LOGOUT, LogoutCommand);

    registerCommand(SEND_MESSAGE, SendMessageCommand);
}

Now let’s create our XMPP proxy…