One of the more important components of a client-side application is a notification system that informs the user when certain events occur. Alerts such as “Item saved successfully” or “There was an error retrieving the data” are common messages that you might see in an application. Informing your users about certain events are an essential component of application development but how would you go about implementing this in a Backbone.js application?
Certainly you could opt for something sophisticated by importing a library that is specifically designed to handle notifications. But if you want a quick and easy way to implement notifications, probably the easiest thing to do is to just use create a Backbone View and instantiate it in your event handlers and call backs (i.e. the functions that run when certain events occur). In what follows we’ll look at a simple implementation that is flexible enough to handle a lot of the needs that a developer might have in implementing a notification system in his or her application. It probably won’t be a silver bullet fix-all that will be sufficient for every area of every application, but I believe it is structured in such a way that things could be extended to be a decent enough solution for a number of different instances.
Read More »
When it comes to securing your REST API — authenticating and authorizing users — the situation is a bit interesting because the principle of an API being truly RESTful is that things remain stateless on the server side with each request. What that means is that the server isn’t really supposed to keep track of state in the form of sessions or anything else. To be truly RESTful all of the information that the web application needs to properly handle each request should be contained in the request itself.
If you wanted to, you could just cheat and handle everything using sessions. But according to the Internet, if you do this many kittens will die. So in the interest of at least trying to do things properly and saving the lives of millions of kittens, in the following bit we’re going to look at another one of the more common implementations for REST API authentication and authorization: Basic HTTP Authentication. We’ll be using the Slim Framework — a lightweight PHP REST API to demonstrate this, but the same principles apply if you’re using another framework or even another language.
To have user authentication within your app’s API and remain truly RESTful, it usually inevitably boils down to 2 choices: Basic HTTP Authentication and OAuth. OAuth was discussed previously in this article about using Google’s OAuth in order to access many different Google’s APIs. The developer docs at Twitter also have some good information on these two different forms of authentication.
Read More »
When programming with more advanced implementations of JavaScript, such as projects using Backbone.js, Node.js, RequireJS, or often some sort of combination of these, you will inevitably come across discussion about the concept of JavaScript modules. Modules are small pieces of decoupled code — code containing no or very few dependencies — that exist as standalone components. These modules can be used by an application to solve a particular problem. The use of modules is not a requirement to create JavaScript applications. They’re just a way of organizing code to solve common problems that arise when creating applications. In that sense, modules can be thought of as a “design pattern.” There may be cases where you want to use the module pattern in combination with other design patterns. Or, there may be where you’d want to use a different design pattern altogether. It all depends on the nature of the app you are building.
That being said, the use of modules can be a very flexible and commonly used pattern for many different types applications — from games, to web apps, to script loaders, to just about everything else. So it is definitely something worth knowing if you’re in the business of creating large-scale JavaScript applications.
So let’s take a look at a module in native JavaScript…
var moduleNamespace = (function () {
var privateVariable;
var privateMethod;
privateVariable = 0;
privateMethod = function( foo ) {
console.log( foo );
};
return {
publicVariable: "foo",
publicFunction: function( bar ) {
privateVariable++;
privateMethod(bar);
}
};
})();
In the code above we have a variable named “moduleNamespace” that is assigned to an anonymous Immediately-invoked Function Expression (IIFE) — also sometimes refereed to as a self-executing function. It’s basically a function that will automatically run in your application when it’s declared. The end result is that there’s no need to write moduleNameSpace(); elsewhere in our program.
Read More »
In the Internet of the past, web design was all about using the images to create web designs. Backgrounds, buttons, layouts and just about everything else that had to do with visualization had to be accomplished by using an image either defined inline or in CSS. When you get right down to it, it is an extremely time consuming process to have to create images for every little piece of a website. That’s why when CSS3 and font embedding came along it was the greatest thing ever! No longer do you have to crack open Photoshop every time you want to make any changes to your site, because now great visuals can be created via code and rendered in the browser.
In this post we’re going to show how these things can come together by creating a search box with the accompanying icon without using any any images at all.
View Demo Download Files
So to start we’re going to want and get our icon that we’re going to use for the search button in the search box. This will be done by using the Font Awesome collection. Font Awesome is a prominent part of the Twitter Bootstrap framework but there are many other great icon font packages all over the web. But for this example, we’ll use this. So go on over to the Font Awesome project page and download the package.
We can create a directory for our example project here and create a directory within it called “fonts” where we can place the FontAwesome webfont files. What’s great about this is that by including a few files here we now can use hundreds of different icons in a webpage simply by giving a class to an element.
Now we’re going to want to embed the font in our webpage in our CSS. Create another directory called CSS and create a style.css file within it. Add the following…
@font-face {
font-family: 'FontAwesome';
src: url('../fonts/fontawesome-webfont.eot');
src: url('../fonts/fontawesome-webfont.eot?#iefix') format('embedded-opentype'), url('../fonts/fontawesome-webfont.woff') format('woff'), url('../fonts/fontawesome-webfont.ttf') format('truetype'), url('../fonts/fontawesome-webfont.svgz#FontAwesomeRegular') format('svg'), url('../fonts/fontawesome-webfont.svg#FontAwesomeRegular') format('svg');
font-weight: normal;
font-style: normal;
}
Read More »
There are lots of great resources out on the web for Backbone.js. You can find lots of different tutorials discussing Backbone.js Models, Backbone.js Collections and Backbone.js Views. Backbone.js is a favorite of the JavaScript community for building rich and well-organized client-side applications in JavaScript.
However, eventually there comes a point where all of this neat stuff you are doing on the client-side will have to be persisted by saving your data to a server somewhere. After you do this, you’ll of course need a way to retrieve it later. Otherwise, every time a user refreshes their browser or closes their browser and comes back to your page, anything that they’d done with your app previously will be gone.
If you’re doing any sort of retrieving and/or saving models from the database, you’ll likely be using the fetch, save, destroy, and/or sync methods (or similar implementations). As the documentation on these methods indicate, these methods send asynchronous GET, POST, PUT, and DELETE requests to a URL (usually the one specified in the urlRoot property on a model or a collection). What we need to do to hook Backbone up with a server so we can consume these requests is to use an API (Application Programming Interface). This API will provide us with server-sided code that can respond to the requests coming from Backbone. Which API we use doesn’t matter. Actually I think one of the great things about client sided JavaScript applications is that you can hook up to any server/API that you want. The important thing is that we know how to set up the API properly and write code to create the URLs Backbone is sending requests to and then handle those requests on the server side.
Read More »
