Adding more functions to Backbone Models - javascript

I am attempting to add some functions to backbone so that I can communicate with mongodb. Now I know this won't work client side; however, I do like backbone's functionality for server side model logic as well. I noticed that I would be doing a bunch of repeat work if I kept adding the same functionality for each model so decided to create a "app_model" file to extend backbone when I'm server side. I also don't want to override the standard Backbone functions because they will be useful client side.
So let's take this user class for instance:
var Backbone = require('./app_model');
var User = Backbone.Model.extend({
name : "users",
defaults: function() {
return {
username: "default",
role: 2,
created: new Date(),
updated: new Date(),
logged: new Date()
};
},
idAttribute: "username",
/**
* A predefined listing of user roles
*/
userRoles: [
"admin", //0
"author", //1
"user" //2
],
initialize: function() {
if(!!app) {
this.svrInit();
}
}
});
module.exports = User;
And I want to append functions onto backbone by using my "app_model.js" file, which looks something like this currently:
var Backbone = require('backbone'),
Deferred = require('Deferred'),
when = Deferred.when;
Backbone.Model.prototype.svrInit = function() {
//TODO: perhaps the code below should be made static some how so we don't have a bunch of instances of collection
var model = this;
if(!!app.db){
app.db.collection(this.name,function(err,collection){
model.collection = collection;
});
}
};
Backbone.Model.prototype.svrSave = function() {
var model = this.toJSON();
var dfd = new Deferred();
this.collection.insert(model, {safe:true}, function(err, result){
dfd.resolve();
});
return dfd;
};
Backbone.Model.prototype.svrFind = function(options) {
var model = this.toJSON();
var dfd = new Deferred();
this.collection.find(options, {safe:true}, function(err, result){
dfd.resolve();
});
return dfd;
};
module.exports = Backbone;
I ran my tests when I abstracted this out and it seemed to work alright. Is there a better way to do any of this? Any pit falls? I am using the global "app" variable, is that bad? If so what are some ways around it? I do find it ugly that I had to put this.svrInit() inside the init function at the model level is there anyway to automatically make that happen after creation?

So I've been thinking about this question for a couple days and I the cleanest thing I've come up with is something like this:
var MyModel = function( attributes, options ) {
Backbone.Model.apply( this, arguments );
this.specialInitializer();
};
MyModel.extend = Backbone.Model.extend;
_.extend( MyModel.prototype, Backbone.Model.prototype, {
specialInitializer: function() {
// called after the users 'initialize'
console.log("MyModel initialized.", this);
},
otherNewMethod: function() {
// this is just like any other instance method,
// just as if Backbone.Model implemented it
}
} );
So what this does is basically make an entirely new 'kind' of Backbone.Model. One which also calls specialInitializer. If you look at the backbone source just after the constructor definition for Backbone.Model you'll see this is a similar strategy.
Construct the instance.
Call an initializer the implementor is supposed to define.
Extend the prototype with functionality (in their case Backbone.Events, in ours, Backbone.Model).
Your new initializer can of course call whatever else it needs, etc.
As for your other questions about the static collection stuff and global app variable, I'm afraid I don't follow exactly what is going on there since I don't see a definition for app and don't know what you're using the collection for.
Here's a fiddle that demonstrates this with some extra logging and such.

I'm working on a fairly large code-base with 4-5 levels of inheritance in the views. This is the pattern I'm using:
var BaseView = Backbone.Model.extend({
somefunc: function() {
//contents
},
otherfunc: function(a,b,c) {
//contents
},
//...
});
var User = BaseView.extend({
// things in user view can now access somefunc and otherfunc
});
Here's a quick example in a jsfiddle (note the doSearch function being inherited)

Related

How do you prevent Knockback.js creating view models for null relations?

If my backbone models have relationships (for example, created by backbone-relational), those relationships might be nullable, leading the foreign key fields to sometimes be null.
If I have several knockback view models, and I've specified factories so that when following relations I get the view models with the desired functionality for the model, when it encounters an attribute that is null, it goes ahead and creates a view model passing null as the model, which likely breaks most of the view model's functionality.
Example:
var ChildViewModel = kb.ViewModel.extend({
constructor: function (model, options) {
// this is the problem I'm trying to avoid - creating a view model with
// no model
if (!model) {
// just report the error somehow - the jsfiddle has the
// relevant HTML element
document.getElementById("error").innerHTML = "ChildModelView initialised without a model!";
}
kb.ViewModel.prototype.constructor.apply(this, arguments);
}
});
var ParentViewModel = kb.ViewModel.extend({
constructor: function (model, options) {
// specify factories here, because this way you can easily deal with
// reverse relationships, or complicated relationship trees when you
// have a large number of different types of view model.
kb.ViewModel.prototype.constructor.call(
this,
model,
{
factories: {relation1: ChildViewModel,
relation2: ChildViewModel},
options: options
}
);
}
});
// if we assume that relation2 is a nullable relationship, backbone-relational,
// for example, would give us a model that looks like this:
var model = new Backbone.Model({
id: 1,
relation1: new Backbone.Model({id: 2}), // this works fine
relation2: null // this causes a problem
});
var view_model = new ParentViewModel(model);
And the fiddle:
https://jsfiddle.net/vbw44vac/1/
I've just discovered what I think might be a reasonable solution.
Your factories don't have to be ViewModel "classes", but can be factory functions. So:
var nullable = function (view_model_class) {
var factory = function (object, options) {
if (object === null) return object;
return new view_model_class(object, options);
};
return factory;
};
And then when you're defining your factories:
kb.ViewModel.prototype.constructor.call(
this,
model,
{
factories: {relation1: nullable(ChildViewModel),
relation2: nullable(ChildViewModel)},
options: options
}
);

