#ember-data

Model objects, defined by the ember-data library abstracts away the complexities involved with handling the communication with the server, serializing, as well as de-serializing of the response received from the server. In order to define your ember-data model object, you just need to extend the DS.Model object present in ember-data module as follows: Models form the core of any MVC design pattern as they describe the core business domain at hand. In Ember.js, every route has an associated model that describes the business domain that the route needs to work on. Almost all of the examples that we have seen so far operate on the static data that is returned from the model property of the routes. But most of the times the data that needs to be operated upon is not static and is fetched from a remote server.

Traditionally we have used jQuery or plain JavaScript to fetch the data from the server, using AJAX calls and then using those returned JSON objects as models in our application. This approach works well for applications that are simpler in nature, but very quickly get difficult to maintain when working on domains that are complex in nature, especially the ones that have relationships among them. We need to make sure that the correct relationship is linked and updated in our application.

The ember-data library tries to solve the problems highlighted earlier that are encountered in building single page web applications, by providing a standard way of accessing, finding, modifying, and saving the model objects of your application. By using the ember-data library, you can easily simplify your code that handles the communication with the backend server, by letting ember-data handle most of the complexity for you. This lets you focus more on solving the business problem at hand. The library also brings in a lot of optimizations to your code that improve the overall performance of your application.

Ember Data is designed to be agnostic to the underlying storage technique, and hence it works equally well will HTTP based JSON API, as well as streaming WebSockets.

The ember-data library is actively being developed and improved, and is under the beta quality. The API is highly stabilized and there are a lot of companies who have been using ember-data in production for quite some time now.

The current beta of ember-data is already included with Ember CLI and can be checked from the bower.json file, present in the project's root directory.

Defining ember-data models

Model objects, defined by the ember-data library abstracts away the complexities involved with handling the communication with the server, serializing, as well as de-serializing of the response received from the server. In order to define your ember-data model object, you just need to extend the DS.Model object present in ember-data module as follows: As you can see in the preceding code, we created a new file in app/models directory with the name book.js. The book object has a few differences from the objects we have seen so far.

I was talking with a developer at a javascript meetup about the #each helper in Ember.js and he said “It would be much better if the index was available” ... well guess what friend ... as of Ember 1.11 “index” is available with the #each helper!

I put together a little ember-cli project to demo it and I also threw in a couple other simple, but very useful things like fixtures example and some basic integration tests. 

You can view/fork/clone/copy the project at https://github.com/adamwysocki/eachExample

It’s super basic, but hopefully points some folks in the right direction. If you have any questions or there’s anything that you’d like to see, let me know in the comments below, I’m happy to help. 

If I get some more time I’ll try and expand on it a little ... I’d like to put the table into a component that changes the highlighting and page header as you click on the rows, I just ran out of time today.

With the new Ember Data 1.0 Beta I had the problem that my JSON had a reserved attribute name "model" that represented a Vehicle's make/model. This of course causes problems in your handlebars and probably everywhere else.

The easiest solution I found was to use a custom serializer for my Vehicle model and describe in there an attrs object.

App.VehicleSerializer = DS.RESTSerializer.extend({ attrs: { 'makeModel' : 'model' } });

Edit: This post describes what is probably a bad idea. If you're looking for a modern user session management pattern in Ember.js, look at the code of Discoure and this post about managing controller communication and dependencies in Ember.js

Warning: Unfinished design pattern ahead! Help polishing it is welcome.

Problem

If your app requires users to log in for certain views or actions, you need a good, universal (to the scope of your app) way of keeping track of user sessions. Polluting the global namespace by putting session data there is probably very doable, but ugly and a waste of the framework you've so lovingly built your app upon.

Solution

This is a job for Ember.StateManager! It provides the base for a finite–state machine, and that's really what we are doing here. This way we have a well–defined way of transitioning to and from a logged in and logged out state, as well as detecting the initial state so that user sessions are persisted between site visits.

In addition to the StateManager, we will have a Controller that contains the data about the logged-in user. In many cases you will want to just use an instance of your user model, if you have one.

Code

The userSessionStateManager

First, we declare our StateManager, which we'll call userSessionStateManager. The name is long but the readability is good.

App.userSessionStateManager = Em.StateManager.createWithMixins({

Notice the use of createWithMixins() instead of just the usual create(). This is because Em.Object.create() no longer supports functions that call their parent functions. I get the feeling that the purpose of this change was to enforce good convention.

Next our initialization function. Here we delegate the session detection to the controller and set the initial state.

init: function() { this._super(); signedIn = App.userSessionController.isLoggedIn(); if (signedIn) { this.initialState = 'loggedin'; } else { this.initialState = 'loggedout'; } },

We define our loggedin state here, again using createWithMixins().

loggedin: Em.State.createWithMixins({ enter: function(sm) { this._super(sm); App.userSessionController.loggedInUser.set('logged_in', true); }, exit: function(sm) { this._super(sm); } }), }); // userSessionStateManager ends here

The loggedout state is pretty much the same.

loggedout: Em.State.createWithMixins({ enter: function(sm) { this._super(sm); App.userSessionController.loggedInUser.set('logged_in', false); }, exit: function(sm) { this._super(sm); } }),

These example functions are very bare, but provide a basic and standardized way of executing setup and teardown code on login and logout.

The userSessionController

The controller provides details of the actual log in and log out process– That is, the code that results in a cookie being stored in the user's browser.

App.userSessionController = Em.Controller.create({

This initialization does not use createWithMixins(), because we never call any parent functions. Semantics are very important in Ember!

loggedInUser: App.User.createRecord({ id: null, username: null, logged_in: false }),

loggedInUser is a reference to an empty App.User model. You do not need to fill out every property of your model; Ember-data is not bothered by incomplete records, you might say to a fault. In fact, we have added a property here that does not exist in our User model: logged_in. Again, our persistence layer does not find this a reason to worry.

isLoggedIn: function(callback) { // log-in state checking action here, that probably $.post()s to an API, // which returns the username and id of the logged-in user (if any) // pretend with me that you got the data into an object called user if (logged_in) { App.userSessionStateManager.goToState('loggedin'); this.loggedInUser.set('id', user.id); this.loggedInUser.set('username', user.username); return true; } App.userSessionStateManager.goToState('loggedout'); return false; },

The details of actually checking the logged in status here are omitted because that is completely up to the back-end that you're using. In my work at Renderfarm.fi developing the front-end web application, this involved pinging an 'loggedIn' view in the authentication API in our Django back-end.

logIn: function(username, password) { // post to your log-in API, which again returns the username and id of the user upon success // in this pseudocode the data is in 'user' if (login_success) { App.userSessionStateManager.goToState('loggedin'); this.loggedInUser.set('id', user.id); this.loggedInUser.set('username', user.username); } },

This function just pings whatever API you are using with username and password values. At Renderfarm.fi, we encrypt both values with the CSRF token that Django gives us before sending the data to the server, to prevent eavesdropping.

logOut: function() { // post to the log-out portion of your API App.userSessionStateManager.goToState('loggedout'); this.loggedInUser.set('id', ''); this.loggedInUser.set('username', ''); }, }); // userSessionController ends here

This is the simplest function of them all, which just posts to the API. I suspect with most frameworks, no logic is required here, just a post. Be sure to protect that part of your API from CSRF attacks.

This is unfinished

I'm going to try to start a new thing: #emberpatterns. If you're an Ember.js person and you find a good pattern to solve a common problem, or even if you find a partial solution (As I have, see my next... tumbl? Is that right?), go ahead and post it with that hashtag.