Browsing the archives for the javascript tag.

A Template for Lunches

work safe

If you want to show anything on your page, you’re going to have to write a template. A template is the html to display on each page view. And if you use resources, they nest! Ember, by default, uses the Handlebars template engine.


It’s a Friday and I want ribs for lunch. But I don’t want to go alone. I’ll just write an intranet app that lets me invite a few coworkers to lunch. Because email is hard.

Begin at the beginning.

The default template is the application template. you can tell it’s the application because it doesn’t have a name. The application template is used to lay out the main page structure and all the site branding. all other templates are nested inside and show up where the {{outlet}} tag is used.

<script type="text/x-handlebars">  
<div class="subtext">Meet your coworkers for lunch</div>  

But, that alone isn’t very interesting, is it?

Okay, lets start off by managing some expectations. I’ll cover Controllers next week, but I’ll be mentioning them often. About 1/2 of the cool things about templates have some counterpart in the controller supporting them. That said, I’m getting hungry. Let’s gather up the team and head out for Barbecue!

I Decide who Leaves and who Dines!

I need to display a list of my coworkers so I can pick a couple of them.

<script type="text/x-handlebars" data-template-name="lunchPicker">  
<h2>Who's in?</h2>  
{{input value=lunchType placeholder="What's for Lunch"}}  
{{#each employee in employees}}  
  {{#if employee.isAvailable}}  
    <tr><td>{{input type="checkbox" checked=employee.isSelected}}</td>  
        <td>{{employee.fullName}} ({{employee.initials}})</td>  

A few things to note in the above example. I’m using an {{input}} block to make a text field that binds to the controller property lunchType. That will be used to let everyone know what kind of food we’re going to eat! Next, I’m looping over the a list of employees using an {{#each}} block. The collection comes from another controller property. Each element is then scoped as ‘employee’ inside the each block. I can conditionally skip displaying an employee if they are not available. more correctly, I can use an {{#if}} block to show only the available employees. I display a checkbox using a built in helper, {{input}}. It binds the checked state of the input control to the isSelected property of the employee. The last three are simple data bindings to text. They just forward properties from the model to html.

The Web Without Links isn’t the True Web.

Let’s tweak the employee listing. I want to make the name link to their info page. I can use the {{link-to}} block.

 <tr><td>{{input type='checkbox' checked=employee.isSelected}}</td><br/>
 <td>{{link-to 'employee' employee.employee_id}}<br/>

But we need to DO something!

Wonderful! Things are moving right along. Now, how do I submit my selections? With an action! An action is a function in the controller. I promise, we will get to that later. Just trust me when I say our bindings put all the information in the model, so we don’t need to pass anything to the function. We just need to bind the action to a button, right after the end of our {{#each}} block.

<button {{action 'pickThem'}}>Choose these Coworkers</button><br/>

We can pass parameters in to the function, but we don’t need to at this time. In addition, we don’t have to worry about controlling event propagation or target a different controller. All of these are possible, just not necessary for us.

Your Bill Comes with Mints

There are a few things we can do to help us clean up our code from here.

Helper isn’t just for Hamburgers

A helper is a function that gets called like a block. It returns text to be displayed in the Html. If you need to format dates, for example, or want to display an employee’s spark-line for their time on the tread mill in the past two weeks.


Partials are templates that can be reused. They bind to what ever model or controller is in the context, just incase your data doesn’t look like you expected because you named something slightly wrong.


A view can pick it’s own template. It has a bit more logic, but I’ wouldn’t go crazy building complex controls with them. In a couple weeks, we’ll cover Components and then we’ll go nuts.

1 Comment

A Picture is Worth 1000 Lies

work safe

Last week, I wrote about Routing in EmberJS. And I kinda lied a bit. I laid out the Pokédex route like this …

 this.route("pokedex", {path: '/pokedex/:poke_id'});<br/>

That’s probably the wrong choice, but I made it for Pedagogical reasons. I regret nothing, but we are going to play with the routes of an example application to think through some design decisions and pick up a small detail of the router I overlooked. Resources.

A Picture is worth 1000 words

I’m a Father, Husband, etc. That means we are generating Gigabytes of pictures. Some are even in focus. She’s two, and fast. So, we are going to build a photo sharing site! Let’s give it a classy name. I’m thinking Phlickr. Um, legal informs me that’s a bit too similar some other upstart.

Introducing PhotoAlbum

PhotoAlbum is the latest in picture sharing technology. Some of our neat features are:

  • Friends
  • Albums
  • Tags
  • Favorites
  • Popular Pictures
  • Searching
  • Dashboard

Laying the Groundwork

I’m going to start by giving some examples of pages and their Urls.

  • Index – ‘/’
  • Login – ‘/login’
  • Dashboard – ‘/dashboard’
  • Popular Pictures – ‘/popular’
  • My Friends – ‘/friends’
  • Search – ‘/search/’
  • Tags – ‘/tags/’
  • Tag – ‘/tag/Sunny%20Days’
  • My Page – ‘/U/Brian’
  • Viewing My Album – ‘/U/Brian/album/sketchnotes’
  • My Albums – ‘/U/Brian/albums’
  • Creating a new album – ‘/U/Brian/albums/new’
  • My Friends Albums – ‘/U/Matt/albums’
  • A Photo – ‘/U/Brian/photo/24153′
  • My Photos – ‘/U/Brian/photos’
  • Uploading a photo – ‘/U/Brian/photos/new’

Cartography in Code (Making a Map) {
 this.route('tag', {path: '/tag/:tagname'});
   this.resource('posters', {path: '/U'}, function(){
     this.resource('user', {path: '/:username'}, function(){
       this.route('album', {path: '/album/:albumname'});
       this.resource('albums', function(){
       this.route('photo', {path: '/photo/:photo_id'});
       this.resource('photos', function(){

What’s the Difference?

Routes are for individual pages. Routes cannot be nested. If we want nested pages, we use resources. And resources give us a few new defaults.


By default, the router gives us the route named ‘index’. And that in turn builds the controller, route, and loads the template named ‘index’. A resource is like a mini router in that way. If we name a resource ‘posters’, then all the child routes are prefixed with the name, including a new default ‘index’. The tetrad is listed out below. When deeply nested, only the resource and route matter for naming as opposed to the parent resources. Example, the template for the new albums is ‘albumsNew’ despite the albums resource being a child of the user resource.

  • RouteName – postersIndex
  • Controller – PostersIndexController
  • Route – PostersIndexRoute
  • template – postersIndex


The defaults are not the only things. They nest, just like applications. The posters resource looks for a template named ‘posters’ and then the child template. While I won’t dwell too much templates now, remember when the application template had an {{outlet}}? Well, the ‘posters’ template can have an {{outlet}} as well. this allow the templates to nest.

But it’s not just the templates, the controllers nest as well. So the model and properties of a parent controller can be accessed by a child. And the routes nest. Each parent finishing before the child runs.

A Time to Choose

Of course we can use routes to describe everything here. I’m fairly sure. But we will have all kinds of issues with reuse. the nesting of controllers and routes gives us a sensible place to hang some code reuse. The really interesting thing is I chose my routes and resources strictly based on what Urls made sense, what parts belong to other pieces of information. For example, there is only one dashboard, yours. The login is also independent of other data. However, each photo album belongs to a user. Matt’s album Dinners I Made is totally different from my album Dinners I Made. And while a picture has a tag, the collection of tags is only useful when it belongs to the system as a whole, allowing me to find all the pictures tagged sunrise regardless of who posted it. Once again, it all comes down to following the Urls and letting them tell you all you need to know.

No Comments

Getting from Here to There

work safe

Where do we go from here? We begin with the Url. The history of the web is based around the URL and our ability to transition from one url to another. Ember is built around the Url.

You are a Web Developer if you build apps with Urls

- Tom Dale

Every view we want to represent in our application will be represented as a different Url. When we want to show a specific piece of data, we use a different Url. Want to modify how we are showing the screen, then we add data to the Ulr. This will allow us to Deep Link and share specific views and app state with colleagues and coworkers. This is how the Web has worked since the web began. And Below, we see how the Url communicates with Ember to make choices on what to show the browser.

Ember Url Structure

Ember’s Url Structure taken from the presentation mentioned above.

The Router

The router dissects the Url and chooses which Route, Controller, Model, and Template to compose, execute, and use the results for displaying to the screen. By default, you get an ‘index’ route for free. As if I went to, that would be the default index.

Baby-steps to Customization

I can specify just a route named ‘about’ and that will show an ‘about’ template that will use the path without specifying that path.{

A Route With a Different Name, Would It Navigate as Sweet?

Lets say I have a dumb legacy Url ( I need to keep working. Because Urls are important. But I want my internal code to use clear names (about). I can specify the path used in the route mapping.{
    this.route("about", {path: '/meet-the-team' });

My Pokémans, let me show you them.

One more mapping to cover for now, before we start talking about the magic a route actually does. What if we want to show the same page, but vary the data based on part of the path? I have a super awesome collection of Pokémans, let me show you my favorite Squirtle. I keep him at I can specify part of the path to be a dynamic segment. The name of the dynamic segment will show up as a param in the Route code.{
    this.route("pokedex", {path: "/pokedex/:poke_id"});

Spent All That Time Defining

It’s neat and all that I’ve just created a route with a dynamic segment. But I need to use that to actually do work. I can create a PokedexRoute and override it’s model creation!

App.PokedexRoute = Ember.Route.extend({
    model: function(params){
        return Ember.$.getJson('api/pokemon/' + params.poke_id);

What’s a lifecycle?

There are so many hooks in the route that I can override. I can override the controller creation. I can specify a non-standard template. Oh, that might be fun! This is the BEST pokemans, so he needs a custom template.

App.PokedexRoute = Ember.Route.extend({
    renderTemplate: function(controller, model){
      if( === "Squirtiepie") {
      } else {

Odds and Ends

If your code is slow, because for example not tied to anything real and not to name names or anything you query exchange, you can create a template called ‘loading’. Or you an overload the loading behavior.

The same thing with handling errors.

Customizing the Base

You may notice that the Url ember gives you has a hash (#). You can pick the location strategy as one of the following three. If you don’t like the hash, you can use the ‘location’. If you’re running an app out of a page, you can use ‘none’. The ‘hash’ strategy is the default.

    location: 'history'

Transition Overrides

When you edit the Pokedex, you don’t want to update the data until the Pokemaster is finished with her entry and presses the submit button. But what if she clicks on a link to another page? We can intercept the transition and quit!

App.PokedexEditRoute = Ember.Route.extend({
    action: {
	    willTransition: function(transition){
			if(this.controller.get('formHasEdits') &&  confirm("Are you sure you want to throw away your changes?")){
			} else {
				return true;

We could also validate the input for correctness and prevent a transition if we found it necessary.


Let’s say you load a model and need to decide to redirect because any Pikachu needs to redirected to a list of rats. That jerk gets all the attention anyway.

App.PokedexRoute = Ember.Route.extend({
   afterModel: function(model, transition){
      if(model.get('type') ==='Pikachu'){

You Are Here

The router is all about defining the transitions between your views. In all honesty, the next time I write a desktop application, I may have to write something like this. It’s super easy to manage and override just about any transition. It’s useful, flexible, and the heart and soul of your application.


Rise of the Tetrad

work safe

Ember has about six concepts that once you understand a bit will help you unlock the documentation and figure out how to develop your site. I have written before about not needing to fully understand ember before working on a project, but once you start getting your feet under you and need to branch out. My hope is that by the time you are done reading, you will have a roadmap to the Ember Guides and the Ember APIs.

Rise of the Tetrad

Ember uses naming conventions to tie together the four moving parts of an ember application; the Route Name, the Route, the Controller, and the Template.

The Route Name

When the route is defined like I did below, it is given a name. By default, the path mapped to the route is the same as the route. For example, the route below defines a route named “level1” and maps the url “/level1” to the route of the same name.{

The Route

By default we are generating a route named App.Level1Route. If we want to change the behaviors of the route, which we will cover in more depth in a different post, we need to define our Route and provide it with some overrides. A common override is to provide some model data, like below

App.Level1Route = Ember.Route.extend({
 model: function(){
 return Ember.$.getJSON("");

The Controller

Again by default, we have a controller called App.Level1Controller created for us. But if we want to override its behavior, we just make a new one with the correct name! For example, we can add an action to save the current state back to the server.

App.Level1Controller = Ember.Controller.extend({
 actions: {
 save: function(){
 Ember.$.postJSON("", model);

The Template

We need to show screens for our level. This is done by showing a template. The default template is, of course, named ‘level1’. The template is written in handlebars.

<script type="text/x-handlebars" data-template-name="level1">
  <button {{action 'save'}}>save</button>
  <canvas name="game-level" width="500" height="400">

Numbers are tricky. You said there were six, told us about four, but it looks more like only three.

Right. The Route, Controller, and Template are all based off of the Route’s Name. So, four for the price of three. The Other Fourth is the model. I’m just going to skip it for now. The three Ember apps I have written have not yet needed the complexity of an Ember Data model.

The other pieces you will come across are the Components, the views, and Router.

The Router

The router is the part that wires all the components together. We used it to set up our route mapping.


Views let you add behavior to an html tag. You can add behaviors and event handlers to the tag.


Components are an implementation of the W3C Custom Element Spec. They are far more functional than overriding an html tag, they are custom tags backed by a template and code that allow you to build custom controls. If you need a calendar control, start here. Need a tabbed page control? Check out for some examples.

Next Steps

Now that we know our way around the major concepts of the Ember framework, we can start to understand them one at a time. Maybe next time we will start with the routes.

No Comments

The Ember Path

work safe

There was a recent blog post by Rob Conery about learning EmberJs by just flinging yourself at it. That was something that kind of resonated with me. I’ve been trying to understand EmberJS for a while, but I wasn’t getting it. I wasn’t feeling confident enough to actually start a project and get it right. You can never learn without actually doing and Rob reminded me of this.

So I tried it. I flung myself in to the void of two projects.

Define the Problems

I chose two projects.

Project one is a rewrite of a comic strip site I wrote using JavaScript and HTML in about 2002. Considering I’ve not written anything for the comic itself in almost 10 years, It’s not important, but it is a healthy amount of data to display.

Project two is much smaller and uses an ASP.NET web service to wrap the Microsoft Exchange APIs. It simply asks what is currently happening with the different conference rooms at SEP.

Layout the path

I wrote both of the sites using mostly the same path. I wrote them at about the same time, so this is only logical. I accepted as fact that I would be rewriting functionality and moving code between responsibilities as I got more familiar with Ember’s various pieces.

Wonder Twins Routes and Templates (via URLs)

With routes and templates, a large amount of the work can be done. I can lay out a number of screens and how they transition. I can specify the Urls for each page.

According to Tom and Yehuda, the Ember core team, The heart of a web application is the URL and the Router is how Ember interfaces with them.

Some Urls map to a route literally to a template. The Comic’s about page has no logic or data. It’s just text. Navigating to the /about Url displays the “about” template.{
    this.route("about", {path: "/about"});

The template uses Handlebars wrapped in a script tag. The element ID is used to map the name to the route.

<script type="text/x-handlebars" id="about">
  Some About Text

Wait, there’s data?

If we want to add a touch of data to a page, we can change the route. Let’s look at the cast page. We don’t alter how we define the route mapping.

    this.route("cast", {path: "/cast"});

Then we can override the default router by adding a touch of code. Here, we have a static data structure defining our cast members. I then override the default router for the Cast route and define a model attribute.

var cast = [ {name: "Jay Barnes",
              occupation: "Coffee Shop Manager",
              head: ""},
              ... ];
 App.CastRoute = Ember.Route.extend({
   model: function () { return cast; }

And then we can consume it in the template.

<script type="text/x-handlebars" id="cast">
    {{#each item in model}}
        <div><div class="head"><img {{bind-attr src=item.head}}></div>
             <div class="cast_name">{{}}</div>

That’s Fine for Merlin, but I Have Dynamic Data

I had this same problem with my Exchange service. I needed to hit my web service for some data.

App.IndexRoute = Ember.Route.extend({
   model: function () {
        return Ember.$.getJSON("https://myendpoint/api/rooms");

But in all honestly, that takes forEVER because exchange is SLOW. So I just define a ‘loading’ template and ember makes it all better because of it’s internal use of promises to handle the async call to my server. Ember automatically shows this while waiting for my data, then shows the page with actual data.

<script type="text/x-handlebars" id="loading">
<h2>Please wait, Exchange is <em>SLOW</em></h2>
<center><img src="/Content/spinner.gif" alt="please wait"/></center>

Let’s Be Specific

If I have a url that needs a data portion, like asking for details of a specific room, I can define that in the route map and access the parameters in my model function.{
    this.route("room", {path: "room/:room_name"});
App.RoomRoute = Ember.Router.extend({
    model : function(params){
        return Ember.$.getJSON("https://myendpoint/api/room/" + params.room_name);

Is That It?

Nope. That’s not it. Granted, I’ve gotten a bunch of functionality out of those two parts of Ember; Routes and Templates. I’m now picked up on my bootstraps and I can pick my next battles based on my needs. I’ll sum up the learning path I have left for me using these two apps, and more importantly why I need to learn these things.

  • Components – I’ve used these to reduce the duplication in my templates. They can be passed data so I use them to define how I render an Exchange meeting or for the navigation bar for my comics site.
  • Controllers – I’m currently using them to handle some button triggered actions on the Exchange site. they can also be used to compute properties based on the model values or add two way binging to things like text input fields.
  • Models – I don’t know if my current projects have a need for Ember.Data, but I’m going to use it to represent the comic site’s data using fixtures. This will, hopefully, give me the experience to start with a larger data driven application.
  • Testing – When learning a framework, NEVER worry about automated programatic testing until you have a decent understanding of how things are working. THEN add tests. THEN start considering adding new features test-first. Ember has a fairly decent testing story that I want to start exploring. The more work I do in JavaScript, the more I’m going to need to test. While not needed for sites I have here, thin wrappers around data or APIs, I will be writing some sites with far more complex logic.

There is more EmberJs to learn, but I don’t need it yet. But when I do, I’m confident the documentation will be clear. And so far, the code has bee easy to use. This is the first time I’ve enjoyed web development in several years. I think I’m ready to take back the web.