Pushing to properties in Backbone [duplicate]

This question already has an answer here:
Backbone View extends is polluted
(1 answer)
Closed 8 years ago.
I spent a lot of time trying to catch a bug in my app. Eventually I set apart this piece of code which behavior seems very strange to me.
var Model = Backbone.Model.extend({
myProperty: []
});
var one = new Model();
var two = new Model();
one.myProperty.push(1);
console.log(two.myProperty); //1!!
What's the reason behind it? Why it acts so? How to avoid this type of bugs in code?
Inheritance in JavaScript is prototypical - objects can refer directly to properties higher up in the prototype chain.
In your example, one and two both share a common prototype, and do not provide their own values for myProperty so they both refer directly to Model.protoype.myProperty.
You should create new myProperty array for each model you instantiate. Model.initialize is the idiomatic place for this kind of initialisation - overriding constructor is unnecessarily complex.
var Model = Backbone.Model.extend({
initialize: function() {
this.myProperty = [];
}
});
Alternatively you could make myProperty as an attribute of the model:
var Model = Backbone.Model.extend({
defaults: function() {
return {
myProperty: []
}
}
});
It is important to note that defaults is a function - if you were to use a simple object you would encounter the same shared reference issue.
Actually its because myProperty is an array, and as you know arrays will be stored by reference. Just to test consider the following code:
var Model = Backbone.Model.extend({
myProperty: [],
messege: ''
});
var one = new Model();
var two = new Model();
one.messege = 'One!';
two.messege = 'Two!';
console.log(one.messege ); // 'One!'
console.log(two.messege ); // 'Two!'
An alternative around this could be:
var Model = Backbone.Model.extend({
constructor: function() {
this.myProperty = [];
Backbone.Model.apply(this);
}
});
var one = new Model();
one.myProperty.push(1);
var two = new Model();
console.log(two.myProperty); // []
The documentation says:
constructor / initialize new Model([attributes], [options])
When creating an instance of a model, you can pass in the initial values of the attributes, which will be set on the model. If you define an initialize function, it will be invoked when the model is created.
In rare cases, if you're looking to get fancy, you may want to override constructor, which allows you to replace the actual constructor function for your model.
So, following the documentation, you'd want to do something like this to get your case running:
var Model = Backbone.Model.extend({
initialize: function() {
this.myProperty = [];
}
});
source: http://backbonejs.org/#Model-extend

Setting Backbone attributes in a model in a nested collection

Pretty new to Backbone JS and I need to know the 'right' way of looping through and setting attributes on models in a collection that is within a model.
My models look like this:
var mediaItem = Backbone.Model.extend({
});
var mediaItems = Backbone.Collection.extend({
model: mediaItem
});
var story = Backbone.Model.extend({
initialize: function () {
this.MediaItems = new mediaItems(this.get('MediaItems'));
this.MediaItems.parent = this;
}
});
What I want to do is loop through the MediaItems in a given story and set the width and height of each. If I do it like this...
storyInstance.MediaItems.each(function (mediaItem) {
mediaItem.set('Width', 200);
mediaItem.set('Height', 100);
});
...then the MediaItem models within the storyInstance.MediaItems property are correctly updated, but the objects within storyInstance.attributes.MediaItems are not. And it's the attributes tree that appears to be used when I subsequently call toJSON() on the Story model.
I can probably amend the above to loop through attributes instead, but I get the feeling I've set up the models wrong or there's a more standard way of doing this?
Thanks.
Probably initialize something other than what you expected.
The below code
var story = Backbone.Model.extend({
initialize: function () {
this.MediaItems = new mediaItems(this.get('MediaItems'));
this.MediaItems.parent = this;
}
});
should have been
var story = Backbone.Model.extend({
initialize: function () {
this.MediaItems = this.get('MediaItems');
this.MediaItems.parent = this;
}
});
and instantiating items should be done with instantiation of story model like
var storyInstance = new story({
MediaItems: new mediaItems()
})
then
story.MediaItems.each(function (mediaItem) {
mediaItem.set('Width', 200);
mediaItem.set('Height', 100);
});
would result updating both
Edit: Did not realize this was from '13. It showed up in questions tagged backbone.js and I did not notice the date/time till now.
Try to check for the instance of Array in the initialize section.
var story = Backbone.Model.extend({
initialize: function () {
if(this.get('MediaItems') instanceof Array){
this.MediaItems = new mediaItems(this.get('MediaItems'));
}
else {
this.MediaItems = this.get('MediaItems');
}
this.MediaItems.parent = this;
}
});

