Getting Started with Backbone.js Views – Part III : Event Handlers Basics

Backbone

Backbone.js LogoLearn how to set up event handlers in your Backbone.js view

In the previous two articles of this series: “Getting Started with Backbone.js Views” (Parts I & II), we learned how to set up a view and optimize it for better performance. The next logical step is event handlers.

While it may be possible that your view will not be interactive, it’s difficult to imagine a mature application that does not involve event handlers. Backbone’s approach to event handlers is a bit of a departure from your standard document.addEventListener and jQuery.click methods. Here, you will add an “events” property to the object that is passed into the Backbone.View.extend method. That “events” property is an object whose key-value pairs are sets strings comprised of an event/selector and event handler.

Example # 1A

In Example # 1A we have instantiated the MessageView constructor. Implementation details of our Backbone.js router are not at all the focus of this article, but I wanted to point out that when setting up event handlers in a Backbone view, it is important to pass an object to the view constructor. In that object, we have specified an “el” property, whose value is a jQuery DOM object. The reason for this is that it allows Backbone to properly attach our event handlers and then tear down the views DOM elements change.

Example # 1B

In Example # 1B we have added an “events” property to the object that is passed into the Backbone.View.extend method. This property is an object. In this example, that object has one property. The property name is a string that consists of two parts: the name of the event, followed by a CSS selector that identifies the DOM element to be targeted. In this case, the “click” event is specified, and the following CSS selector targets the element: “.messageView.mainMessage p”. Again, that is the key or property name. The value of that property is: “clickHandler“, the name of the function that will handle the event. This example is not very exciting. When the target element is clicked an alert shows the message: ‘I was clicked!’. We can do better.

Example # 1C

In Example # 1C, we inject the message: “I was clicked” into the DOM, a step up from the alert, but still not too sophisticated. We’ll clean this up in Example # 3.

Example # 2

In Example # 2, we have added two more properties to the “events” object: mouseover and mouseout event handlers. The purpose of this example is to illustrate that you can specify as many event handlers as you need in your “events” object.

Obtaining a Reference to the Target Element

Example # 3

In Example # 3, we have set up some functionality that is a bit of an improvement over the alert in Example # 1. Each time you click the message, timestamp is injected into the page.

You’ll notice that we are using a function named: “renderTimestamp”. This function is defined in the HTML file. Its implementation details are not particularly important. Suffice to say that when passed a jQuery DOM element object, it injects a time-stamped child element. The purpose of this is simply to demonstrate that we have real-time access to whichever DOM element is the target of an event.

HERE IS THE JS-FIDDLE.NET LINK FOR EXAMPLE # 3: http://examples.kevinchisholm.com/backbone/views/basics/html/part-iii.html

How to Demo:

When the page loads, you will see the default route. If you click “message/hello” or “message/goodbye”, you’ll see our custom routes in action. In either case, the message text has a click handler attached to it.

When you click the message text, you will see a time-stamp injected into the page. No matter how many times you click the message a new time-stamp will be added. When you mouse-over any time-stamp, the background color of that time-stamp will change.

Summary

In this article we learned the basics of how to set up event handlers in a Backbone.js view. We discussed how to specify the “el” property for a view, and then create an “Events” object. We also covered how to configure multiple events, as well as how to reference the target element and manipulate it.

Helpful Links for Backbone.js View Events

http://www.codebeerstartups.com/2012/12/12-listening-to-dom-events-in-backbone-js-learning-backbone-js

http://kevinhamiltonsmith.com/backbone-js-view-dom-events-complete-list/

http://lostechies.com/derickbailey/2011/11/09/backbone-js-object-literals-views-events-jquery-and-el/

Getting Started with Backbone.js Views – Part II : Optimization Basics

Backbone

Backbone.js LogoiLearn how to optimize your Backbone.js view for better performance

In the first part of this series:  Getting Started with Backbone.js Views – Part I : Introduction, we learned the basics of how to implement a view in Backbone.js. Although the process of extending the Backbone.View class was quite similar to extending the Backbone.Route constructor, our code was not efficient. There are two areas to address: 1) Multiple constructor instantiations, and 2) Separation of presentation and data.

Multiple constructor instantiations

Example # 1A

In Example # 1A, we have the “message” method that is meant to handle any request to the “#/message/:text” route. While this method works as intended, we instantiate the the “MessageView” class each and every time that route is requested. There is no reason to instantiate that class more than once, and from a performance standpoint, this code is inefficient.

