Switching on Signal strings
Recently I was reading some code that had been written with RobotLegs and AS3 Signals and which also used SWFAddress. There was a SwfAddress model which had a signal called 'addressSignal' and all of the other mediators also contained a reference to this signal. When the SwfAddress changed the addressSignal would dispatch from the SwfAddress model and carry with it a string which dictated the page being requested.
ex:
addressSignal.dispatch('/gallery');
All of the mediators would then run a switch on the addressSignal's payload to determine how to respond. So there were basically 4 or 5 switches being run at once every time a page changed.
Does this seem like the best way to do things or would it perhaps be better to have a unique signal for each page type? Wouldn't you still need a switch in the SwfAddress model to determine which unique signal to send..?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Shaun Smith on Apr 21, 2010 @ 10:34 PM
That approach sounds fine to me. Addresses don't change that rapidly, so it's not likely that having every mediator respond and perform a switch on each change will ever be a serious performance bottleneck. I would imagine that you could have 100s of mediators and hundreds of switch cases and it still wouldn't be noticeable.
Shifting more responsibility into the model is probably not a good idea - the class will constantly need updating.
The problem with having the mediators respond to address changes is that it only works while those mediators exist (obviously!). I.E you need view components with mediators on screen, and those mediators will probably become responsible for creating new views.
My current approach is to have special actors called Routes. All routes are informed when the address changes. Each route looks at the address and decides whether to call the "onOpen", "onChange" or "onClose" hook on itself (based on a pattern matcher). Inside these hooks the route might decide to add or remove view components, updates models, call services or broadcast events. If none of the Routes report a match a special NotFound route is called.
2 Posted by rob on Apr 26, 2010 @ 04:07 PM
We chose to do something similar where a change to 'gallery' will run the GalleryCommand which then adds the view if necessary.
edit Hey Shaun, do you have examples of your Routes? I would love to take a look at them.
Support Staff 3 Posted by Shaun Smith on Apr 28, 2010 @ 10:44 PM
Hi Rob,
I'm very unhappy with the actual implementation that I've got at the moment, but here's an example of what a concrete Route looks like:
Here I'm extending an abstract Route that has a couple of helper methods for add/removing view components. Also, the view, in this case, is cached (only created once and then re-used).
I've thrown the implementation down as a Gist, but I definitely need to clean it up at some point and release it:
http://gist.github.com/382830
4 Posted by rob on Apr 28, 2010 @ 10:51 PM
Very cool, thanks Shaun!