I'm working out a responsive design template that may be useful for others.  Showing / hiding of things like top nav and bottom nav is done programmatically, side menu, all that.

How would I begin thinking of this as a puremvc plugin?  I've created many jQuery plugins, so I'm familiar with this format, but a puremvc approach would be different.  I'm trolling for best practices, I guess, since a plugin architecture would open some doors.

Thanks in advance.

I wanted to post this because I'm having a lot of luck with JS-Signals http://millermedeiros.github.com/js-signals/ in the Views and Mediators of a jQuery-based application, specifically around the area of handling user interaction from viewComponent.  Obviously there are alternatives, but this one is turning out to be fairly clean and straightforward.

I'm using:

• PureMVC Javascript http://trac.puremvc.org/PureMVC_JS/browser/branches/native-multicore/
• jQuery http://jquery.com/
• Underscore http://underscorejs.org/

I'm instantiating a new view component on the Mediator's on Register, and calling setViewComponent(). 

:

/**
 * @author Mike Britton
 *
 * @class ScrollerMediator
 *
 *
 *
 */

puremvc.define({
    name : 'rps.view.mediator.ScrollerMediator',
    parent : puremvc.Mediator
},
// INSTANCE MEMBERS
{
    /** @override */
    listNotificationInterests : function() {
        return [rps.AppConstants.NOTE_PAGES_RETRIEVED,rps.AppConstants.NOTE_APP_RESIZE];
    },
    /** @override */
    onRegister : function() {
       
        // Create the viewComponent
        this.setViewComponent(new rps.view.component.ScrollerComponent);
       
        // Establish signal listeners
        this.doSignals();
       
    },
    /** @override */
    handleNotification : function(note) {
        //console.log('ScrollerMediator::handleNotification - ' + note.getName());

        switch (note.getName()) {
            case rps.AppConstants.NOTE_APP_RESIZE:
                this.getViewComponent().updateUI(note.getBody());
                this.doSignals();
                break;
            case rps.AppConstants.NOTE_PAGES_RETRIEVED:
                this.getViewComponent().build(note.getBody());
                break;
        }
    },
    doSignals:function(){
        var target = this;
        $.each(this.getViewComponent().signals, function(index, item) {
           if (!item.has(target.handleEvent)) {
               // Second arg is scope
               item.add(target.handleEvent, target);
           }
        });     
    },
    handleEvent : function(signal) {
       switch(signal){
           case rps.view.component.ScrollerComponent.SIGNAL_READY:
              //console.log('ScrollerMediator::Signal '+signal+' received');
           break;
       };

    }
},
// STATIC MEMBERS
{
    /**
     * @static
     * @type {string}
     */
    NAME : 'ScrollerMediator'
});

Inside the view component, I call build() and use underscore.js to retrieve templates:

:

var comp = _.template($('#stripsTmpl').html());

An underscore template looks like this in HTML:

:

<script type="text/template" id="stripsTmpl">
    <div id="pagesX" class="pagesX" style="width:<%- pagesXWidth %>px;height:<%- pagesXHeight %>px;"></div>
    <div id="pagesY" style="position:absolute;width:<%- pagesYWidth %>px;height:<%- pagesYHeight %>px;"></div>
</script>

Back in my component class, I have public signals[], each key being a new signals.Signal(). In my Mediator, I call doSignals() once the viewComponent has been created, and set a single handler (see above) for all signals.  All user interactions in the viewComponent dispatch Signals back to the Mediator's handleEvent().

Scope issues between viewComponent and Mediator are handled with a Signals context argument:

:

doSignals:function(){
    var target = this;
    $.each(this.getViewComponent().signals, function(index, item) {
       if (!item.has(target.handleEvent)) {
           // Second arg is scope
           item.add(target.handleEvent, target);
       }
    });     
},

Why use Signals?  I don't want to troubleshoot native events until their implementation stabilizes across browsers and platforms.  (At least not for client projects.)  I want to abstract them, to keep my architecture safe from contamination by proprietary hocus-pocus with respect to event programming.  Not sure if this is the right approach, but it feels right.

Hope this proves useful, either directly or as an example of how not to do it!   


Mike

Can't seem to retrieve my proxy once I've registered it:

:

var facade = Facade.getInstance('ApplicationFacade');
   
 facade.registerProxy(new StoryProxy(StoryProxy.NAME, []));

Then elsewhere, after StroyProxy's onRegister fires:

:

var prox = facade.retrieveProxy(StoryProxy.NAME);
console.dir(prox); // undefined

My proxy (probably where the problem is):

:

function StoryProxy(name, component) {
    console.log('new StoryProxy: '+name);
    Proxy.call(name);
}

StoryProxy.prototype = new Proxy;
StoryProxy.prototype.constructor = StoryProxy;

StoryProxy.NAME = 'StoryProxy';

