Chapter 12: Decisions and Setup

Before you write any application, you need to take some time to sit down, organize your thoughts, and make a few decisions — or, in this example, you need to understand the decisions I made. First and foremost, as I mentioned in the previous chapter, Marionette should be in the forefront of this application, so we need to keep the domain logic and other features simple. To this end, I chose not to have any form of persistence. Data is stored solely in memory. It will also be generated by some static JSON when the application is started up, so we at least have some data each time the browser is refreshed. This sidesteps the need to set up a back end and also allows us to skip using a solution for client-side storage.

We’ll also keep things simple by using Underscore templates and sticking the templates inside <script> tags in the HTML file. That way, we can simply provide an ID for the <script> tag holding the template we need, instead of having to worry about loading in additional files or anything else.

In addition, to help make development simpler and quicker, I’ve decided to use Twitter Bootstrap 3. This allows me to easily make the pages responsive as well, as you can see in the screenshots, which show the app at only 480 pixels wide. This may make the HTML look a bit convoluted at times, but for the most part you can ignore the HTML and just focus on the JavaScript bits.

Since Bootstrap is designed for more modern browsers (it doesn’t have support for older versions of Internet Explorer), I’ve also decided to use jQuery 2.0.3, which also eliminates support for older versions of IE. I figured that web developers tend to have more modern browsers, so leaving out these older browsers would be fine for this application.

I also decided not to use some of the libraries that I almost always use, such as RequireJS¹. Normally, I wouldn’t dream of skipping out on RequireJS — which would change the way I do numerous things, such as making some classes more decoupled, and not storing classes within a namespace since they can just be retrieved with require directly — but once again, this is about keeping things simple.

Finally, some conventions should be agreed on:

•Capitalize module names.

•Capitalize file names for files that only contain a class definition. Other file names will be all lowercase letters.

•Keep all classes related to a module namespaced on that module. If I were using RequireJS, I wouldn’t be namespacing classes.

•All modules have an index.js file that handles the core bits and external communication for the module.

Setting Up

Now that we’ve come to some decisions, let’s get started. First let’s set up some folders. Of course, we need to start with our root folder where the whole application will be held. Call this whatever you like, but it should have something to do with the application name: Quiz Engine. Inside that folder we’ll add three folders: css, js, and fonts. That will be good enough for now. It should look something like this:

[] quizengine
   [] css
   [] fonts
   [] js

Now let’s add a few subfolders into that js folder. First off, we’ll add a vendor folder. This is where we’ll put all the third-party scripts and libraries. Next we’ll add a modules folder in the js folder. This application will be divided into a few subapplications, and since Marionette uses module for creating these subapps, we’ll call this folder modules instead of subapps or something similar. Finally, we’ll throw in a helpers folder. You could also call this something like utils or extensions or whatever takes your fancy, but this is where anything that offers some type of utility functionality will go, especially if it can’t be classified as anything else we’ve come across. The overall folder structure should look like this:

[] quizengine
   [] css
   [] fonts
   [] js
      [] helpers
      [] modules
      [] vendor

Now that we’ve got all our folders set up (or if you’ve downloaded or cloned the GitHub repository), we need to make sure that the root folder is accessible to your web server. We don’t need anything special — any standard web server that can deliver files will work for this application since there is no back end. For a quick and simple server, I like to use Polpetta², which allows me to use the command line to quickly turn any folder into the root of a website accessible at http://localhost:1337. Go ahead and use whatever you’d like. If you’re downloading the code from GitHub, then this is all you need to do to get the code working.

Now, in order to start writing our own code, we’ll need to first get our dependencies. Download each of these dependencies:

•Twitter Bootstrap³:
Go to the Bootstrap site and click “Download Bootstrap” on the homepage. Unzip the file, go into the dist folder, and copy the bootstrap.min.css file (you could use the non-minified version if you prefer) in the css folder directly to our css folder and copy all the contents of the fonts folder directly to our fonts folder. It also comes with some JavaScript, but we won’t be using any of it.

•jQuery⁴:
Go to the jQuery site, click “Download jQuery”, and click “Download the compressed, production jQuery 2.0.3” under the “jQuery 2.x” section and save it into the js/vendor folder.

•Underscore⁵:
Go to the Underscore site, click “Production Version (1.5.2)”, and save the file in the same vendor folder as jQuery.

•Backbone⁶:
Go to the Backbone site, click “Production Version (1.1.0)”. Save this file in the vendor folder as well.

•Marionette⁷:
Go to the Marionette site, scroll down to the “Downloads and Documentation” → “Bundled” section and click “backbone.marionette.min.js”. Save this file in the same vendor folder as the other JavaScript files we’ve downloaded. This bundled version also includes Wreqr and Babysitter, so we don’t need to download them separately.

Now that we have all of our libraries and frameworks downloaded, we’ll need to get our HTML file set up. Create an index.html file in the root application folder and add these contents:

index.html

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width,initial-scale=1"/>
    <title>Quiz Engine: A MarionetteJS Example Application</title>
    <link rel="stylesheet" href="css/bootstrap.min.css">
    <link rel="stylesheet" href="css/styles.css">
</head>
<body>
    <div class="container">
        <header data-region="header" class="navbar navbar-inverse navbar-fixed-top">
            <div class="container">
                <div class="navbar-header">
                    <a href="#list" class="navbar-brand">Quiz Engine</a>
                </div>
            </div>
        </header>
        <section id="appBody" data-region="body" class="row"></section>
        <footer data-region="footer" class="row">
            <p class="col-xs-12 text-muted">Copyright &copy; 2013 Joe Zimmerman. This is an example application used in the book, <em>Better Backbone Applications with MarionetteJS</em>.</p>
        </footer>
    </div>

<!-- Templates -->

<!-- Dependencies -->
    <script src="js/vendor/jquery.min.js"></script>
    <script src="js/vendor/underscore.min.js"></script>
    <script src="js/vendor/backbone.min.js"></script>
    <script src="js/vendor/backbone.marionette.min.js"></script>
<!-- Our Code -->
</body>
</html>

What do we have here? Well there’s the obvious stuff, like a <doctype> element and such. We also have the <meta> elements for the character set and viewport. The viewport <meta> element is important for responsive websites, because without it many mobile browsers will initially be zoomed out. Moving past that, we come to our style sheets. We obviously needed to include the Twitter Bootstrap style sheet, but we also have another style sheet there that we’ll get to in a moment.

Once we get into the <body>, we see the structural HTML for the page with a header, footer, and body. The header and footer should remain unchanged by the application, but the [data-region="body"] <section> element is where all of our views will sit.

After that, I have a comment denoting where our templates will be. And moving past that, at the end of the <body> element is where we’ll place our myriad of scripts. I’ve already put in the dependencies, and just below those is where we’ll start sticking our scripts.

Before we get to writing our JavaScript code, though, let’s create that styles.css file and place it in the css folder:

css/styles.css

#appBody {
    margin-top: 60px;
    margin-bottom: 30px;
}

.table > thead > tr > th,
.table > tbody > tr > th,
.table > tfoot > tr > th,
.table > thead > tr > td,
.table > tbody > tr > td,
.table > tfoot > tr > td {
    vertical-align: middle;
}

.green {
    color: #090;
}

.red {
    color: #c00;
}

.navbar-brand {
    font-size: 28px;
}

Nothing special here. Just some minor styles and tweaks to Bootstrap’s styles.

Summary

Well, that’s the bulk of the high-level decisions we need to make. Most of the decisions are fairly straightforward, especially with an application of this size. Now that we have our setup done, though, I’m sure you are keen to get into writing the JavaScript, so let’s move on to the next chapter.