Building the Page with Templates
Nothing is more fundamental to a web application than how it generates the HTML that ultimately tells the browser what to display, and nothing generates more heated arguments among web application developers. A bevy of templating libraries allow empty shells of HTML to be filled with specific content, ranging from the trivial (Underscore.js’s _.template function) to the extravagant (React.js/JSX). Even the choice between generating HTML on the server or on the client is wrought with controversy: client-side rendering is sleek, but server-side rendering is enormously flexible, as it can handle an unlimited number of special cases (personalization, internationalization, errors, and security checks...) without passing on the weight of that code to the browser.
All this controversy is beyond the scope of this book. You’re here to learn CoffeeScript! So for this project, we’re going to use a templating language called Eco.[40] Eco allows you to write templates that look like HTML with CoffeeScript snippets thrown in for conditionals and loops. Eco can be rendered on the server, but we’ll stick to client-side rendering so that we don’t have to write a Node server until the next chapter. (In the real world, client-side rendering might be preferred for an application like this one so that it can run offline and then sync changes to the server later.)
Now let’s figure out what templates we need. For simplicity, we’ll have a 1:1 correspondence between templates and Backbone views, and a 1:1 correspondence between Backbone views and Backbone models. So what kinds of entities will our task manager have? I’m thinking:
- A board, with a name and a number of columns to group task cards
- A column, with a name and containing any number of task cards
- A task card, with a description and a due date
That’s all we need for our simple app. So let’s turn those descriptions into markup:
| | <input name='board-name' value='<%= @name %>'> |
| | <div class='column-container'> |
| | <% for column in @columns : %> |
| | <div class='column' data-column-id='<%= column.id %>'></div> |
| | <% end %> |
| | <button name='add-column'>Add Column</button> |
| | </div> |
| | <input name='column-name' value='<%= @name %>'> |
| | <div class='card-container'> |
| | <% for card in @cards : %> |
| | <div class='card' data-card-id='<%= card.id %>'></div> |
| | <% end %> |
| | <button name='add-card'>Add Card</button> |
| | </div> |
| | <textarea name='card-description' placeholder='Description' |
| | rows='3'><%= @description %></textarea> |
| | <label class='due-date-label'><span>Due by:</span><input type='date' |
| | name='due-date' value='<%= @dueDate %>'></label> |
We’re not asking the templating library to pull much weight in this application. All it has to do is be better than putting your templates directly in your JavaScript code as strings and loops. In addition to being more fun to write, the templating library serves an important security function by escaping all strings before they’re inserted into the DOM. The syntax <%= value %> replaces HTML characters like > and < with codes like > and < that display as those characters. In a multi-user application, this becomes extremely important. Without escaping, one user could insert a <script> tag into a card that could, when viewed by another user, send him that user’s login cookie!
Note that we’re relying on one fairly cutting-edge browser feature here: the date input type. In a production application, we’d want to use a JavaScript library to power our datepicker. But since you’re a developer, I’m going to trust that your browser is up to date (no pun intended), allowing our project to have minimal dependencies.
Now, using the power of Backbone, we’re going to bring this markup to life.