Backbone render return this

I'm trying to figure out some of the 'patterns' to set up a Backbone-project. In the examples below, in the 'render'-function, the author returns an instance of 'this'.
Why is this? Is it specific for the example, or something common for Backbone? I don't see why one should return 'this' in the 'render'-function.
The examples
http://backbonefu.com/2011/08/filtering-a-collection-in-backbone-js/
Calling a jQuery plugin in a Backbone render method
This is just a common practice so you can call render() and to chain another method call.
It is a common pattern that the Views don't insert its HTML content in the page, and this job is done by the instance that instantiate the View in a first place.
Then what you have to write in the code that instantiate the View is something like this:
var myView = new MyView({ model: myModel });
myView.render();
$(myDOMElement).html( myView.el );
But if render() returns the View itself you can write the above code like this:
var myView = new MyView({ model: myModel });
$(myDOMElement).html( myView.render().el );
The meaning of returning this, is for providing chaining possibilities.
For example, lets assume:
var obj = {
prop1 : 0,
method1 : function(){
},
method2 : function(){
}
};
//Then you could do something like:
obj.method1();
obj.method2();
obj.prop1 = 1;
All actions on obj you need to do separately.
Now consider:
var obj = {
prop1 : 0,
method1 : function(){
return this;
},
method2 : function(){
return this;
}
};
//Now you could do these
obj.method1().prop1 = 1;
obj.method1().method2().method1();

Backbone.js view instance variables?

I'm learning Backbone.js and am trying to figure out whether it's possible to have instance variables in Backbone views.
My goal is to load a view's templates from an external file when a view is being instantiated. Currently I'm storing them in a global variable in the Backbone app's global namespace, but it would be cleaner to store the templates in a view's instance variables. Currently I have it set up like this:
var templates = {};
MessageView = Backbone.View.extend({
initialize: function() {
$.get('js/Test2Templates.tpl', function(doc) {
var tmpls = $(doc).filter('template');
templates['MessageView'] = [];
tmpls.each(function() {
templates.MessageView[this.id] = $.jqotec($.unescapeHTML(this.innerHTML));
});
});
},
render: function() {
var tpldata = {name: 'Ville', thing: 'Finland'};
$('#display').jqoteapp(templates.MessageView.greeting_template, tpldata);
},
events: {
"click input[type=button]": "additionalTransactions"
},
additionalTransactions: function() {
this.render();
}
});
But instead of using "templates" being defined as a global var, I'd like to create 'templates' in a view's initialize function, along these lines (but this doesn't work):
MessageView = Backbone.View.extend({
view_templates: {},
initialize: function() {
$.get('js/Test2Templates.tpl', function(doc) {
var tmpls = $(doc).filter('template');
tmpls.each(function() {
this.view_templates[this.id] = $.jqotec($.unescapeHTML(this.innerHTML));
});
});
},
render: function() {
var tpldata = {name: 'Ville', thing: 'Suomi'};
$('#display').jqoteapp(this.view_templates.greeting_template, tpldata);
},
events: {
"click input[type=button]": "additionalTransactions"
},
additionalTransactions: function() {
this.render();
}
});
This is probably (?) pretty straightforward and/or obvious, but me being somewhere on the Backbone.js learning curve, I'd much appreciate any help with this!! Thanks!
Your view_templates instance variable is fine (and a good idea as well). You just have to be sure that you're using the right this inside your $.get() callback and inside your tmpls.each() call. I think you want your initialize to look more like this:
initialize: function() {
this.view_templates = { };
var _this = this;
$.get('js/Test2Templates.tpl', function(doc) {
var tmpls = $(doc).filter('template');
tmpls.each(function() {
_this.view_templates[this.id] = $.jqotec($.unescapeHTML(this.innerHTML));
});
});
},
I'm not sure which this.id you want inside the tmpls.each() but I'm guessing that you want the DOM id attribute from the current template so I left it as this.id.
The this.view_templates assignment in your constructor (initialize) is needed because you presumably want each instance of the view to have its own copy of the array. Creating a new view instance doesn't do a deep copy of the the view so if you just have:
MessageView = Backbone.View.extend({
view_templates: {},
// ...
then all the instances will end up sharing the same view_templates object and view_templates will behave more like a class variable than an instance variable.
You can specify your instance variables in the view definition (i.e. the Backbone.View.extend() call) as a form of documentation but you will want to initialize any of them that should behave as an instance variable in your initialize method; read-only or "class variables" like events can be left as part of the view's definition.

Categories

Resources