/** @override */
StoryProxy.prototype.initializeNotifier = function() {
    console.log('StoryProxy::initializeNotifier'); 
};
StoryProxy.prototype.onRegister = function() {
    console.log('StoryProxy::onRegister'); 
    var facade = Facade.getInstance('ApplicationFacade');
    facade.sendNotification(Application.NOTE_GET_STORIES);
};

Thanks in advance!

I may be barking up the wrong tree again, but it seems like managing views (Activities) from inside other Activities is bad.  How do I know which Activity is changing the page with an Intent?

Just for the hell of it, I implemented it in a Command.  Now I don't have to wonder which Activity did what; it's all centralized.  Granted it will have to have a case for each page in the application, but I see less scalability issues than with dispatching Intents inside Activities that should have no knowledge or control of them, in theory.

When trying to figure out how to send events from Activities to Mediators, I first created interface InteractionListener for the Mediator to implement:

:

package com.britton.apps.puremvcboilerplate.view;

import com.britton.apps.puremvcboilerplate.view.event.InteractionEvent;

public interface InteractionListener {
public void interactionReceived(InteractionEvent event);
public void configureListeners(InteractionListener m);
}


Implementation in Mediator:

:

@Override
public void onRegister() {
super.onRegister();
configureListeners(this);
}

@Override
public void configureListeners(InteractionListener m) {
this.getApplication().addListener(m);
}

@Override
public void interactionReceived(InteractionEvent event) {
Log.d(TAG, "Event Received");
}


In my experimental app, Activity is subclassed as InteractionActivity (which could also be an abstract class):

:

package com.britton.apps.puremvcboilerplate.view;

import java.util.ArrayList;
import java.util.List;

import android.app.Activity;

public class InteractionEmitterActivity extends Activity {
public List listeners;

public InteractionEmitterActivity() {
listeners = new ArrayList();
}

public synchronized void addListener(InteractionListener il) {
        listeners.add(il);
    }

    public synchronized void removeListener(InteractionListener il) {
        listeners.remove(il);
    }
}


And in ApplicationActivity, the subclass, where there's a Button ready to trigger this miraculous handler:

:

private void initDisplay() {
btn = (Button) findViewById(R.id.button1);
btn.setOnClickListener(new View.OnClickListener() {

public void onClick(View v) {
InteractionEvent ie = new InteractionEvent(this);
Iterator it = listeners.iterator();

while (it.hasNext()) {
InteractionListener il = (InteractionListener) it.next();
il.interactionReceived(ie);
}
}
});
}


So now, any Activity that extends InteractionEmitterActivity can, by contract, send InteractionEvents to the Mediator actor.

Here's the InteractionEvent:

:

package com.britton.apps.puremvcboilerplate.view.event;

import java.util.EventObject;

public class InteractionEvent extends EventObject {

public InteractionEvent(Object source) {
super(source);
}
}

I realize this is very Flex-like; in fact, I kept thinking about Signals when I wrote it!  I've had success with them.  Maybe that's another route.


Mike

In the the AS3 port, my views have event constants defined and I handle them in my Mediators, which then send Notifications.

In the PHP port, I have a Manager class that looks for $_GET or $_POST and uses the Facade to send Notifications.  I'd rather communicate back to my views' Mediators without going through the facade.

Just wondering what you all are doing.

I have an app that has two modes, "default" and "custom".  Default mode means views use a standard set of components; custom mode means views have been customized and should load images for their UI.

Because of this, my views differ significantly enough to warrant creating a mediator for each.  The alternative would introduce a lot of messy conditional logic to the views, which is something I want to keep at a minimum.

So here goes: I have a command that registers these mediators based on boolean flags set in my proxies.  These booleans tell the app whether certain views are "custom" or "default".  How do I refer to the base app, where the views have been instantiated, from my command?

One approach is to store a reference to the main application on the facade, and fire a method on the facade when I'm ready to set the mediators dynamically.

In ApplicationFacade:

:

public function startup( app:VODPlayer ):void
{
this.app = app;
sendNotification( STARTUP, app );
}

public function get app():VODPlayer { return __app; }
public function set app(value:VODPlayer):void { __app = value; }

In the Command:

:

var app:VODPlayer = ApplicationFacade(facade).app;

This doesn't feel like a good technique.  Has anyone come up something more elegant?  Am I missing something simple and obvious?

I don't know what it is, but I can't figure out how to get a simple message to a module from my shell and vice-versa.  I'm working in Flash AS3 only, no Flex.  I'd post code here, but last time I did, the post was removed.  Can anyone give me a step-by-step process?

I must be in a rut because here I am a week later without a clear handle on this.

The demo is great, but as I try to port my architecture to an implementation with Pipes, the complexity of tracing through the demo to decide how to move forward is not conducive to good learning.

May I suggest an all-AS3 example, sans Flex?  I'm having trouble with things like the PipeAwareModule utility extending MovieClip instead of ModuleBase, resulting in the need for an init method to account for MovieClip not accepting constructor arguments.

I'm really excited about Pipes, but have just started with AS3 MultiCore and want to comply with best practices.  When will we get a simple Pipes demo for AS3 MultiCore?