// Allow the `Backbone` object to serve as a global event bus, for folks who
// want global “pubsub” in a convenient place.
_.extend(Backbone, Events);

So for smaller apps you can just call Backbone.on(‘event’) and Backbone.trigger(‘event’) without needing to pass around the ‘Vent’

I’ve been toying with the idea of extending backbone to include automated dependency injection, but could not convince myself of the advantages. Like you, I was referring to my experience in C# (WPF) as well as Actionscript (Flash).

Currently I use the approach you describe here by attaching an event bus to the application namespace. I do the same with a model that needs to be accessed from multiple areas of the app. It “feels” bad to do, but after reading your post I’m somewhat convinced to stick with it. Anything else seems to overcomplicate things as it tries to deal with hurdles that just do not exist in Javascript.

Some posts below mention that this approach could lead to a “dumping ground”. Totally true, but Javascript itself is one huge dumping ground already. It’s really up to the developers to discipline themselves.

That makes perfect sense – I realise now at the time I posted the comment I was also unaware of the third argument in .off, the context, which also answers my own question. Backbone.js has really made me learn about things like events (which you almost take for granted when doing JS development), object lifespan etc in depth – which can only be a good thing, but also kinda scary when things you thought you knew…you really don’t. But, posts like yours have really helped me along the way, so thank you :)

For handling global events with an event binder, and needing to clean up just the ones that were for the specific part of the app that I’m in, I just create my own instance of an event binder and add only the events that I need at that point in time. Then I can “unbindAll” on that event binder instance when I need to, and not worry about destroying all of the app level events.

you can see an example of this in the wiki here: https://github.com/marionettejs/backbone.marionette/wiki/When-to-use-the-EventBinder

Hope that helps. If you have any more questions about this, it would be best to ask on the google group for marionette: https://groups.google.com/forum/#!forum/backbone-marionette

I’ve been implementing your idea of an event aggregator, but also much of the advice that you give on Zombie views and proper cleanup. How do you deal with cleanup code not accidentally unbinding global event aggregator events for other views? I’ll elaborate, because I know that makes no sense on it’s own!

Say you hit a route, this route passes off to a controller method that instantiates some views, models etc – standard stuff, lastly the controller calls the app level showView method to swap in the new view, and clean up the old one. So the following happens:

- When the controller method is called View A is instantiated, View A makes some bindings to the global event aggregator.

- The last part of the controller method is calling showView, showView calls close on View B, who had some bindings to the same type of event that A is now bound to. So as part of View B’s cleanup all of it’s bindings to the global event aggregator are unbound.

- View B’s cleanup includes, for example, something like App.vent.off(“thing:clicked”, this.openMe);

- As this is a global, View A’s newly bound events are also unbound at the same time.

Should I just not be making event aggregator bindings in my ‘top-level’ view? (e.g. View A renders in sub-views, they’re okay, events unaffected, as they’re not actually instantiated until render() is called on view A as the last part of showView)

Or should I be namespacing these events or something similar?

Sorry that took so long to explain, and many thanks if you can offer any help :)

also, semantics and separation of concerns are important. i don’t want my event aggregator to be associated with or require a DOM manipulation library because event aggregation has nothing to do with DOM manipulation.

but there’s no reason you can’t use jquery for your event aggregator in your apps.

i just showed a really poor example, because … well… it’s an example :D