The best part about new projects is getting to try out all the latest software and ideas on a clean slate. You’ve spent months finishing up that last project, reading blogs and forums, keeping up to date and brainstorming what you want to incorporate into the next new project you start.
Same goes for us at 9mmedia. As our latest project was brought to the table, we immediately tossed out new ideas about what would make this one faster to load, better designed, more compatible with all systems. But a big chunk of our concern was put toward how to make it easier to develop and collaborate, so we looked into frameworks and ultimately decided on PureMVC. Compared to Cairngorm, ServerBox, and a few others, we felt it best fit our needs. Plus it was ranked most approachable, flexible and scalable by developers at the Silicon Valley Flex Users Group (SilvaFUG), held at Adobe's offices in San Francisco recently.
I went into PureMVC expecting the standard model, view, and controller classes, but instead found myself face to face with proxies, mediators, commands, and façades. Just a swap in terminology? Not quite. PureMVC provides the model, view, and controller just as expected but hides them behind a global façade layer with mediators and proxies to manipulate them.
The façade class allows a single point of access to data and view objects from anywhere. The façade delegates actions to the model, view, and controller classes as appropriate, enforcing the MVC design pattern. And though a bit confusing at first, it ensures the proper data and event handling so new developers who aren’t familiar with the MVC design pattern can easily get into the flow of it.
The mediators act as intermediates between the view and its data, which is held in a proxy. This helps simplify the view and leaves it to hold just the GUI, with the mediator containing any code that is needed to alter data or do any communication with the rest of the application.
The other convenient thing PureMVC offers is notifications. Similar to events but a little more globally used, notifications implement an observer pattern that allows any object to register itself to the notification. Mediators list which notifications they are interested in receiving and no matter where they are sent from, the mediator will receive them.
The biggest downfall so far is the fact that the mediators and proxies are expected to be singletons. This makes reusable components with unique datasets impossible because they would each be accessing the same proxy with the same data through the same mediator. The mediators and proxies should be dynamic so that each view can have its own instance of each, and in an upcoming post I will be sharing some ways to make these changes within the framework.
6 Comments
You can instantiate proxies and mediators dynamically, you just need to do so with unique names, so the typical static const NAME instead needs to be identified as a dynamic variable.
http://forums.puremvc.org/index.php?topic=34.0
Here is an example for mediators, but I would imagine that proxies could be handled in a similar fashion.
It will be interesting to see how you approach this problem.
>>The biggest downfall so far is the fact that the mediators and proxies are expected to be singletons.
This is not correct. Proxies and Mediators are not singletons. The only singletons in the system are Facade, Model, View and Controller.
You may have only looked at one or two demos and found that OFTEN, there is only one instance of a given Mediator or Proxy in the in the system, but this is not always the case.
For instance, to see a Mediator that is instantiated multiple times at runtime, check out the HelloFlash demo, in which you grab a colored square on the screen and drag it, causing it to emit further colored squares.
The colored square is a HelloSprite, and each one has an associated HelloSpriteMediator. When you use the scrollwheel to resize all the sprites, what is happening is that a notification is being broadcast that all instances of HelloSpriteMediator hear and in turn resize their associated HelloSprite.
Note that each HelloSpriteMediator is given a unique name.
Whether a given Mediator or Proxy is instantiated more than once depends entirely upon what it is you’re trying to do.
-=Cliff>
Cliff
You are right, the proxies and mediators dont HAVE to be single instances. However, it seems as though you were assuming most developers would use them that way. Especially with retrieving mediators by name, the static name makes them easily accessible.
The example in the HelloFlash demo is similar to how we set up our system, using the view to dynamically name the mediators. We found that there wasn’t too much documentation about a system like that so far, as most of the examples stick to the single instances with static names. Aside from one or two posts in the forum, we decided to bring the issue out a little and discuss. To showcase our way of doing it and give others some ideas on how to go about finding a solution to their own needs.
Wouldn’t it make more sense to have the mediator be responsible for dynamically naming themselves? The mediators are inherently bound to the views via there instantiation and would be intelligent enough to offer up, or act on there own, unique name.
Jackson:
It does make sense to have the mediators responsible for their own names. And this was the course we took in the instance where we needed them to be dynamically named, they grab their name from the uid of the view they are mediating.
This becomes a problem in retrieving the mediator if you do not have access to the view component, therefore do not know the name of the mediator you are trying to use.
In that case, static names are a plus. We have stated to use static names for our mediators that may be called on from more than one component and will never be instantiated more than once, such as the entire application mediator.
thanks much, bro