You are previewing JavaScript Web Applications.

JavaScript Web Applications

Cover of JavaScript Web Applications by Alex MacCaw Published by O'Reilly Media, Inc.
  1. JavaScript Web Applications
    1. SPECIAL OFFER: Upgrade this ebook with O’Reilly
    2. Preface
      1. Who Is This Book For?
      2. How This Book Is Organized
      3. Conventions Used in This Book
      4. Accompanying Files
      5. Code Conventions
      6. Holla
      7. Author’s Note
      8. Safari® Books Online
      9. How to Contact Us
    3. 1. MVC and Classes
      1. Early Days
      2. Adding Structure
      3. What Is MVC?
      4. Toward Modularity, Creating Classes
      5. Adding Functions to Classes
      6. Adding Methods to Our Class Library
      7. Class Inheritance Using Prototype
      8. Adding Inheritance to Our Class Library
      9. Function Invocation
      10. Controlling Scope in Our Class Library
      11. Adding Private Functions
      12. Class Libraries
    4. 2. Events and Observing
      1. Listening to Events
      2. Event Ordering
      3. Canceling Events
      4. The Event Object
      5. Event Libraries
      6. Context Change
      7. Delegating Events
      8. Custom Events
      9. Custom Events and jQuery Plug-Ins
      10. Non-DOM Events
    5. 3. Models and Data
      1. MVC and Namespacing
      2. Building an ORM
      3. Adding ID Support
      4. Addressing References
      5. Loading in Data
      6. Populating Our ORM
      7. Storing Data Locally
      8. Adding Local Storage to Our ORM
      9. Submitting New Records to the Server
    6. 4. Controllers and State
      1. Module Pattern
      2. Adding a Bit of Context
      3. State Machines
      4. Routing
    7. 5. Views and Templating
      1. Dynamically Rendering Views
      2. Templates
      3. Binding
    8. 6. Dependency Management
      1. CommonJS
      2. Module Loaders
      3. Wrapping Up Modules
      4. Module Alternatives
      5. FUBCs
    9. 7. Working with Files
      1. Browser Support
      2. Getting Information About Files
      3. File Inputs
      4. Drag and Drop
      5. Copy and Paste
      6. Reading Files
      7. Custom Browse Buttons
      8. Uploading Files
      9. jQuery Drag and Drop Uploader
    10. 8. The Real-Time Web
      1. Real Time’s History
      2. WebSockets
      3. Real-Time Architecture
      4. Perceived Speed
    11. 9. Testing and Debugging
      1. Unit Testing
      2. Drivers
      3. Headless Testing
      4. Distributed Testing
      5. Providing Support
      6. Inspectors
      7. The Console
      8. Using the Debugger
      9. Analyzing Network Requests
      10. Profile and Timing
    12. 10. Deploying
      1. Performance
      2. Caching
      3. Minification
      4. Gzip Compression
      5. Using a CDN
      6. Auditors
      7. Resources
    13. 11. The Spine Library
      1. Setup
      2. Classes
      3. Events
      4. Models
      5. Controllers
      6. Building a Contacts Manager
    14. 12. The Backbone Library
      1. Models
      2. Collections
      3. Views
      4. Controllers
      5. Syncing with the Server
      6. Building a To-Do List
    15. 13. The JavascriptMVC Library
      1. Setup
      2. Classes
      3. Model
      4. Using Client-Side Templates in the View
      5. $.Controller: The jQuery Plug-in Factory
      6. Putting It All Together: An Abstract CRUD List
    16. A. jQuery Primer
      1. DOM Traversal
      2. DOM Manipulation
      3. Events
      4. Ajax
      5. Being a Good Citizen
      6. Extensions
      7. Creating a Growl jQuery Plug-in
    17. B. CSS Extensions
      1. Variables
      2. Mixins
      3. Nested Rules
      4. Including Other Stylesheets
      5. Colors
      6. How Do I Use Less?
    18. C. CSS3 Reference
      1. Prefixes
      2. Colors
      3. Rounded Corners
      4. Drop Shadows
      5. Text Shadow
      6. Gradients
      7. Multiple Backgrounds
      8. Selectors
      9. Transitions
      10. Border Images
      11. Box Sizing
      12. Transformations
      13. Flexible Box Model
      14. Fonts
      15. Graceful Degradation
      16. Creating a Layout
    19. Index
    20. About the Author
    21. Colophon
    22. SPECIAL OFFER: Upgrade this ebook with O’Reilly
O'Reilly logo

What Is MVC?

