We Keep Coding

Backbone.js views will not display on page load, but works with jQuery in console

I am trying to create a Backbone.js front end for a Rails api and I am running into a problem. I have been able to pull the data from the api and put it into a single view and a collection view. The problem is that the data is definitely there and I can run a jQuery command in the console that will append it to the page correctly however, it will not display when the page loads. It seems like maybe the javascript files are not loading in the correct order so I have tried rearranging in application.js with no luck. I have researched a lot and can't find anything that relates directly to this and I am a beginner with Backbone.js, so it's possible I may be going about this the wrong way. Any help would be appreciated. Here is my code:
singleUserModel.js
singleUser = Backbone.Model.extend({
defaults: {
name: null
}
});
userCollection.js
userCollection = Backbone.Collection.extend({
model: singleUser,
url: 'http://localhost:3000/users'
});
singleUserView.js
singleUserView = Backbone.View.extend({
tagName: 'li',
template: _.template("<%= name %>"),
render: function() {
var userTemplate = this.template( this.model.toJSON());
this.$el.html(userTemplate);
return this;
}
});
userCollectionView.js
allUsersView = Backbone.View.extend({
tagName: 'ul',
initialize: function( initialUsers ) {
this.collection = new userCollection();
this.collection.fetch({reset: true});
this.render();
this.listenTo(this.collection, 'add', this.renderUser);
this.listenTo(this.collection, 'reset', this.render)
},
render: function() {
this.collection.each(function(item) {
this.renderUser(item);
}, this);
},
renderUser: function( item ) {
var user = new singleUserView({
model: item
});
this.$el.append(user.render().el);
}
});
main.js
var userGroupView = new allUsersView();
$('#allUsers').html(userGroupView.el);
Using this command in the console will display it on the page correctly.
$('#allUsers').html(userGroupView.el);

The script probably executes sooner than #allUsers exists on page. When you run it inside console, the page is already loaded and therefore this element was rendered on the page.
You should put this function call inside DOMContentLoaded, which can be registered with jquery's constructor shorthand $(function() { /* your code here */ }). This will ensure that the DOM is rendered before you try to query for the #allUsers element. Also note, if you're loading the data asynchronously and the #allUsers exists only after the data is loaded, you should be calling the function after the content is rendered. but if that's the case, you'll have to figure it on your own.
Also, an useful tip: never rely on .js files being loaded in the correct order, or you'll have a bad time.

Deleting a view and onclick opening it again, as if it is new - SAPUI5

I have a multiple View setup, a main View and then modules who are opened on button click after certain actions.
Right now the view is reset by me whenever its opened, but what I want to accomplish is, when the view is left, that its gone from the core and its initiated again as if it is opened for the first time.
I am not certain how, and I tried multiple things, none worked as I intended (.destroy(), .removeAllContent(), ... ).
Did I miss a function or is there a way to accomplish that?
Some code:
index.js (how the View is instantiated the first time, its not called a second time)
module.exports.Partner = function(place) {
View = require('./app/js/suche.view');
Bearbeiten = require('./app/js/bearbeiten.view');
var ctrl = View.getController();
ctrl.setPlace(ctrl, place);
ctrl.setEditPlace(ctrl, place);
ctrl.setCreatePlace(ctrl, place);
sap.ui.getCore().byId('suche').placeAt(place);
sap.ui.getCore().byId('suche').byId('searchBtn').attachPress(ctrl.nummerSearch, ctrl);
};
controller (how the View and the index.js is called)
handlePartnerSuche : function(){
this.hideView(); //this is the main view
var p = require('bit-js-business-partner');
var partner_view = p.Partner('content');
p.setCallbackForSchliessen(this, this.callbackForSchliessen);
},
controller (callback function)
callbackForSchliessen: function(){
this.showView();
},
The second View (how its closed)
handleSchliessen : function () {
var p = this.getView('suche');
p.setVisible(false);
this.callbackMethodSchliessen.call(this.callbackCtrlSchliessen);
},

You mentioned you cannot use the Router mechanism due to company restrictions -- am really curious to know what these restriction are then ;-) -- and toggle the visibility properties of the respective views instead.
In that case, I would trigger the OData service in the method where you set the view's visibility to visible, and (re)bind the ODataModel to that view.
From a performance perspective, I would not advise to destroy views from the core

Combining jQuery UI and HotTowel