Example # 1B

In Example # 1B, we’ve fixed the instantiation problem by leveraging the “initialize” method. If you remember from the article: “Getting Started with Backbone.js Routes – Part IV: Configuring an Initialization Function”, the “initialize” method only executes once. This is a perfect place to handle setup tasks for views. In Example # 1B, we instantiate the “MessageView” constructor. But, instead of assigning the newly instantiated object to a variable, we assign it to “this”, which is the instance of the “AppRouter” constructor. The reason we do this is because we will need access to that instance object from the “message” method.

Then, in the “message” method, we reference that instance object twice: when setting its “options.message” property and then when calling its “render” method. Both of those actions happen every time the “#/message/:text” route is requested.

Example # 2A

In Example # 2A, we can see the other problem with our code: we mix JavaScript in with our HTML. While this does work, but it is not the most efficient way to go, and we are mixing presentation with data. We will fix this by using Handlebars.js.

Example # 2B

In Example # 2B, we have replaced our “template” method with a call to the Handlebars.compile method. We pass it our string of HTML with one small but important change: the double-curly-braces templating syntax: {{message}}. A discussion of JavaScript templating is beyond the scope of this article, but it is important to note that by using Mustache.js (or a similar templating library), we do not need to mix-in JavaScript with the HTML string we pass to the Handlebars.compile method. The double-curly-braces templating syntax: {{message}} safely retrieves the data that we reference.

Example # 3

In Example # 3, we have the full code for our working example. Visually there is nothing going on in Example # 3 that you have not seen already in an earlier article. But if you look at the page source, you’ll see that there is a dramatic difference in how we go about instantiating the MessageView constructor, as well as how we reference the data in our view’s “template” method.

HERE IS THE JS-FIDDLE.NET LINK FOR EXAMPLE # 3: http://examples.kevinchisholm.com/backbone/views/basics/html/part-ii.html

How to Demo:

This example will not appear to work any differently from the previous article’s examples. The important thing to note is what is going on under the hood. Take a look at the JavaScript file for Example # 3, so you can see that we have put the techniques discussed into action.

http://examples.kevinchisholm.com/backbone/views/basics/js/part-ii.js

Summary

In this article we learned two important optimization techniques for Backbone.js views: instantiating the view constructor only once, and separating the presentation from logic. We discussed the router’s “initialize” method as the best place to instantiate our view constructor, as well as how to use the JavaScript “this” keyword to make that instance object available to other methods in the Router class. We also learned how to leverage Mustache.js for client-side templating.

Getting Started with Backbone.js Views – Part I : Introduction

Backbone

Backbone.js LogoLearn how to separate presentation from logic by leveraging Backbone.js views2

One of the main principles of MVC is the separation of presentation, data and logic. While it may be tempting to mix these concerns in order to “get it out the door”, maintaining and extending this kind of code can quickly become a nightmare. In this article, we will be introduced to Backbone.js views, which provide a tremendous amount of abstraction that keeps presentation separate from logic.

In the previous articles about Backbone routes, we learned about extending Backbone classes. Specifically, we discussed extending the Backbone.Route class. When it comes to leveraging Backbone views, the approach is exactly the same. The only difference is that we will extend the Backbone.View class.

Example # 1A

In Example # 1A, we create a variable named MessageView. This variable will become a constructor function that inherits from the Backbone.View class. We accomplish this by using the extend method of the Backbone.View class. In very much the same way that we extended the Backbone.Route class, we pass an object to the Backbone.View.extend method. In this example, the object that we passed in has two properties: “template” and “render”.

The Template Property

The “template” property tells the view “what” to render. That is, it provides the actual HTML that will be injected into the DOM. This property must be a function. Since it is a property of an object, that makes it a method. Even though it ultimately provides a string of HTML, it must be a function. So we have made it a function that returns a string of HTML.

The Render Method

The “render” property is a function, which makes it a method. This method is where you provide the code that injects the template property’s HTML into the DOM. Let’s break down the code in this method:

this.$el – “this” refers to the object, which is the instance of the MessageView variable (which is a class that we created, and it extends, or inherits from the Backbone.View class). The Backbone.View class provides a property named: “$el”, which is a jQuery object that represents the view’s parent element.

this.$el.html – Since “$el” is a jQuery object, we can use its “html” method to inject markup into the DOM.

