Seeing the Model Railroad

Okay, now that we’ve covered models exhaustively, it’s time to actually see something, to move to the View part of our Model-View-Controller-ish application.

You can play with the code here on JS Bin.

First, I need to address the issue of namespacing, which is good to take care of now before running into trouble later down the road. When I started off developing I had code that looked like:

var Railroad = Backbone.Model.extend();
var railroad = new Railroad();

Now that’s fine, but what do I call the View for the railroad? Do I call it viewRailroad, railroadView, or something else?

I discovered a way of solving this problem by using Rico Sta Cruz’s advice to put everything in an App namespace attached to the window to keep everything organized. So now, whenever I’m starting an application, I start with:

window.App = {
 Models: {},
 Views: {}
};

I would then define Models and Views like this:

App.Models.Railroad = Backbone.Model.extend();
App.Models.railroad = new App.Models.Railroad();

App.Views.Railroad = Backbone.View.extend();
App.Views.railroad = new App.Views.Railroad();

This way I can keep Models and Views better organized with visual cues, knowing that the railroad view is using the railroad model.

Since this is the first time we’re looking at Views, we’re going to keep it simple and not add too much in the way of rendering data. In fact, we’re not going to render any data from our railroad model yet – we’ll tackle that in the next post.

App.Views.Railroad = Backbone.View.extend({
 initialize: function(){
   this.render(); 
 }, 
 el:'body',
 render: function(){
   this.$el.html('Hello View!');
 }
});

App.Views.railroad = new App.Views.Railroad();

Taking a look at this View, you can see that the View is made up of three components.

initialize

This is an easy one, since we’ve seen it before as the constructor for Models. Now we have a constructor for the View. In this case, initialize is telling itself to use the render method, which I cover below.

el

el stands for the target element in the DOM for this view. In this case, to make things simple, I’m just targeting the body in the DOM. Usually, I would put a div in the HTML with the id of app, so I can isolate the View to one part of the DOM.

When you specify the el in a View, you can use $el to access a cached jQuery object of the element you used for el. This way you don’t have to use jQuery again to get to the element of el.

Speaking of jQuery, lots of folks are dumping jQuery for Vanilla JS. I see the reasons why. Unfortunately, I have to support legacy browsers (Internet Explorer 8+), so using Vanilla JS isn’t always an option.  The Backbone documentation suggests including jQuery for DOM manipulation, but just for kicks, I tried substituting $el with Vanilla JS and couldn’t get it to work. For the sake of time, I’m not going to bother during these tutorials.

(BTW, Vanilla JS is just plain JS).

render

This is the method used for actual rendering. In this case, we’re just outputting HTML to $el, the cached jQuery object of el, which happens to be the body tag.

That’s it for now. Next time, we’ll actually output data from the model railroad to the view.

 

Was Carl right?

“The Cosmos is all that is or was or ever will be.”
- Carl Sagan

Was Carl right? Many would say yes, some might say maybe.

I’d have to say no, and I’d like to explain my reasoning not from a religious perspective, but as best as I can from a programming perspective.

When I come to a computer environment to start working on a blog, or tutorial about JavaScript as I’ve been writing, or checking Facebook for no reason, I come to an environment that is built upon the work of many minds that spent time putting this environment together. Although I do not see these minds or know them, it seems to make more sense that something or somethings put this environment together.

My reasoning for expecting computers to work predictably is that they have been programmed intentionally. Perhaps they aren’t programmed perfectly or as I would have them, but yet the evidence of a predictable environment suggests that there at least is something(s) outside the environment that put this together.

Does the order of the cosmos suggest something outside the cosmos?

I think so, and yes, I “think”. I do not have the ability to prove something outside the universe because I am confined to my universe. Yet, Carl Sagan was confined to the same universe, and he said, “The cosmos is all that is or was or ever will be.” He did not say, “There’s proof that the cosmos is all…” or “Perhaps the cosmos is all..” or “I think the cosmos is all…”. No, he said bluntly, “The cosmos is all…”

How did he know that? Was he somehow able to step outside the cosmos, look around and have proof that there was nothing else, and then step back into the cosmos? No, that’s what he believed. He couldn’t possibly know, because the only way to test the theory that the cosmos is the only thing that exists would be to have god-like attributes like omnipresence. Omnipresence would give one the ability to be present everywhere or anywhere, thus giving someone the ability to go backward in time to actually observe the beginning of the universe and the beginning of life.

Predictable order of the universe

One of the reasons I think or believe in something outside the cosmos is because of the predictable order of the universe. The scientific method works because the universe is predictable because of the observable laws of nature. We call them “laws” because they happen all the time in a predictable fashion. Protons, neutrons, quarks, atoms, etc. all work in a rather predictable fashion. We live in a predictable, ordered universal environment. No god, gods, angels, demons or fairy tale creatures are necessary – that’s just how it is.

