I was just wondering when using triggers would you set it up in a pub sub kind of way? i.e. if i have a trigger of next how would i get some kind of workflow controller to subscribe and display the next view in a content region with the model?

how would that look in backbone with marionette.. im very new to it all

https://groups.google.com/forum/#!forum/backbone-marionette
thanks :)

Thoughts?

let’s say you have 3 separate worflows… one for adding an employee, one for adding a contractor, and one for adding a vendor. in all three of these situations you might have a cancel button on one of the views in the workflow. if you trigger “cancel” from each of these three views, all three of the workflows will receive the cancel event because you are using a global event aggregator. this will cause really big, horribly problems with your app, long term.

to fix the “cancel” event problem, you have to hack your events the way you have done, and prefix them with the view’s type name. this is very tightly coupling your events to your views. the purpose of the events is to decouple the parts of the app, not couple them more tightly with magic strings. if you change your view’s name, you have to hope you can find all of the places in your code that use this view’s name in an event, so you can change them all and keep your code up to date.
unit testing: if you are trying to test your view implementation, now you have added another requirement for your test set up: the application object must be instantiated, and must provide it’s vent for use. this is going to turn in to a nightmare when you have to set up the same global objects over and over and over in your unit tests.

you no longer have a modularized system. you are now relying on global objects, which means you have tightly coupled your code to parts of the app that they should not have to know about. this means you can’t take your app’s module and re-use it somewhere else in the same system even, without bringing along everything it’s coupled too.

you seem to be wanting to push all of the responsibility of every part of the system up to the application object. this flies in the face of every object oriented software development principle i can think of. giant “god objects” that handle everything (also known as “big ball of mud”) are one of the worst anti-patterns in software design.

and on top of all that, you’ll have to maintain your hack in your system every time a new version of Marionette is released. that will get tedious, quickly. but that’s a minor problem compared to the other issues.

I just started working with Marionette and am working specifically with the triggers pattern. I noticed, however, that you’re making the view trigger the event, instead of the App.vent object – any particular reason for that?

The reason I’m asking is that once I start using the App.vent object I don’t plan on having individual views trigger anything, in fact, I don’t even want to keep track of individual views. I ‘new’ a view directly into the region’s show method (since you so graciously clean up after me anyway within the show method):

MyApp.region.show(new MyView(…));

and would like to do this:

MyApp.vent.on(“myview:clickevent”, …);

I have already written the small BB.Marionette hack to make this work, but would like your input as to why or why not to do this.

Thanks!

I can have several parts of my app updating from one change using bindings.  For example:

http://bit.ly/KYFmW5

In the above example I have  a queryBinding where I specify the path to the bound object.  Once that object changes, I perform a transform and the change gets published to any subscribers like the queryDidChange handler in the above gist. I can have several other observers throughout my app and observers on these observers etc. and this is all synchronised beautifully without me having to write any additional code.

BTW, I use Backbone.Marionette on any legacy backbone apps and it has been a real time saver. It really does take the pain out of backbone.