I'm getting back into web development a bit after having been kind of out of it for the past 10 years or so, and I'm overwhelmed by all the new technologies that I'm having to catch up with, ASP.NET, MVC, jQuery, SPA, Knockout, etc. I don't know the second thing about jQuery and my experience with ASP.NET is very limited. I have a little familiarity with ASP.NET WebForms, but MVC (and the rest) is totally new to me.
After seeing how many technologies there were, and not knowing which route to explore in my new project, I saw that Hot Towel seems to be a template that combines all the latest stuff into one nice package, so I decided to get the Hot Towel template and start an ASP.NET MVC4 SPA project with it.
Now I'm trying to integrate with our in-house UI framework (which has been developing without me over the past few years). I decided to try to update the Details page in the Hot Towel template to have some content. I added a simple <span>, and all's well and good. But if I try to add what I understand to be a jQuery-widget-based component (?), I get nothing. Even for the simplest test of adding content via jQuery, I get nothing:
<section>
<h2 class="page-title" data-bind="text: title"></h2>
<span>Test this</span>
<div id="testDiv"></div>
<script type="text/javascript">
$("#testDiv").append("Testing");
</script>
</section>
I see the span, but not the modified div. And I can't see any of this content in the source ("View source") or the IE9 console (not surprising given the nature of SPA, but what should I do about it?). And the Visual Studio Page Inspector seems to be totally useless (can't get past the splash screen).
What is the proper method of adding elements to the UI under the HotTowel/jQuery/MVC/SPA/KockoutJS/Breeze/Durandal model? All these new frameworks are driving my crazy.
Edit some more details: The jQuery stuff works fine when I move it to the main page of the SPA, but when I have it on the Details "page" it doesn't work. I suspect it has something to do with the SPA nature of this application and how the content of alternate views are delivered not as an entire page, but as updated content for the main page.
Edit after further investigation, I have discovered the existence of a view model named "detail" which is probably related to this detail view code I have posted. This is the code from the view model:
define(['services/logger'], function (logger) {
var title = 'Details';
var vm = {
activate: activate,
title: title
};
return vm;
//#region Internal Methods
function activate() {
logger.log(title + ' View Activated', null, title, true);
return true;
}
//#endregion
});

The script is probably executing but cannot find the div. To correct manipulate div put your jquery code to in a function and trigger that function using attached/compositionComplete callback for duranadal 2.0 or viewAttached callback for durandal 1.x
1.x link - https://github.com/BlueSpire/Durandal/blob/master/docs/1.2/Composition.html.md#view-attached
2.0 link - http://durandaljs.com/documentation/Hooking-Lifecycle-Callbacks/
// in your detail view model, if using durandal 1.x
define(['services/logger'], function (logger) {
var title = 'Details';
var vm = {
activate: activate,
title: title,
viewAttached : function(view){
// view is the root element of your detail view and is passed in
// by durandal
$(view).append("Testing");
}
};
return vm;
//#region Internal Methods
function activate() {
logger.log(title + ' View Activated', null, title, true);
return true;
}
//#endregion
});
// in your detail view model, if using durandal 2.0, you have two options
define(['services/logger'], function (logger) {
var title = 'Details';
var vm = {
activate: activate,
title: title,
attached : function(view, parent){
// view is the root element of your detail view
// and is passed in by durandal
$(view).append("Testing first method");
},
compositionComplete: function(view, parent){
// view is the root element of your detail view
// and is passed in by durandal
$(view).append("Testing second method");
}
};
return vm;
//#region Internal Methods
function activate() {
logger.log(title + ' View Activated', null, title, true);
return true;
}
//#endregion
});

Is this pattern correct for performing region switching with Marionette?

This question is based on my previous one Switching from a region to another in Marionette, views are not rendered correctly. It differs from it since I'm asking if the approach I'm following is correct or it exists another approach to perform the switching between regions.
I've created a layout with two different regions. On initialize the layout loads two views in two regions of my layout. Say ViewA and ViewB. Within ViewA an event is triggered. The event is consumed by the layout to switch and other two views are injected. Say ViewC and ViewD.
Is this approach correct or do I have to follow another pattern? Routing?
Here some code where comments highlight the important parts.
onConfirm : function() {
this.leftView = new ViewC();
this.rightView = new ViewD();
this.leftRegion.show(this.leftView);
this.rightRegion.show(this.rightView);
},
initialize : function() {
// listen for event triggered from ViewA
// e.g. GloabalAggregator.vent.trigger("ga:confirm");
// where "ga:confirm" is a simple string
GloabalAggregator.vent.on("ga:confirm" , this.onConfirm, this);
this.leftView = new ViewA(), // creating here a new ViewC the style is applied correctly
this.rightView = new ViewB(); // creating here a new ViewD the style is applied correctly
},
onRender : function () {
this.leftRegion.show(this.leftView);
this.rightRegion.show(this.rightView);
}

