Till now, we have seen very basic usage of the Ember.js routes; we have been using only top-level routes such as /products and /about, but very seldom do real-world applications have such simple routes.

Real-world applications will have resources or nouns, and actions that can be executed on these nouns that are depicted by verbs.

For example, there could be a /products/2 endpoint to show the product details page for a product with ID as 2, or /products/new and /products/2/edit routes to create and edit a product, respectively.

The Ember.js framework encourages using resource for all the nouns and route for all the verbs. This means that if you are creating your application for a specific domain area, all the entities of that domain should map to a resource and all the actions on the domain entities should translate to routes. A resource then becomes a collection of routes.

You can create a new resource using this.resource in the router. It expects two arguments, the first one is the name of the resource and other is a function that defines the nested routes, if any. If you don't have any nested routes in the resource, you can omit this argument. The following code snippet shows how to create a resource with nested routes:

Router.map(function() {
  this.resource("products",function(){
    this.route("new");
  });
  this.route("about");
});

Here, we have created a resource products and a nested route, new. To be able to display these routes, we will have to create the corresponding nested templates.

One very important thing to note here is that the nesting of resources/routes also means that their templates should also be nested in a similar fashion. Let's make it more clearer by defining our products , products/new and about templates:

<br>
<br>
<div>Products Template</div>
    {{outlet}}

<br>
<br>
<div>About Template</div>
<div> This Template should contains some information about us

<br>
<h3>Create a New Product</h3>
<br>
    Product name:<br>
    {{input value=name }}
<br>
    Product Description:<br>
    {{textarea value=description }}
<br><br>
<button {{action 'create'}}>Create</button>

You can see above that we have defined two templates, one for products and the other for the new route that is nested under the products resource.

When you first look at the products template, you will notice that we have now added {{outlet}} at the end of the template. This outlet will enable nesting for this template, and all the nested routes that are present under the products resource will first render the products template present at app/templates/products.hbs, and then render the nested route's template in the outlet provided by the products template. If you remove the {{outlet}} from the products template, you will notice that the products.new template is never rendered, as it could not get the parent outlet to render the child route template.

You might also have noticed by now that we are referring to the new route that is nested inside the products resource by products.new. Ember.js follows this convention to refer to the nested routes in handlebars and other helpers, which is <<parent resource>>.<<nested route>>.

To link this nested route using the {{link-to}} handlebars helper, we would do something like the following:

