I'm currently working on a large scale Backbone application (using marionetteJS) and having some architecture troubles with the best practices/patterns involved in switching views or changing the "page".
Marionette's layouts & regions provide some really great tools for doing the view switching, such as the .show()
and the .empty()
methods. In the application I am working on, I've used a layout view as the container of all other views, and this allows me to switch views in and out, essentially navigating within the app.
Thats easy. The hard part for me is understanding what the best practices are for triggering those changes.
Here are some of the solutions I've come up with:
A
page:change:x
event is fired when a user clicks a certain part of the ui (x being the view to change to). The controller that manages that view listens for that event and shows it in the apps main layout view.When a user clicks the ui to change the page, the view triggers a command, and passes in the view it would like the ui to change to, like
App.execute('page:change', view)
. The application object listens for that that trigger, and shows the view that is passed into the apps main layout view.
The problem with the first method is that the controller has to know about every page in its scope (maybe thats not a bad thing, I don't know). For example: users-list-view, users-edit-view, users-profile-view etc etc. It also makes the code somewhat harder to keep track of since there are events being triggered all over the place.
The issue with the second method is that the current view has to know about the view that the application will change too, which doesn't seem very scalable to me.
Is there any best practice for doing this kind of thing?
EDIT:
I should clarify that this is a problem associated with navigating around within an application. Not the initial load using the router.
page:change:x
orApp.execute
I am actually talking about the application level event aggregator implemented by default in marionettejs. – Tom