To switch between views in a Layout usually a Controller is used, have a look at this gist for an example.
Basically you will have to create a new controller
var controller = Marionette.Controller.extend({
initialize: function(options){
this.leftRegion = options.leftRegion;
this.rightRegion = options.rightRegion;
},
swap: function() {
// do the region swapping here
}
});
You could create it like this from the view:
var controller = new MyController({
leftRegion: this.leftRegion,
rightRegion: this.rightRegion
});
(where this referes to the view) and have it listen on that event with the help of listenTo.
A couple more examples from the author of Marionette you might find useful:
fiddle
wiki article

Large scale KnockoutJS application architecture

I love KnockoutJS but have been struggling to figure out the best way to build large scale Javascript applications with it.
Right now the way I'm handling the code is by building with a root view model which usually starts at the master page level and then expanding on that. I only ko.applyBindings() on the main view. Here is the example code I have:
var companyNamespace = {};
// Master page. (a.k.a _Layout.cshtml)
(function(masterModule, $, ko, window, document, undefined) {
var private = "test";
masterModule.somePublicMethod = function() {};
masterModule.viewModel = function() {
this.stuff = ko.observable();
};
}(companyNamespace.masterModule = companyNamespace.masterModule || {}, jQuery, ko, window, document));
// Index.cshtml.
(function(subModule, $, ko, window, document, undefined) {
var private = "test";
subModule.somePublicMethod = function() {};
subModule.viewModel = function() {
this.stuff = ko.observable();
};
$(document).ready(function() {
ko.applyBindings(companyNamespace.masterModule);
});
}(companyNamespace.masterModule.subModule = companyNamespace.masterModule.subModule || {}, jQuery, ko, window, document));
I'm just worried since this is a tree structure that if I needed to insert a double master page or something like that, that this would be very cumbersome to re-factor.
Thoughts?
EDIT
I'm aware that you can apply bindings to separate elements to change the scope of the bindings however what if I have nested view models?

