To `attrs` or not to `attrs`

The advice to avoid attrs is still relevant as of Ember 2.12, and until angle bracket components are released in Ember.

In this post I will attempt to explain why you should avoid using attrs in your Ember.js application code.

tl;dr attrs is a Glimmer Component thing, and Glimmer Components haven’t landed on stable Ember.js yet.

Two Components

First, a bit of background on why attrs appeared. Currently we have a kind of component that is invoked with handlebars (curly braces), like this:

{{my-component}}

These have been around for a while, so for the sake of distinction we’ll call them Classic Components. Then, in the much mentioned Road to Ember 2.0 RFC and related blog post, a new kind of component was introduced that uses HTML-like invocation, like so:

<my-component>

Previously slated to land on the 1.x series, it has been postponed until some serious flaws are addressed

May 25, 2015

Controllers are dead; Long live Controllers

There has been a concern circulating the Ember.js community about the removal of controllers. In this post I will attempt to demystify what is happening and what you need to do to be future-proof.

Deprecations

Proxying

It is true that the proxying behaviour of controllers (ObjectController and ArrayController) is deprecated. In retrospect this behaviour created more confusion than it was helpful. In a proxying controller if you had {{foo}} in your template, it would first look up a foo property in the controller, and if the controller did not have a foo property, it would then look up foo in the model. ArrayController also had a special feature called item controllers which can be implemented with components instead.

This means that when using Ember.Controller, which does not have the proxying behaviour, {{foo}} is equivalent to {{controller.foo}}. If you want the model’s foo

Continue reading →

Model inheritance for Ember.js routes

Update 2014-04-01

As of Ember.js 1.5.0 this feature is enabled by default for release builds.

Update 2014-02-10

As of commit b351b4a7c41dbaa5d4b1c5508f02df6b957018c7 this feature is enabled by default. This includes Canary builds.

I’ve just helped push a feature to Ember.js’ master that might help you shave off a couple of lines of code. By switching on the ember-routing-inherits-parent-model feature flag your routes will inherit the model from the parent resource by default.

At the moment resources won’t inherit the model from their parents, but that might change in the future, depending on how appropriate the core team deems it.

Getting the right Ember.js

You will have to grab the build from the Canary page. You can read more about the different build channels in the Getting Started section of the guides.

Enabling the feature

First you should read through the section on the

Laravel up and running on Cloud9

Setting up

The other day I decided to try out Laravel since I kept hearing about it and maintain a PHP website myself. The weekend previous I had developed a small node.js package using nitrous.io, so I figured I’d spare my laptops from the likely scenario of poorly installed dependencies and set out to find a suitable service since nitrous.io does not support PHP.

I picked Cloud9 IDE, having used it previously, and after fumbling a bit I came upon these easy steps to have a working Laravel application:

$ c9pm install php
$ curl -sS https://getcomposer.org/installer | php
$ mv composer.phar ../bin/composer
$ composer create-project laravel/laravel <project name> --prefer-dist

In order, they do the following:

Install PHP;
Download [http://getcomposer.org/](Composer);
Move Composer to a path available globally, so you can just call composer;
Create a Laravel project, substitute

Ricardo Mendes

Ember.js documenteur

Read this first