this.template – Refers to the “template” property that we discussed above (and don’t forget: that “template” property is a method).

Example # 1B

In Example # 1B, we have the the full JS code that is used in the working example URL (below). We are leveraging what we learned about Backbone.js routes but creating a route, and configuring it for a “default” route, and our “message” route. So, when the user chooses a “message” route (e.g. “#/message/hello” or “#/message/goodbye”), our “MessageView” class is instantiated.

But this example falls short in one pretty big way: our “message” route takes a parameter from the user, but we are not making any use of that in in the view. Let’s fix this.

HERE IS THE JS-FIDDLE.NET LINK FOR EXAMPLE # 1:
http://examples.kevinchisholm.com/backbone/views/basics/html/part-i-ex1.html

How to Demo:

When the page loads, you will see the message: “This is the default route”. If you click either of the other two nav links, you will see the message: “Hello from the MessageView class!”. This markup is injected into the DOM by our MessageView class.

Example # 2

In Example # 2, we made two changes:

1) we use the “text” argument passed-into the “message” method that handles the “#/message:text” route. We get this information to the view in the following line:

view.options.message = text ? text : ‘No Message Provided!’;

Details: We use a ternary operator so that if there is no text parameter passed-in, we have a default message to provide to the view.

2) We inject the message into the view’s HTML in the following line:

‘The message is: ‘ + this.options.message + ‘

Details: In the HTML string that we are returning from the view’s “template” method, we reference the “message” property of the view’s “options” object.

HERE IS THE JS-FIDDLE.NET LINK FOR EXAMPLE # 2: http://examples.kevinchisholm.com/backbone/views/basics/html/part-i-ex2.html

How to Demo:

When the page loads, you will see the message: “This is the default route”. If you click either of the other two nav links, you will see the message: “The message is: hello” or “The message is: goodbye”. This is because the “message” route passes the “text” parameter to the view as the “message” property of its “options” object.

Summary

In this article, we had a brief introduction to Backbone.js views. We learned how to extend the Backbone.View class, and create the HTML that will be injected into the DOM. We also learned how to pass parameters to the view so that it can be dynamic.

Angular.js Basics: Routes Part III: Creating a Default Route (version 1.0.8)

Angular

Anuglar.js route

Learn how to create a default route in your Angular single-page app.

In Part II of this series: “Angular.js Basics: Routes Part II: Partials“, we learned how to leverage partials in order to decouple our HTML from the associated controllers. This not only proved to be fairly simple, but it also helps to keep our JavaScript code easier to manage and allows us to create HTML templates that can support a higher degree of complexity.

But in the previous example, when our page loaded, the element with the ngView directive was empty by default. So, the user was required to click a link in order for us to display any content provided by a partial.

In this article, we will learn about a new method of the $routeProvider object that allows us to tell Angular which partial to inject into the DOM when the base page loads.

Two things to note: 1) This article is specific to Angular 1.0.8.   2) The example code that follows leverages code from Part II of this series: “Angular.js Basics: Routes Part II: Partials“. For the sake of brevity, I won’t review much of what we learned in the previous article in great detail. If you are completely new to the idea of Angular Routes, I highly recommend you read Parts I and II of this series, and then return here.

You can download a working version of this code here: https://github.com/kevinchisholm/angular-1.0.8-default-route

The JavaScript file with the code samples you see below can be found in the file: www/js/myApp.js

Configuring your routes

Example # 1

In Example # 1, we re-visit the function expression: configFunction. You may recognize the two calls to $routeProvider.when(). These let angular know how we want it to handle requests to the routes “/hello” and “/goodbye”. In both cases, I’ve omitted the properties of the object that makes up the second argument to that method call, just to keep the example code to a minimum (these details were covered in Part I and Part II of this series).

The otherwise method

What follows those two calls is the .otherwise() method of the $routeProvider object. This method tells Angular what to do if the current request does not match any of the ones specified by the one or more calls we have made to the $routeProvider.when() method.

This is quite a useful feature. It allows us to continue to leverage an Angular partial that will be injected into the DOM by default. A typical scenario for this would be some kind of “home” page. Since the examples provided in this series are focused around the routes “/hello” and “/goodbye”, I decided that when neither route has been requested, I’d like to show the message “Hello!”. I’ve leveraged the same partial file: “message.html”, but the inline anonymous function that is assigned to the “controller” property sets the value of $scope.message” to “Welcome!”. The end result is that when you load the base page (i.e. part-3.html), the default message is “Welcome!”.