I have a rather large knockout.js single page application. (20K+ lines of code currently) that is very easy for anyone to maintain and add additional sections to. I have hundreds of observables and the performance is still great, even on mobile devices like an old iPod touch. It is basically an application that hosts a suite of tools. Here are some insights into the application I use:
1. Only one view model. It keeps things simple IMHO.
The view model handles the basics of any single page application, such as visibility of each page (app), navigation, errors, load and toast dialogs, etc. Example Snippet of View Model: (I separate it out even further js files, but this is to give you an overview of what it looks like)
var vm = {
error:
{
handle: function (error, status)
{
//Handle error for user here
}
},
visibility:
{
set: function (page)
{
//sets visibility for given page
}
},
permissions:
{
permission1: ko.observable(false),
permission2: ko.observable(false)
//if you had page specific permissions, you may consider this global permissions and have a separate permissions section under each app
},
loadDialog:
{
message: ko.observable(''),
show: function (message)
{
//shows a loading dialog to user (set when page starts loading)
},
hide: function()
{
//hides the loading dialog from user (set when page finished loading)
}
},
app1:
{
visible: ko.observable(false),
load: function ()
{
//load html content, set visibility, app specific stuff here
}
},
app2:
{
visible: ko.observable(false),
load: function ()
{
//load html content, set visibility, app specific stuff here
}
}
}
2. All models go into a separate .js files.
I treat models as classes, so all they really do is store variables and have a few basic formatting functions (I try to keep them simple). Example Model:
//Message Class
function Message {
var self = this;
self.id = ko.observable(data.id);
self.subject = ko.observable(data.subject);
self.body = ko.observable(data.body);
self.from = ko.observable(data.from);
}
3. Keep AJAX database calls in their own js files.
Preferably separated by section or "app". For example, your folder tree may be js/database/ with app1.js and app2.js as js files containing your basic create retrieve, update, and delete functions. Example database call:
vm.getMessagesByUserId = function ()
{
$.ajax({
type: "POST",
url: vm.serviceUrl + "GetMessagesByUserId", //Just a default WCF url
data: {}, //userId is stored on server side, no need to pass in one as that could open up a security vulnerability
contentType: "application/json; charset=utf-8",
dataType: "json",
cache: false,
success: function (data, success, xhr)
{
vm.messaging.sent.messagesLoaded(true);
for (var i = 0; i < data.messages.length; i++)
{
var message = new Message({
id: data.messages[i].id,
subject: data.messages[i].subject,
from: data.messages[i].from,
body: data.messages[i].body
});
vm.messaging.sent.messages.push(message);
}
},
error: function (jqXHR)
{
vm.error.handle(jqXHR.getResponseHeader("error"), jqXHR.status);
}
});
return true;
};
4. Merge and Minify all your model, view model, and database js files into one.
I use the Visual Studio "Web Essentials" extension that allows you to create "bundled" js files. (Select js files, right click on them and go to Web Essentials --> Create Javascript Bundle File) My Bundle file is setup like so:
<?xml version="1.0" encoding="utf-8"?>
<bundle minify="true" runOnBuild="true">
<!--The order of the <file> elements determines the order of them when bundled.-->
<!-- Begin JS Bundling-->
<file>js/header.js</file>
<!-- Models -->
<!-- App1 -->
<file>js/models/app1/class1.js</file>
<file>js/models/app1/class2.js</file>
<!-- App2 -->
<file>js/models/app2/class1.js</file>
<file>js/models/app2/class2.js</file>
<!-- View Models -->
<file>js/viewModel.js</file>
<!-- Database -->
<file>js/database/app1.js</file>
<file>js/database/app2.js</file>
<!-- End JS Bundling -->
<file>js/footer.js</file>
</bundle>
The header.js and footer.js are just a wrapper for the document ready function:
header.js:
//put all views and view models in this
$(document).ready(function()
{
footer.js:
//ends the jquery on document ready function
});
5. Separate your HTML content.
Don't keep one big monstrous html file that is hard to navigate through. You can easily fall into this trap with knockout because of the binding of knockout and the statelessness of the HTTP protocol. However, I use two options for separation depending on whether i view the piece as being accessed by a lot by users or not:
Server-side includes: (just a pointer to another html file. I use this if I feel this piece of the app is used a lot by users, yet I want to keep it separate)
<!-- Begin Messaging -->
<!--#include virtual="Content/messaging.html" -->
<!-- End Messaging -->
You don't want to use server-side includes too much, otherwise the amount of HTML the user will have to load each time they visit the page will become rather large. With that said, this is by far the easiest solution to separate your html, yet keep your knockout binding in place.
Load HTML content async: (I use this if the given piece of the app is used less frequent by users)
I use the jQuery load function to accomplish this:
// #messaging is a div that wraps all the html of the messaging section of the app
$('#messaging').load('Content/messaging.html', function ()
{
ko.applyBindings(vm, $(this)[0]); //grabs any ko bindings from that html page and applies it to our current view model
});
6. Keep the visibility of your pages/apps manageable
Showing and hiding different sections of your knockout.js application can easily go crazy with tons of lines of code that is hard to manage and remember because you are having to set so many different on and off switches. First, I keep each page or app in its own "div" (and in its own html file for separation). Example HTML:
<!-- Begin App 1 -->
<div data-bind="visible: app1.visible()">
<!-- Main app functionality here (perhaps splash screen, load, or whatever -->
</div>
<div data-bind="visible: app1.section1.visible()">
<!-- A branch off of app1 -->
</div>
<div data-bind="visible: app1.section2.visible()">
<!-- Another branch off of app1 -->
</div>
<!-- End App 1 -->
<!-- Begin App 2 -->
<div data-bind="visible: app2.visible()">
<!-- Main app functionality here (perhaps splash screen, load, or whatever -->
</div>
<!-- End App 2 -->
Second, I would have a visibility function similar to this that sets the visibility for all content on your site: (it also handles my navigation as well in a sub function)
vm.visibility:
{
set: function (page)
{
vm.app1.visible(page === "app1");
vm.app1.section1.visible(page === "app1section1");
vm.app1.section2.visible(page === "app1section2");
vm.app2.visible(page === "app2");
}
};
Then just call the app or page's load function:
<button data-bind="click: app1.load">Load App 1</button>
Which would have this function in it:
vm.visibility.set("app1");
That should cover the basics of a large single page application. There are probably better solutions out there than what I presented, but this isn't a bad way of doing it. Multiple developers can easily work on different sections of the application without conflict with version control and what not.

I like to set up my view models using prototypal inheritance. Like you I have a "master" view model. That view model contains instances of other view models or observable arrays of view models from there you can use the "foreach" and "with" bindings to in your markup. Inside your "foreach" and "with" bindings you can use the $data, $parent, $parents and $root binding contexts to reference your parent view models.
Here are the relevant articles in the KO documentation.
foreach binding
with binding
binding context
If you want I can throw together a fiddle. Let me know.