Connecting to a database

1
2

$ psql postgres     # the default database
$ psql database_name

Connecting as a specific user

1
2

$ psql postgres john
$ psql -U john postgres

Ever since I saw the testing slides from EmberCamp I was thinking about testing. Up until now I’ve been using Capybara which is really really really slow.

But @joliss mentioned this thing called Ember.testing which should automagically fix all of the async problems which make tests ugly, such as waiting for the application to initialize and finish routing.

In its essence Ember.testing = true disables the automatic runloop, which gives you the control to manually schedule asynchronous operations to happen in a one-off runloop via Ember.run.

Ember.run will run the given function inside a runloop and flush all of the bindings before it finishes, which means you can render a view inside Ember.run and check the DOM right after that. Here’s an example from the Ember.View tests

There are many ways one can DRY up templates when using Ember.js, it all depends on what you’re trying to achieve.

Router is the core part of Ember. Every time we go to a new URL it means the route object is called with our params and stuff. These are the hooks sorted in order in which they are called

We talked about transactions in one of the previous articles (read it if you haven’t already), but we didn’t really touch on when to use them in real world. One of the most common use cases for me is when I just want to manage a single record while there are many changes happening on the page.

Adding a record to a transaction is simple

Ever since the change to resource and route a lot of people are confused about the meaning of the two and how they affect naming. Here’s the difference:

• resource - a thing
• route - something to do with the thing

Let’s say we have a model App.Post and we want to show a list of posts and a new post form. There are many ways you can go about this, so let’s start with the simplest.

One of the common things people ask about Ember Data is how to find a single record by it’s attribute. This is because the current revision (11) only offers three methods of fetching records

1
2
3

App.User.find(1) // returns a single user record
App.User.find({ username: "wycats" }) // returns a ManyArray
App.User.findQuery({ username: "wycats" }) // same as the above

When you first come to Ember, you’ll soon stumble upon three things:

• Ember.Controller
• Ember.ObjectController
• Ember.ArrayController

For some people (including me) it is not very clear what’s the difference between the first two.

Ember.Controller is just a plain implementation of Ember.ControllerMixin, while Ember.ObjectController is a subclass of Ember.ObjectProxy. This is a huge difference! Let’s take a look at how Ember.ObjectProxy works, and as always starting with a code sample (taken from the excellent source code documentation).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

object = Ember.Object.create({
  name: "foo"
});

proxy = Ember.ObjectProxy.create({
  content: object
});

// Access and change existing properties
proxy.get("name") // => "foo"
proxy.set("name", "bar");
object.get("name") // => "bar"

// Create new "description" property on `object`
proxy.set("description", "baz");
object.get("description") // => "baz"

There is really no magic. In the basic usage, Ember.ObjectProxy will delegate all of it’s unknown properties to the content object, with one exception.

If we try to set a new property on a proxy while it’s content is undefined, we will get an exception.

1
2

proxy = Ember.ObjectProxy.create();
proxy.set("foo", "bar"); // raises the following exception

1
2

Cannot delegate set('foo', bar) to the 'content' property
of object proxy <Ember.ObjectProxy:ember420>: its 'content' is undefined.

I’ve stumbled upon this in one scenario, where I didn’t set content for my ObjectController, but I tried to modify one of it’s properties. Raising the exception is a good example of failing fast, rather than silently swallowing errors.

This being said you should almost always use Ember.ObjectController over Ember.Controller, unless you know what you’re doing :)

Since state management is such a huge part of Ember.js it desrves a dedicated article. I’m not going to explain the old router which used Ember.StateManager to do it’s bidding. Those days are over and we should all be moving towards the v2 router (or v2.2 so to speak). Instead we’re going to go deep into the Ember.StateManager.

In the general concept, state manager is basically some object which manages states and the transitions between them, thus representing a finite state machine.

As some of you might now, Ember provides you with something called concatenated property. Their main use case is internal, which means you are unlikely to have the need to use them in your own application. There are some places in Ember where you might be surprised by how things behave and this might be one of those. Let’s start with an example.