Example # 2

In Example # 2, we have added two hyperlinks to our navigation component: “Home” and “Bad Route”. The “Home” link simply requests an unspecified route: “#/”, which displays the default content “Welcome!”. We have specified this in the controller that is a property of the object passed to the $routeProvider.otherwise() method.

 

There is also a link named “Bad Route”, which requests the route: “/badroute”. Since we have not told Angular what to do when this route is requested, the details provided in our call to the $routeProvider.otherwise() method tells Angular to also display the default content: “Hello!”. But a subtle problem we have is the hash. In this case, the URL in the address bar will show: “#/badroute”, even though Angular does as we ask, and displays the default content. The problem here is that we are giving the user an opportunity to deep-link this URL, even though it is an un handled route. We need to fix this.

the redirect-to property

Example # 3

In Example # 3, we have added a new property to the object that is passed to the $routeProvider.otherwise() method: “redirectTo”. This tells Angular that when a route that we have not specified is requested, then in addition to using the specified partial and controller, it should re-direct the requested route to the “root” of our application. We could also specify another valid route, for example “/login”, etc. In this case, we simply want the address bar to show the root of the app. This way, when the user requests a route that is un handled, that request fails gracefully.

Example # 4

In Example # 4, we have the full code for our working example.

View and test the full working example code

HERE IS THE LINK FOR THE FULL WORKIG EXAMPLE: http://examples.kevinchisholm.com/javascript/angular/routes/part-3.html

How to Demo: In the blue box, you’ll notice two hyperlinks: “Hello” and “Goodbye”. Click either one of those links. When you click either link, you’ll notice that the appropriate HTML is injected into the DOM on the right side of the page. Note as well that in your browser’s address bar, “#hello” and “#goodbye” are appended to the URL. This is Angular’s way of providing support for deep-linking. The web page you are on never refreshes, but the hash portion of the URL changes.

Differences in the code

The main difference between this example and the same one from Part # 2 of our series is our use of a default route. When the page initially loads, the message “Welcome!” is displayed. The reason why this happens is: we have specified that message in our call to the $routeProvider.otherwise() method. Also, if you click the link: “Bad Route”, the default route is displayed as well. From Angular’s perspective, it is the exact same scenario: the user has requested a route that has not been specified, so our default route is used.

Summary

In this article, we learned how to create a default Angular.js route. While covering this topic, we focused on the the $routeProvider.otherwise method, which tells Angular how to handle a request for a route that has not been specified by a call to the $routeProvider.when() method. We also discussed the importance of the “redirectTo” property, which tells Angular to redirect to a route that has been properly configured, which makes for a better user experience.

here are some Helpful Links for the $routeProvider.otherwise method

http://docs.angularjs.org/api/ngRoute.$routeProvider

https://www.bitcast.io/b/getting-started-with-angularjs?v=angularjs-routeprovider-api

http://vxtindia.com/blog/8-tips-for-angular-js-beginners/

Angular.js Basics: Routes Part II: Partials

Angular

Angular.js LogoLearn how to use partial templates in your Angular single-page app.

In the first article of this series: “Angular.js Basics: Routes Part I,” we learned how Angular can intercept a hyperlink click, and inject HTML into the DOM. Accomplishing this is surprisingly straightforward because Angular provides a great deal of abstraction with regard to preventing a full-page refresh, DOM manipulation, and deep-linking via the hash.

In that previous post, the HTML that we injected into the DOM was a string that was assigned to the “template” property of the object passed to the $routeProvider.when() method. While this makes it easy to accomplish our task, it is not optimal because we are mixing with JavaScript. Also, a real-world scenario might require markup significantly more robust than the simple one-line string we use (i.e. <h1>{{message}}</h1>). What we need is the ability to leverage HTML that is separate from our JavaScript code, and could be hundreds, even thousands of lines of markup. Most importantly, our JS controller should have no concern for the markup we use; its only job is to be told where it is, and then inject it into the DOM.

An Angular partial is simply an HTML file. The main difference between this and a full-fledged web page is that the partial contains only the HTML we need. There is no need for a !DOCTYPE declaration, HTML, HEAD or BODY elements. The HTML in this file will be injected into the current web page, so only the markup that makes-up the actual component is needed.

