I created a native Javascript port of the PureMVC Pipes Utility.  I also have a Dojo version contained inside my Dojo-PureMVC implementation, but since the PureMVC Native JS port is the defacto standard, I created a matching Pipes version.  Although it probably needs some refinement in places, it appears to work fine for me.

You can get it here and read about it here. 

There is also a src directory with an implementation created with the puremvc.define utility which I like much better.  It makes the OO structure easy to see and understand.  However, since the main PureMVC JS distribution is written with prototypes, the primary src directory follow suit. I've also posted demos showing it in action with the source included on GitHub.  (They are based on Tekool's excellent actionscript Pipes demo)

If anyone wants to add it to the official PureMVC distribution site, I'm fine with that too.   

If anyone needs a dojo version of puremvc that uses AMD loading, you can try the version I ported to work with with Dojo 1.7 with AMD loading.  I also ported the pipes utility which you can find in the utilities package.  I have not ported all the tests over yet, but the implementation seems to work well for my purposes.  I want to eventually use the native puremvc port with dojo but I haven't really figured out the details of how to do it cleanly yet.

 
Bill

I'm building a framework where the user creates a configuration file that defines how the Flex application is constructed.  One part of this framework allows the user to define a data visualization along with the components used in the construction.  Now I'm adding the ability to define and add filter logic so that once the visualization is created, it can be filtered dynamically at run-time.  I currently build the visualization from the configuration file and create/register mediators for the view components when the application starts.  For the filtering, I was thinking I could encapsulate the logic and functionality in a separate mediator that would point to a view that is already being mediated.    This would allow me to have one mediator manipulate the view's regular state, events, etc and then have another mediator handle the filtering notifications being applied.  Obviously, I could use one mediator to do both tasks but this means that my existing mediators have to be made even more complex with the addition of filtering behavior methods, etc.

So, does it make any sense to try to use more than one mediator for a single view if the functions being handled by each mediator on that view are clearly defined? 

Thanks

How do you handle the design of proxies when you have two classes that might also be combined into a single dataprovider? I've got an application that displays a calendar for pilots to use where they can enter 2 types of events:  FlightEvent and PersonalEvent.  These objects share a common set of properties based on a common interface that allows them to be both be displayed in the UI calendar.   Before the calendar displays them, they have to be placed into a single dataprovider/array.  However, I still need to be able to maintain each type of collection for adds/updates/deletes.   Which of these designs is best?

1.  Make one CombinedEventsProxy that maintains two internal arrays, one named flightEventsArray and one nameed personalEventsArray.   This proxy would also be responsible for providing the combined array as a property called combinedEventsArray which aggregates the two arrays into one.  I would also have the methods on this proxy to add/update/delete items of each time within their specific arrays and then update the CombinedEventsProxy accordingly.

2.  Make a FlightEventsProxy and a CalendarEventsProxy, each of which is responsible for their own types of events.  Then create a third CombinedEventsProxy that makes calls to FlightEventsProxy/CalendarEventsProxy in order to build the aggregated list of events that it will provide.  This approach seems a little better, but I'm not sure how to handle all the inter-proxy communication because I think I would need to have the CalendarEventsProxy call FlightEventsProxy/CalendarEventsProxy to initially build the combined list, but I would also need the FlightEventsProxy/CalendarEventsProxy to call the CombinedEventsProxy back to let it know that its contents need to be updated.  This coupling seems a little strong to me.

Any suggestions on how to handle this so I can get a combined view of all the events and still issues commands to CRUD each individual type of event?

Thanks