MVC is a design pattern that breaks an application into three parts: the data (Model), the presentation layer (View), and the user interaction layer (Controller). In other words, the event flow goes like this:

  1. The user interacts with the application.

  2. The controller’s event handlers trigger.

  3. The controller requests data from the model, giving it to the view.

  4. The view presents the data to the user.

Or, to give a real example, Figure 1-1 shows how sending a new chat message would work with Holla.

Holla

Figure 1-1. Sending a new chat message from Holla

  1. The user submits a new chat message.

  2. The controller’s event handlers trigger.

  3. The controller creates a new Chat Model record.

  4. The controller then updates the view.

  5. The user sees his new chat message in chat log.

The MVC architectural pattern can even be implemented without libraries or frameworks. The key is to divide up the responsibilities of the MVC components into clearly defined sections of code, keeping them decoupled. This allows for independent development, testing, and maintenance of each component.

Let’s explore the components of MVC in detail.

The Model

The model is where all the application’s data objects are stored. For example, we might have a User Model that contains a list of users, their attributes, and any logic associated specifically with that model.

A model doesn’t know anything about views or controllers. The only thing a model should contain is data and the logic associated directly with that data. Any event handling code, view templates, or logic not specific to that model should be kept well clear of it. You know an application’s MVC architecture is violated when you start seeing view code in the models. Models should be completely decoupled from the rest of your application.

When controllers fetch data from servers or create new records, they wrap them in model instances. This means that our data is object oriented, and any functions or logic defined on the model can be called directly on the data.

So, rather than this:

var user = users["foo"];
destroyUser(user);

We can do something like this:

var user = User.find("foo");
user.destroy();

The first example is not namespaced or object oriented. If we have another destroyUser() function defined in our application, the two will conflict. Global variables and functions should always be kept to an absolute minimum. In the second example, the destroy() function is namespaced behind User instances, as are all the stored records. This is ideal, since we’re keeping global variables to a minimum, exposing fewer areas to potential conflicts. The code is cleaner and can take advantage of inheritance so functions like destroy() don’t have be defined separately on every model.

Models are explored in much more depth in Chapter 3, which covers topics such as loading in data from servers and creating object-relational mappers (ORMs).

The View

The view layer is what’s presented to the user and is what she interacts with. In a JavaScript application, the view would be made up mostly of HTML, CSS, and JavaScript templates. Apart from simple conditional statements in templates, the views shouldn’t contain any logic.

In fact, like models, views should also be decoupled from the rest of the application. Views shouldn’t know anything about controllers and models—they should be independent. Mixing up views with logic is one of the surest paths to disaster.

That isn’t to say MVC doesn’t allow for presentational logic—as long as it’s not defined inside views. Presentational logic resides in what are called helpers: scripts solely for small utility functions related to the view.

The example below, which includes logic inside views, is something you shouldn’t do:

// template.html
<div>
  <script>
    function formatDate(date) {
      /* ... */
    };
  </script>
  ${ formatDate(this.date) }
</div>

In the code above, we’re inserting the formatDate() function directly into the view, which violates MVC, resulting in an unmaintainable mess of tag soup. By separating out presentational logic into helpers, as with the example below, we’re avoiding that problem and keeping our application’s structure MVC-compliant.

// helper.js
var helper = {};
helper.formatDate = function(){ /* ... */ };

// template.html
<div>
  ${ helper.formatDate(this.date) }
</div>

In addition, all presentational logic is namespaced under the helper variable, preventing conflicts and keeping the code clean and extendable.

Don’t worry too much about specifics regarding views and templates—we cover them extensively in Chapter 5. The aim of this section is to familiarize you with how views relate to the MVC architectural pattern.

The Controller

Controllers are the glue between models and views. Controllers receive events and input from views, process them (perhaps involving models), and update the views accordingly. The controller will add event listeners to views when the page loads, such as those detecting when forms are submitted or buttons are clicked. Then, when the user interacts with your application, the events trigger actions inside the controllers.

You don’t need any special libraries or frameworks to implement controllers; here’s an example using plain old jQuery:

var Controller = {};

// Use a anonymous function to enscapulate scope
(Controller.users = function($){

  var nameClick = function(){
    /* ... */
  };

  // Attach event listeners on page load
  $(function(){
    $("#view .name").click(nameClick);
  });

})(jQuery);

We’re creating a users Controller that is namespaced under the Controller variable. Then, we’re using an anonymous function to encapsulate scope, preventing variable pollution of the global scope. When the page loads, we’re adding a click event listener to a view element.

As you can see, controllers don’t require a library or framework. However, to comply with MVC’s architectural requirements, they must be separated from Models and Views. Controllers and states are covered in more detail in Chapter 4.

The best content for your career. Discover unlimited learning on demand for around $1/day.