Note: The example code that follows leverages code from Part I of this series: “Angular.js Basics: Routes Part I”. For the sake of brevity, I won’t review much of what we learned in the previous article in great detail. If you are completely new to the idea of Angular Routes, I highly recommend you read that article first, and then return here.

Example # 1

In Example # 1, we have the entire contents of the file message.html. This file sits in the same folder as our web page. As you can see, it contains only two lines of HTML: an H1 tag and a paragraph tag. There is also a set of double-curly-braces in the paragraph tag. As per our discussion in the last article, this is a placeholder for the “message” property of the $scope object to which this element is bound.

Example # 2

In Example # 2, we have our call to the $routeProvider.when() method. As per the previous article’s discussion, this method takes two arguments: the path that we want Angular to respond to, and an object that tells Angular how to handle this request.

The code in Example # 2 is virtually identical from that of the previous article with one exception: Instead of using a “template” property, we are now using a property named “templateUrl”. What this tells Angular is:

When the user requests “/hello”, do not actually direct the browser to that path.
Load the file “message.html” via ajax, and inject it into the DOM
In “message.html”, replace {{message}} with the value of $scope.message

While all of this occurs in virtually milliseconds, it is important to note that these steps are, in fact, executed by Angular.

Example # 3

In Example # 3, we have made the same change to the $routeProvider.when() method call for the path “/goodbye”.

Example # 4

HERE IS THE LINK FOR FULL WORKING EXAMPLE: http://examples.kevinchisholm.com/javascript/angular/routes/part-2.html

How to Demo: In the blue box, you’ll notice two hyperlinks: “Hello” and “Goodbye”. Click either one of those links. When you click either link, you’ll notice that the appropriate HTML is injected into the DOM on the right side of the page. Note as well that in your browser’s address bar, “#hello” and “#goodbye” are appended to the URL. This is Angular’s way of providing support for deep-linking. The web page you are on never refreshes, but the hash portion of the URL changes.

The main difference between this example and the same one from Part 1 of our series is our use of partials. Instead of hard-coding an HTML string in our JavaScript controller by assigning it to the ‘template” property, we specify a “templateUrl” property and assign a value that points to an HTML file containing only the markup we need.

Summary

In this article, we learned how to leverage Angular partials. Instead of hard-coding some HTML in our JavaScript file, we tell Angular where to find an HTML file that contains the markup we need. The main advantage here is the ability to decouple our JavaScript from the presentation code. And the HTML files that comprise our partials can be as large or complex as we like.

Helpful Links for Angular Partials

http://docs.angularjs.org/tutorial/step_07

http://onehungrymind.com/building-a-website-with-angularjs-routes-and-partials/

Angular.js Basics: Routes Part I

Angular

Learn how to spin-up an AJAX-driven single-page app by leveraging Angular.s Routes

Single-page applications have become a common project for many front-end web developers. The key components to any such endeavor is the ability to intercept hyperlinks, the updating of the DOM without actually refreshing the page, and support for deep-linking.

Anyone who has attempted even the most basic single-page application knows that managing this kind of interaction on the client-side can be tedious. Angular.js provides a significant level of abstraction when it comes to these kinds of tasks. In a few dozen lines of code, you can quite easily spin-up an AJAX-driven single-page app by leveraging Routes & Views.

Example # 1

In Example # 1, we have added the ng-app directive to the BODY tag. The value is “mainRouter”, which means there must be an Angular module by that name available. We will create this module shortly.

Example # 2

In Example # 2, we have two hyperlinks. Note that the values provided for each element’s HREF attribute are preceded by a hash. This allows Angular to intercept the hyperlink, process the request and prevent the page from following the URL (which would result in an error).

Example # 3

In Example # 3, we have an empty element with an ng-view directive. This is the element into which Angular will inject the HTML templates that we specify.

Example # 4

In Example # 4, we have created an Angular module. This is done by assigning a variable to the return value of a call to the angular.module() method. This method takes two arguments: the name of our module as a string (required), and an array of dependencies (optional). Although the second parameter is optional, because these dependencies are provided via an array, if you do not specify any dependencies, you must still include an empty array.

Example # 5

In Example # 5, we configure our router module by calling it the config() method. This method takes an array as an argument. The first element of the array is the $routeProvider object (which we will use shortly), and the name of a function that will execute our configuration code. It is perfectly acceptable (and quite common) to provide an inline anonymous function for the second parameter. I have specified a function expression instead, simply to keep the example code straightforward and easy to understand.

