I. Create a Middleman project with middleman-ember-template
$ middleman init hello --template=ember
II. Install ember.js package
$ bower install ember
I. Create a Middleman project with middleman-ember-template
$ middleman init hello --template=ember
II. Install ember.js package
$ bower install ember
Many existing JSON APIs are not consistent between types. As JSON endpoints grew organically and were built by different engineers at different times, the style in which records are represented can vary wildly.
Historically, we have asked adapter authors to rely on the fact that the type of record is
provided to all adapter hooks (either by passing a type
argument, or by passing a record
WARNING
This gist is outdated! For the most up-to-date information, please see http://emberjs.com/guides/routing/!
An Ember application starts with its main template. Put your header, footer, and any other decorative content in application.handlebars
.
<header>
This article has been given a more permanent home on my blog. Also, since it was first written, the development of the Promises/A+ specification has made the original emphasis on Promises/A seem somewhat outdated.
Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most basic definition, your code will move from continuation-passing style:
getTweetsFor("domenic", function (err, results) {
// the rest of your code goes here.
init: function() { | |
var view = this; | |
var resizeHandler = function() { | |
view.rerender(); | |
}; | |
this.set('resizeHandler', resizeHandler); | |
$(window).bind('resize', this.get('resizeHandler')); | |
}, |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> | |
<html> | |
<head> | |
<link rel="stylesheet" href="http://code.jquery.com/qunit/git/qunit.css" type="text/css" media="screen" /> | |
<!-- when.js Promises implementation --> | |
<script src="https://raw.github.com/cujojs/when/master/when.js"></script> | |
<!-- Unit testing and mocking framework --> | |
<script type="text/javascript" src="http://code.jquery.com/qunit/git/qunit.js"></script> |
Recently, we've been working on extracting Ember conventions from applications we're working on into the framework. Our goal is to make it clearer how the parts of an Ember application work together, and how to organize and bootstrap your objects.
Routing is an important part of web applications. It allows your users to share the URL they see in their browser, and have the same things appear when their friends click on the link.
The Ember.js ecosystem has several great solutions for routing. But, since it is such an important part of most web applications, we've decided to build it right into the framework.
If you have already modeled your application state using Ember.StateManager
, there are a few changes you'll need to make to enable routing. Once you've made those changes, you'll notice the browser's address bar spring to life as you start using your app—just by moving between states, Ember.js will update the URL automatically.
The rules for how Ember.js evaluates Handlebars templates have recently changed, and you may need to update your application's templates to ensure they continue working..
Remember that a template is always evaluated against a context object. When you render a template, values are looked up from that object. For example:
Hello, {{firstName}} {{lastName}}!
TODO: | |
- edit /opt/statsd/local.js | |
- correct the graphite host to localhost | |
- if desired, put 'debug: true' in there | |
- make the box accessible via the hostname 'graphite' | |
- update conf/storage-schemas.conf, see example for these retention rules: | |
6 hours of 10 second data | |
1 week of 1 minute data | |
5 years of 10 minute data |