Event Handling (The M Project 1.x) - mwaylabs/The-M-Project GitHub Wiki

Introduction

Every application developer needs to register handlers for events that can occur in a modern HTML5 JavaScript application.

Howto bind events to view elements

The event logic has been refactored completely. With the new version 0.5 of The-M-Project, the framework no longer manages event binding for the developer. It's his job to explicitly bind events to functionality for every view element. That means a little overhead in coding but it results in a lot more flexibility in the application development and boosts up the overall performance.

Howto bind non-view-relevant events

All the events, that are not bound on a view element, are defined in the application context, which means in the M.Application.design call. The design call is made in your app's main.js. Here, you have to define an events object, that serves as the container for your definition of event handlers:

M.Application.design({
 ...

  events: {
    application: {
      ...
    },
    applicationCache: {
      ...
    },
    localStorage: {
      ...
    },
    sessionStorage: {
      ...
    }  
  }
});

This can be used to bind handlers to events that are triggered by the Application Cache object, that is responsible for making the application offline-capable. You find a list of Application Cache Events below.

Application Cache Events

(see http://www.w3.org/TR/html5/offline.html#appcacheevents)

• checking: The user agent (browser) is checking for an update, or attempting to download the manifest for the first time. This is always the first event in the sequence.
• noupdate: The manifest hadn't changed.
• downloading: The user agent (browser) has found an update and is fetching it, or is downloading the resources listed by the manifest for the first time.
• progress: The user agent (browser) is downloading resources listed by the manifest.
• cached: The resources listed in the manifest have been downloaded, and the application is now cached.
• updateready: The resources listed in the manifest have been newly redownloaded, and the script can use swapCache() to switch to the new cache.
• obsolete: The manifest was found to have become a 404 or 410 page, so the application cache is being deleted.
• error:
  • The manifest was a 404 or 410 page, so the attempt to cache the application has been aborted.
  • The manifest hadn't changed, but the page referencing the manifest failed to download properly.
  • A fatal error occurred while fetching the resources listed in the manifest.
  • The manifest changed while the update was being run.

Web Storage Events

(see http://dev.w3.org/html5/webstorage/#the-storage-event)

• storage: The storage event is fired when a storage area changes, e.g. with setItem. It has the following properties:
  • key: Represents the key being changed.
  • oldValue: Represents the old value of the key being changed.
  • newValue: Represents the new value of the key being changed.
  • url: Represents the URL of the page whose key changed.
  • storageArea: Represents the Storage object that was affected.

The storage event is handled differently in every browser implementation. Our investigation of the behavioural differences is not yet finished.