I have two main page layouts: one is the default layout that is going to be used for most pages and the other one is a bare layout without the header/footer etc. that will be used for example for the login page. There might be more in the future.
My current router:
var AppRouter = Backbone.Router.extend({
routes: {
'login': 'login',
'main': 'main'
},
login: function(){
var mainLayoutView = new MainLayoutView({
'layout': 'bare'
});
App.Notes.mainLayoutContainer.show(mainLayoutView);
},
main: function(){
var mainLayoutView = new MainLayoutView({
'layout': 'default'
});
App.Notes.mainLayoutContainer.show(mainLayoutView);
}
});
How should approach the implementation of the MainLayoutView to be able to render the layout specified in options? Or should I actually have two separate layouts to handle the two templates? They'll obviously share a lot of functionality, though, so I'd rather have only one.
One way could look like this...
MainLayoutView = Backbone.Marionette.ItemView.extend({
initialize: function(options){
this.layout = options.layout;
},
onRender: function() {
if (this.layout == 'default') { // or "fullView"
// Render all components
} else {
...
// Perhaps there's nothing here
}
// Render the center partial view
}
});
Another way could be directly in your view template. Marionette suggests to have a templating system (Handlebars, Jade, ...).
If you don't use a templating system, first you should consider using one. Second, if you thought about always rendering all the views and simply $(element).hide() what you don't want: DON'T. The advanced users will be able to make the elements visible again and perhaps abuse of your system. Plus, this is useless processing and useless data sent through the wire :-)
I think I've found the best way to handle this. I've decided to set the template dynamically in "initialize":
var MainLayoutView = Backbone.Marionette.LayoutView.extend({
initialize: function(options){
if(options.layout==='bare'){
this.template = '#bare-layout';
}
else{
this.template = '#default-layout';
}
}
});
This way I can use as many templates for a layout as I want to. Although I'm starting to think that ideally I should be using separate instances of LayoutView for that.
Related
I would like to know if it possible to extend in some way the mechanism Marionette Layouts are based on creating a sort of stack like navigation.
Marionette behaviour.
Before a region show()'s a view it calls close() on the currently displayed view. close() acts as the view's destructor, unbinding all events, rendering it useless and allowing the garbage collector to dispose of it.
My scenario.
Suppose I have a sort of navigation mechanism where a Layout acts as controller and first displays an ItemView called A, then a click somewhere allows to switch to ItemView B. At this point, an action on B (like for example a tap on a back button) allows to return to A without recreating it.
How is it possible to achieve the previous scenario without creating again A and maintaning its state?
For iOS people, I would like to mimic a sort of UINavigationController.
Any advice?
EDIT
My goal is to restore a prev cached view with its state without creating it again.
My scenario is the following. I have a layout with two regions: A e B.
I do a click somehere within A and A and B are closed to show C and D. Now a back click would restore A and B with their states. Events, models, etc...but since views are closed events are removed.
Use a backbone router to listen to URL change events. Setup routes for each of your views and then have the router call the layout to change the view it's displaying in response to each route. The user could click back or forward any number of times and the app responds accordingly and displays the correct view. Your router might look like:
var Router = Backbone.router.extend({
routes: {
'my/route/itemViewA': 'showItemViewA',
'my/route/itemViewB': 'showItemViewB'
},
showItemViewA: function () {
layout.showItemView('a');
},
showItemViewB: function () {
layout.showItemView('b');
}
});
Your layout might look something like this:
var Layout = Backbone.Marionette.Layout.extend({
regions: {
someRegion: 'my-region-jquery-selector'
},
initialize: function () {
this.createViews();
},
createViews: function () {
this.views = {
a: new Backbone.Marionette.ItemView,
b: new Backbone.Marionette.ItemView
};
},
showItemView: function (view) {
this.someRegion.show(this.views[view]);
// You might want to do some other stuff here
// such as call delegateEvents to keep listening
// to models or collections etc. The current view
// will be closed but it won't be garbage collected
// as it's attached to this layout.
}
});
The method of communication between the router and the layout doesn't have to be a direct call. You could trigger further application-wide events or do anything else you can think of. The router above is very basic but gets the job done. You could create a more intelligent router to use a single route with parameters to determine dynamically which itemView to show.
Every time the user does something that requires changing views, you can update the browser's history by using router.navigate('my/route/itemViewB', {trigger: true});. Also, if you set up your app to only render on history change events then you don't need to set up two mechanisms for rending each view.
I use this pattern in my own apps and it works very well.
#Simon's answer is headed in the correct direction. However, the only way to stop Marionette from closing views is to modify a bit of it's Region code.
var NoCloseRegion = Marionette.Region.extend({
open: function(view) {
// Preserve the currentView's events/elements
if (this.currentView) { this.currentView.$el.detach(); }
// Append the new view's el
this.$el.append(view.el);
}
});
The, when be sure to specify our new Region class when creating the Layout view
var Layout = Backbone.Marionette.Layout.extend({
regions: {
someRegion: {
selector: 'my-region-jquery-selector',
regionType: NoCloseRegion
},
},
initialize: function () {
this.createViews();
},
createViews: function () {
this.views = {
a: new Backbone.Marionette.ItemView,
b: new Backbone.Marionette.ItemView
};
},
showItemView: function (name) {
// Don't `show`, because that'll call `close` on the view
var view = this.views[name];
this.someRegion.open(view)
this.someRegion.attachView(view)
}
});
Now, instead of calling show which closes the old view, renders the new, and attaches it to the region (and triggers a few events), we can detach the old view, attach the new, and open it.
I know the MVC concept in ExtJs just very briefly. Could you please help me to fill up the knowledge gaps please? I only know how to create a single view this way...
Ext.define('My.controller.Contacts', {
extend: 'Ext.app.Controller',
stores: ['Contacts'],
views: ['ContactsGrid'],
refs: [{ref: 'grid', selector: '', xtype: 'contacts-grid', autoCreate: true}],
getGrid: function() {
var g = this.getGrid();
return g;
}
});
this.getGrid() seems to give you the same grid view. But what if:
I want to create multiple instances of grid views dynamically, how? and where do I store them by convention?
For each view I have created, I want to give it a config object, like how I do Ext.create(somecontrol, config); but this case in MVC they are in refs? Where do I insert this config object for every view instance I create?
I have a store Contacts, what is the relationship between all these views and the store? One each, or all sharing one store?
Thank you very much.
For all of these the answer is going to be "it depends",
I would create dynamic views in the view definition if it's something that you read at startup, otherwise if you are clicking on a button and adding a view element, you could have everything in the controller, or you could have the controller call a method on the view that actually creates the view. I'd probably go with the latter but it depends on how you want to encapsulate your view logic.
As far as 'storing' these views is concerned, the convention is to give your views an unique id so you can reference it later, similar to DOM lookups. But you can also store references to a component in a variable obviously. It really depends on what you are doing. If a controller is constructing a bunch of dynamic elements, it might make sense to just hold on to references to those elements in the controller.
Views are typically defined in their own files under the MVC approach, essentially this is an Ext.define block with a configuration in it. There are a few sample MVC applications on the Sencha site, I recommend looking them over.
This really depends on what your doing. If you have multiple Contacts views, it might make sense to have a single store be referenced by multiple views, but in general Stores represent a collection of specific data. Like Books, or Contacts, or Employees. So if a view needs to show Books and Employees, it would make sense to references those stores in the view.
I think the crux of what you're asking is where do I encapsulate the logic for dynamic views. I would recommend creating reusable view components that encapsulate your display logic and have the controller create these components and give them the data to populate themselves. This gives you a nice flexible separation of concerns.
If you're just getting started with ExtJS and their implementation of MVC I highly recommend playing around with Sencha Architect. I wouldn't build a real project with it, but it's great for throwing together quick little demo apps, and it generates an MVC structure for you. Take a look at what it gives you and take a look at the demo applications on the Sencha site.
Here's some code to explain as well. The button text config is set to 'ZZZ' in my example. The component being instantiated from view 'view-XXX' (xtype) extends 'Ext.window.Window' in my example. If a component is being instantiated within a view, the Ext.create is implicit when using lazy instantiation via the xtype config. If a component is being instantiated within the controller, I use the standard notation Ext.create. If you want to give an id, use the Ext.id() to dynamically generate an id for the component. I won't repeat #James' answer for #2 and #3.
Try this:
Ext.define('App.controller.ControllerExample', {
extend : 'Ext.app.Controller',
stores: ['XXXs', 'YYYs'],
models: ['XXX', 'YYY'],
refs : [{
ref: 'viewport',
selector: 'view-viewport'
}, {
ref: 'XXX',
selector: 'view-XXX-window'
}, {
ref: 'YYY',
selector: 'view-YYY'
}],
init : function() {
this.control({
'view-XXX-window': {
minimize: function(win, obj) {
this.getXXX().hide();
},
close: function(panel, eOpt) {
this.getXXX().hide();
}
},
'view-XXX-window button[text=ZZZ]': {
click: function() {
var XXX = this.getXXX();
if (XXX === undefined) {
var viewportWidth = this.getViewport().getWidth();
var viewportHeight = this.getViewport().getHeight();
var windowWidth = viewportWidth * 0.9;
var windowHeight = viewportHeight * 0.9;
var x = (viewportWidth / 2) - (windowWidth / 2);
var y = (viewportHeight / 2) - (windowHeight / 2);
XXX = Ext.create('App.view.XXX', {
x: x,
y: y,
width: windowWidth,
height: windowHeight
});
XXX.show();
}
else {
XXX.show();
}
}
},
});
},
});
We are currently building a Marionette based application.
Basically, we have a Marionette Application that has multiple regions defined on it.
Each region will act as a container for different Modules to display their views. I want each Module to have full control of what is being displayed in it's container, but I want the Application to allocate these regions. For simplicity, let's say that each module just has a simple ItemView.
I'm considering 2 approaches to populating those regions with the module views.
The first approach says that when each module is initialized, it will create its view and it will call the application to display its view in the specified region, for example:
var app = new Marionette.Application();
app.addRegions({
regionA: "#regionA",
regionB: "#regionB"
});
app.module("moduleA", function(moduleA, app, ...){
moduleA.on("start", function(){
var viewA = new MyViewA();
app.regionA.show(viewA);
}
});
app.module("moduleB", function(moduleB, app, ...){
moduleB.on("start", function(){
var viewB = new MyViewB();
app.regionB.show(viewB);
}
});
The second approach says that each module should expose some function that returns its view. The Application will call that function when ready and it will stick the view in the designated region.
I'm not sure which approach is better and would be happy to hear opinions.
I would definitely go with the second approach, after having gone with the first approach in the past I am now hitting the limitations of this approach and moving to the second approach. I wrote a blog post about it here
It depends which approach you take, both are fine, we choose the second option because we use require.js to load our modules dynamically.
var dashboardPage = Backbone.Marionette.Layout.extend({
template: Handlebars.compile(tmpl),
regions: {
graphWidget : "#graphWidget",
datePickerWidget: "#datePickerWidget",
searchWidget : "#searchWidget"
},
widget: {
graphWidget: null,
datePickerWidget: null,
searchWidget: null,
},
initialize: function(options){
this.someId= options.someId;
//if have someId ID - fetch model;
if(this.someId){
//fetch model if campaignId not null
this.modelAjax = this.model.fetch();
}
onShow: function() {
var that = this;
if(this.modelAjax){
this.modelAjax.done(function(){
that.widget.graphWidget= new graphWidget(graphWidgetOptions);
that.listenTo(that.widget.graphWidget, 'graphWidget', that.getGraphWidgetData, that);
....
that.graphWidget.show(that.widget.graphWidget);
that.datePickerWidget.show(that.widget.datePickerWidget);
Because Backbone.js is pretty flexible, I am wondering about the best approach for certain things. Here I'm wondering if I'm supposed to build my application's views so that '.render()' and '.remove()' correctly reverse each other.
At first, the way that seems cleanest is to pass the view a ID or jQuery element to attach to. If things are done this way though, calling '.render()' will not correctly replace the view in the DOM, since the main element is never put back in the DOM:
App.ChromeView = Backbone.View.extend({
render: function() {
// Instantiate some "sub" views to handle the responsibilities of
// their respective elements.
this.sidebar = new App.SidebarView({ el: this.$(".sidebar") });
this.menu = new App.NavigationView({ el: this.$("nav") });
}
});
$(function() {
App.chrome = new App.ChromeView({ el: $("#chrome") });
});
It seems preferable to me to set it up so that .remove() and .render() are exact opposites:
App.ChromeView = Backbone.View.extend({
render: function() {
this.$el.appendTo('body');
this.sidebar = new App.SidebarView({ el: this.$(".sidebar") });
this.menu = new App.NavigationView({ el: this.$("nav") });
}
});
$(function() {
App.chrome = new App.ChromeView();
});
What does the Backbone.js community say? Should .remove() and .render() be opposite sides of the same coin?
I prefer that render does NOT attach the view's element to the dom. I think this promotes loose coupling, high cohesion, view re-use, and facilitates unit testing. I leave attaching the rendered element to a container up to either the router or a main "layout" type container view.
The nice thing about remove is that it works without the view having knowledge of the parent element, and thus is still loosely coupled and reusable. I definitely don't like to put random DOM selectors from my layout HTML (#main or whatever) into my views. Definitely bad coupling there.
I will note that in certain annoying situations, some things like the chosen jQuery plugin require some code to run AFTER the element has been attached to the DOM. For these cases I usually implement a postAttach() callback in the view and try to keep the amount of code there as small as possible.
Yes, the in-house View.remove() is very agressive.
For the propose of re-create the View again using an external el I am used to rewrite it like this:
remove: function(){
this.$el.empty();
return this;
}
But I don't think the framework should implement magic behavior to avoid this external DOM elements deletion.
This framework behavior is aggressive, ok, but it is very cheap to customize it when needed as we see above.
What about this? If we just have .initialize and .render take a parentSelector property, we can do this and end up with a usage that is:
Loosely coupled
Reversable .remove()/.render()
Single method
instantiation & rendering for the calling method
eg:
// Bootstrap file
curl(['views/app']).then(
function(App){
app = new App('body');
});
// view/app.js
define([
'text!views/app.tmpl.html'
, 'link!views/app.css'
]
, function (template) {
var App
// Set up the Application View
App = Backbone.View.extend({
// Standard Backbone Methods
initialize: function (parentSel) {
console.log('App view initialized')
if (parentSel) { this.render(parentSel) }
}
, render: function (parentSel) {
if (parentSel) { this._sel = parentSel } // change the selector if render is called with one
if (!this._sel) { return this } // exit if no selector is set
this.$el.appendTo(this._sel)
this.$el.html(
this.compiledTemplate({ 'content':'test content' })
);
return this
}
// Custom Properties
, compiledTemplate: _.template(template)
})
return App
});
// External usage
// I can call .remove and .render all day long now:
app.remove()
app.render()
app.remove()
In my simple project I have 2 views - a line item view (Brand) and App. I have attached function that allows selecting multiple items:
var BrandView = Backbone.View.extend({
...some code...
toggle_select: function() {
this.model.selected = !this.model.selected;
if(this.model.selected) $(this.el).addClass('selected');
else $(this.el).removeClass('selected');
return this;
}
});
var AppView = Backbone.View.extend({
...some code...
delete_selected: function() {
_.each(Brands.selected(), function(model){
model.delete_selected();
});
return false;
},
});
Thing is, I want to know how many items are selected. In this setup selecting is NOT affecting the model and thus not firing any events. And from MVC concept I understand that views should not be directly talking to other views. So how can AppView know that something is being selected in BrandViews?
And more specifically, I AppView to know how many items were selected, so if more than 1 is selected, I show a menu for multiple selection.
You might want to have a read of this discussion of Backbone pub/sub events:
http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/
I like to add it in as a global event mechanism:
Backbone.pubSub = _.extend({}, Backbone.Events);
Then in one view you can trigger an event:
Backbone.pubSub.trigger('my-event', payload);
And in another you can listen:
Backbone.pubSub.on('my-event', this.onMyEvent, this);
I use what Addy Osmani calls the mediator pattern http://addyosmani.com/largescalejavascript/#mediatorpattern. The whole article is well worth a read.
Basically it is an event manager that allows you to subscribe to and publish events. So your AppView would subscript to an event, i.e. 'selected'. Then the BrandView would publish the 'selected' event.
The reason I like this is it allows you to send events between views, without the views being directly bound together.
For Example
var mediator = new Mediator(); //LOOK AT THE LINK FOR IMPLEMENTATION
var BrandView = Backbone.View.extend({
toggle_select: function() {
...
mediator.publish('selected', any, data, you, want);
return this;
}
});
var AppView = Backbone.View.extend({
initialize: function() {
mediator.subscribe('selected', this.delete_selected)
},
delete_selected: function(any, data, you, want) {
... do something ...
},
});
This way your app view doesn't care if it is a BrandView or FooView that publishes the 'selected' event, only that the event occured. As a result, I find it a maintainable way to manage events between parts of you application, not just views.
If you read further about the 'Facade', you can create a nice permissions structure. This would allow you to say only an 'AppView' can subscribe to my 'selected' event. I find this helpful as it makes it very clear where the events are being used.
Ignoring the problems with this that you already mention in your post, you can bind and trigger events to/from the global Backbone.Event object, which will allow anything to talk to anything else. Definitely not the best solution, and if you have views chatting with one another then you should consider refactoring that. But there ya go! Hope this helps.
Here is my case with a similar need: Backbone listenTo seemed like a solution to redirect to login page for timed out or not authenticated requests.
I added event handler to my router and made it listen to the global event such as:
Backbone.Router.extend({
onNotAuthenticated:function(errMsg){
var redirectView = new LoginView();
redirectView.displayMessage(errMsg);
this.loadView(redirectView);
},
initialize:function(){
this.listenTo(Backbone,'auth:not-authenticated',this.onNotAuthenticated);
},
.....
});
and in my jquery ajax error handler:
$(document).ajaxError(
function(event, jqxhr, settings, thrownError){
.......
if(httpErrorHeaderValue==="some-value"){
Backbone.trigger("auth:not-authenticated",errMsg);
}
});
You can use Backbone object as the event bus.
This approach is somewhat cleaner but still relies on Global Backbone object though
var view1 = Backbone.View.extend({
_onEvent : function(){
Backbone.trigger('customEvent');
}
});
var view2 = Backbone.View.extend({
initialize : function(){
Backbone.on('customEvent', this._onCustomEvent, this);
},
_onCustomEvent : function(){
// react to document edit.
}
});
Use the same model objects. AppView could be initialized with a collection, and BrandView initialized with one model from that collection. When attributes of a branch object change, any other code that has a reference to that model can read it.
So lets so you have some brands that you fetch via a collection:
var brands = new Brands([]);
brands.fetch();
Now you make an AppView, and an array of BrandView's for each model.
var appView = new AppView({brands: brands});
var brandViews = brands.map(function(brand) {
return new BrandView({brand: brand});
});
The appView and the brandViews now both have access to the same model objects, so when you change one:
brands.get(0).selected = true;
Then it changes when accessed by the views that reference it as well.
console.log(appView.brands.get(0).selected); // true
console.log(brandViews[0].brand.selected) // true
Same as John has suggested above, the Mediator Pattern works really good in this scenario, as Addy Osmani summing this issue up again in Backbone fundamentals.
Wound up using the Backbone.Mediator plugin which is simple and great, and makes my AMD View modules working together seamlessly =)