{{#link-to 'products.new'}}Create a new product{{/link-to}}</div>

The following table shows the mapping of the different routes that you defined in your router to respective controller, route, and template files:

Let us see how the routes, which we have defined in our router above, map and initialize the controller, route, and template. Let us start from products.new route. Now, since the new route is defined inside the products resource, we would refer it by products.new. As we discussed earlier, route nesting also means controller and template nesting. This means that when the user visits the /products/new route, first of all, the products template is rendered from app/templates/products.hbs using the route exported from app/routes/products.js, and this route injects the controller from app/controllers/products.js to back the template.

After rendering the products template, the framework will look for the products.new template in app/template/products/new.hbs to render it in the {{outlet}} provided by the products template.

The controller exported at app/controllers/products/new.js and the route exported at app/routes/products/new.js will back the app/templates/products/new.hbs template.

The general rule of thumb is that first the parent resource is rendered, using its route and controller. Then, the nested child route is rendered in the parent template's outlet.

The nested or child route has its own controller and route, just like an independent route. The location of the nested route should be inside a folder whose name is the name of the resource it is nested in, for example, app/routes/<<resource>>/<<nested route>>.

It may seem a bit odd at first, but the trick here is to think of your application layout as nested templates rather than independent ones.

One thing that you might have noticed in the above table would be the products route, which is not mapped to any URL, and the products.index route, which we did not define anywhere. Lets revisit the products and products.index routes again here:

The products route is not mapped to any URL and is always invoked when a user visits /products or any of its child routes. It is very much like the application route present in app/routes/application.js, but only for all the routes that are nested inside the products resource.

If we want to handle errors or add in a common functionality for all the products, then its app/routes/products.js or app/controllers/products.js routes would be the right place to put in the common behavior.

For example, if we want to handle the errors that originate from the products pages in a specific way, we would put this specific behavior in the products route.

Similarly, whenever you create a nested route, you get resource.index that maps to /resource automatically. You just need to override the default implementation of ResourceIndexRoute and ResourceIndexController by defining them in your application with its custom behavior. This behavior is in line with the event bubbling topic we discussed in Action event bubbling section of Chapter 3, Rendering Using Templates.

This hierarchy of controllers and routes keeps the entities focused toward providing functionality to one section, rather than putting everything in one place and later finding it difficult to maintain that. Another view of the template hierarchy of our application is shown in the following image:

Template hierarchy of our application

Now, you should be in a better position to understand the overall routes and template nesting in Ember.js.

Till now, almost all of the examples we have seen so far have one thing in common: they all render static data that is returned from the model method of the corresponding route, something like the following:

export default Ember.Route.extend({
  model: function() {
    return ['red', 'yellow', 'blue'];
  }
});

As we saw in Chapter 2, Understanding Ember.js Object-oriented Patterns, one of the very important advantages of using Ember.js framework is that it tries to build an application that uses components that are highly decoupled, yet internally cohesive.

The templates present the data that is fetched from the models. Routes play a very important role in this process. Routes help you to decide which model to fetch and how to customize it. As shown in the preceding snippet, the model can return a static list of colors or it can also fetch a list of colors from a remote server. All of this remains transparent to the templates that focus on displaying the list of item(s) returned from the model method.

Up until now, we have seen the model method in the route returning static data to the templates. But it will seldom be the case where your models return static data, and most of the time the data is fetched from the server and displayed to the user.

For the next example, we will be using GitHub's public API (found at https://developer.github.com/v3/)to fetch the commits in the Ember.js repository.

If you open the https://api.github.com/repos/emberjs/ember.js/commits link in a browser, you will get the commit data in JSON format for the Ember.js repository on GitHub, something like the following:

[{
  "sha": "2da6e0b981ee20d2e2361102fcf7b8cb3ef812c5",
  "commit": {
    "author": {
      "name": "Stefan Penner",
      "email": "[email protected]",
      "date": "2014-12-06T17:38:03Z"
    },
    "committer": {
      "name": "Stefan Penner",
      "email": "[email protected]",
      "date": "2014-12-06T17:38:03Z"
    },
    "message": "Merge pull request #9826 from twokul/brocfile-dup-funct

Removes duplicate function",
    "tree": {
      "sha": "3eaae01753f4a2a919921232013ba32dda658bab",
      "url": "https://api.github.com/repos/emberjs/ember.js/git/trees/3eaae01753f4a2a919921232013ba32dda658bab"
    },
    "url": "https://api.github.com/repos/emberjs/ember.js/git/commits/2da6e0b981ee20d2e2361102fcf7b8cb3ef812c5",
    "comment_count": 0
  },
]

Now, let's consume this data and make it presentable for an end user.

We shall create two routes here: the commits.index route and the application index route.

As we don't have anything at present to show on the homepage of our application, we shall use the redirect method to transition from the index route to the commits.index route when anyone hits the / or the root URL. This is how the commits.index route will look:

export default  Ember.Route.extend({
  model: function() {
    varurl = 'https://api.github.com/repos/emberjs/ember.js/commits';
    return Ember.$.getJSON(url);
  }
});

The following code shows how we can redirect the index route of our application to commits.index route:

export default Ember.Route.extend({
  redirect: function(){
    this.transitionTo("commits.index");
  }
});

As you can see in the preceding code snippet, we are using the JQuery $.getJSON() method to retrieve the data from the server. Now, instead of static text, our model function retrieves the commit data from the server and returns it to the template.

Now let's look at the two templates we will have for our application. One is for the application that will contain our application name. The application template can contain things that are common for the entire application. The other commits.index template can contain the code to display the list of commits of the repository. These commits can be retrieved from the model object set in the commits.index route, as shown in the following:

<h1>Ember.js Repo</h2>
{{outlet}}

<h2>Commits</h2>
{{#each c in model}}
<div><em>Sha</em>: {{c.sha}}</div>
<div><em>Author</em>: {{c.commit.author.name}}</div>
<div><em>Message</em>: {{c.commit.message}}</div>
<hr/>
{{/each}}

As you can see in the example3/app/templates/commits/index.hbs file, to show the list of commits, we just iterate over the model object and then just output the contents of each commit to the user. If you run the preceding code, you will see the output as shown in the following screenshot:

Using asynchronous data from the model