Example # 6

In Example # 6, we have a function named configFunction(). This function expression is passed to the config() method of our myRouter module. It takes the $routeProvider object as its sole argument. The real action takes place as we make a call to the $routeProvide’s when() method. This method expects two arguments: the URL to watch for, and an object. The properties of that object allow us to tell Angular a number of things about what should happen when the specified URL is requested by the user.

The specified URL is not a fully-qualified web address that starts with “http://”. Instead, we specify a path that is relative to the current page. The general approach is that this path should resemble a RESTful API address.

Examples:

  • http://www.some-domain.com/users (would return a list of users)
  • http://www.some-domain.com/users/1 (would return the user with the ID of “1”)
  • http://www.some-domain.com/users/add (would allow you to add a user)
  • http://www.some-domain.com/users/remove (would allow you to remove a user)
  • Etc…

A discussion of RESTful web services is out of the scope of this article. If you are not familiar with that topic, there are a few links at the bottom of this page that you might find helpful.

In the case of Example # 6, we have told Angular that when the user clicks a link that points to: “/hello”, two things should happen:

  1. The element with the ngView directive should have the HTML string assigned to the “template” property injected into it (i.e.<h1>{{message}}</h1>)
  2. The inline anonymous function that is assigned to the “controller” property should be executed.

A few things to note about these two actions that Angular takes:

In the HTML string that is injected into the element with the ngView directive, there is a set of double-curly-braces. This functions as a client-side template. When the specified HTML is injected into the DOM, the value of the “message” variable is inserted inside of that set of double-curly-braces. That value is provided by the function assigned to the “controller” property of this object passed to the $routeProvide’s when() method. That function takes the $scope object as an argument, and inside of the function, the string: “Hello!” is assigned to the “message” property of the $scope object.

Note: Once again, please note that this function expression could have been defined inline as an anonymous function when we made the call to myRouter.config() in Example # 5. The reason that I chose to break it out like that is because it made it easier to demonstrate the critical pieces of code, while keeping them fairly simple.

Example # 7

In Example # 7, we have added another route: “/goodbye”. So when the user requests that URL, the exact same actions taken in Example # 6 will be performed by Angular, with the only difference being the value of $scope.message: “GoodBye!”.

Example # 8

In Example # 8, we have the full code for our working example.

HERE IS THE LINK FOR OUR FULL WORKING EXAMPLE # 8: http://examples.kevinchisholm.com/javascript/angular/routes/part-1.html

How to Demo: In the blue box, you’ll notice two hyperlinks: “Hello” and “Goodbye”. Click either one of those links. When you click either link, you’ll notice that the appropriate HTML is injected into the DOM on the right side of the page. Note, as well, that in your browser’s address bar, “#hello” and “#goodbye” are appended to the URL. This is Angular’s way of providing support for deep-linking. The web page you are on never refreshes, but the hash portion of the URL changes. If you were to copy and paste http://examples.kevinchisholm.com/javascript/angular/routes/part-1.html#/hello or http://examples.kevinchisholm.com/javascript/angular/routes/part-1.html#/goodbye into another browser, your single-page app would “link” to that desired behavior. What is really happening is that Angular is intercepting any request that comes after the hash, and taking the actions that we specified in Examples # 6 and # 7. If you were to remove the hash from either URL, you would receive an error because the URL http://examples.kevinchisholm.com/javascript/angular/routes/part-1.html/goodbye is not valid.

Summary

In this article, we discussed Angular.js routes, a powerful feature that allows you to create fully-functioning single-page web apps with minimal effort. We talked about how to create an Angular module, configure that module, and call the $routeProvider.when() method in order to tell Angular how to intercept specific URL requests without refreshing the page, and inject the appropriate HTML into the DOM. We also discussed how this feature is based on RESTful URL syntax.

Helpful Links for Angular.js Routes and RESTful Web services

Angular.js Routes

http://docs.angularjs.org/api/ngRoute.$route

http://docs.angularjs.org/api/ngRoute

http://viralpatel.net/blogs/angularjs-routing-and-views-tutorial-with-example/

RESTful Web services

 

http://searchsoa.techtarget.com/definition/REST

http://www.ibm.com/developerworks/webservices/library/ws-restful/