Now, the web environment is predictable too. If I create a blank file called cosmos.js and write the following:

console.log('Hello world');

I know that the console is going to log a message saying ‘Hello world’. It’s predictable and works. Yet, it’s predictable and works because it’s programmed to work.

Programming languages and abiogenesis

Now the way the laws of nature work could be compared to the operating system or hardware of a computer, whereas life itself could be compared to a programming language like JavaScript. We have code in our DNA. Regardless of theories regarding evolution or creation, we can scientifically observe that all life has code within it. Without diving too far into microbiology, I see a comparison between the minimal basics for life, or living machines on the molecular level, and the minimal basics of a programming language.

Inside the universe, you can have random atoms or molecules stick together just fine. However, to get to the minimal basics of a living machine, say even the most primitive single-celled organism, you need more than that.

Here’s a dilemma: We all have to “think” or “believe” something regarding where life came from. I’m not alone on this. You can read the entry in Wikipedia about on Abiogenesis. There’s lot of different ideas of theories from scientists who do not resort to “Well, God must have done it.” Please note the repeated use of the word “thought”, “may”. They at least are being honest when they use such terminology because they can’t be certain unless they could hop in a Delorean and go back in time 3.5 billion years to have proof.

Programming languages from goo?

I hope you read the article on Abiogenesis, because I have to ask this question:

Is it likely that random molecules in a random pool could have randomly formed the bare minimum form of life which would possess a built-in programming language, such as in the form of RNA/DNA?

In the last episode of Star Trek: The Next Generation, Captain Picard discovered he’s responsible for destroying humanity. In trying to figure out how this happens, he inadvertently causes a temporal anomaly in space. However, the anomaly is working backward in time, so the farther back in time he goes, the bigger the anomaly. Picard is stumped because he can’t figure out what’s the problem, so his friend Q takes him back to France, about several billion years ago.

Q points out that the anomaly has consumed much of the galaxy at this point in time. He also points out that life is about to form for the first time from a mixture of animo acids and proteins from this warm pool of goo. He whispers to Picard,

“Oh, look! There they go. The amino acids are moving closer and closer, and closer.”

Then he says,

“Ooh! Nothing happened. See what you’ve done?”

Now, in this science fiction show, life was supposed to “happen” from a stew of animo acids swimming together, but Captain Picard caused an anomaly that prevented it.

It’s good science fiction, but is it really reasonable to think that stews of chemicals can randomly build a single-celled organism, even a “protocell“? That cell needs to be able to live, do stuff, convert matter into energy, replicate, protect itself from the environment, etc.

Recently, Carl Sagan’s Cosmos has had a comeback with a reboot hosted by Neil deGrasse Tyson. Here’s something wise he said:

“Test ideas by experiment and observation; build on those ideas that pass the test, reject the ones that fail; follow the evidence wherever it leads and question everything.”

Everything means everything, right?

Model Railroads: Part 3

There’s a few other methods I’d like to show you that you can use with models, particularly ones that can track changes in your model’s properties. As before, I’ve got examples of these snippets that you can play with at JS Bin.

Has

if (railroad.has('conductor')) {
  console.log('Whew! This railroad has ' + railroad.get('conductor') + ' as the conductor.');
}

The had method is useful to see if a model has a property. In this case, we’re using it to check if the railroad has a conductor. Since conductor is one of the default properties for the Railroad model, it should return true.

Unset

railroad.unset('owner');
console.log('Does the railroad have a owner? ' + railroad.has('owner'));

You can use unset to remove a property from a model. In this case, owner was one of the default properties for the Railroad model, but after unsetting it, it’s removed and therefore when we use the has method later, it returns false.

Clear

railroad.clear();
  console.log('Does the railroad have a conductor? ' + railroad.has('conductor'));

Clear unsets all the properties so you’re left with an empty model with no properties.

hasChanged and previous

var railroad = new Railroad();
railroad.set('destination', 'Quarry');
console.log('Has the destination changed? ' + railroad.hasChanged('destination'));

railroad.set('destination', 'Brendam Docks');
console.log('Previous destination: ' + railroad.previous('destination'));
console.log('Has the owner changed? ' + railroad.hasChanged('owner'));

These two methods are handy with tracking changes in your model, which is one of the reasons I started using Backbone.js. The hasChanged method will let you know if a property has changed.

The previous method will give you the previous value of the property you specify. This will work even if the property was never set, or if you have unset a property.

There are other methods for models as well, but many of these deal with interacting with a server, which we’re not going to cover yet until we get through other major components of Backbone, such as Collections, Views and Routers.

Just another WordPress geek