Let me set out my goal, so you’ll have some context to understand better why I did what I did and maybe even be able to see me going wrong as it happens.
My primary data source would be the third-party API mentioned above. It’s a pretty straightforward REST API that speaks JSON and does it in a pretty consistent way. I had already written a Python wrapper around the API, so I knew what to expect with my data access methods.
The page as concepted was a one-page app with mostly read views and only one action that would actually need to POST to the API and create new data.
Seemed really simple. I also have a deadline.
The First Problem
Given that Ember.js requires Handlebars.js and Backbone.js works really well with it, I had to figure out how to get my Handlebars templates into a Django template.
I ended up finding this template tag which let me wrap my Handlebars templates so that Django wouldn’t try to evaluate anything inside of the tag.
My Experience with Ember.js
Like a good programmer should, I first started by reading the documentation for Ember.js. But, like a lot of documentation, it is dense and not terribly good at painting the big picture.
I was excited to find that they had a guides section but frustrated that those guides weren’t exactly of the tutorial type.
Next, I was pointed to this essay by Trek Glowacki as a great resource for how to build an Ember.js app. And that it most certainly is.
However, it’s a step-by-step guide to build a massive app completely in Ember.js. It does not stop to answer questions about how these new concept might or might not match up with concepts with which the reader may be familiar.
That is, it’s a tutorial that requires you to forget everything else you know. This is a great way to truly learn something new, but it’s not so good for productivity under a deadline.
The First Code
With the first code I wrote, I attempted to follow Trek’s guide to the letter. I had outlets and routes and felt good about the structure I was laying out. However, it didn’t really seem to work.
Here’s a look at what the code basically looked like at this point.
Additionally, I was having issues with how the callbacks that are happening wouldn’t be finished in time for the code that needed to use their results.
You’ll remember the third-part API I talked about. It requires that a signature string be created and appended to every API call.
App.Signature = Ember.Object.extend();
this.signature = response;
Turns out, I didn’t know anything about promises or deferreds. This was one of the great things I learned when I asked this question on Stack Overflow. This is clearly not an Ember problem, but it was something great to learn.
I quickly realized that the outlets and routes wouldn’t work for me, mostly because it seemed like my simple app didn’t need them. They were just clouding my already muddled understanding of what I was doing.
The Second Code
Through some trials and tribulations, I eventually was able to cobble together some code that sort of worked. It seemed like I had a lot of verbose code that didn’t do much except to get things set up.
As a heavy jQuery user, I kept thinking to myself that the functionality I had could essentially be done in about half the code if I just used jQuery. Sure, it might not have the structure I was searching for, but the question still nagged.
This is the code as it stood and was sort of working.
The error that I had with this code was that The PostedPiblications data was always one action behind the PostedPubsCampaign selection. That is, if the app loaded with the data for campaign A, then the user changed the selection to campaign B, nothing would happen. I the user then selected campaign C, the PostedPublications shown on the page would belong to campaign B.
I could see that the correct API call was being made, but the page wasn’t updating as expected. After fighting for this for a full day, I posted this StackOverflow question that remains unanswered with 40 views.
Despite the fact that I had some code that worked moderately well, I still didn’t really understand why I needed controllers and views. The models didn’t seem to quite work the way my conception of models does (based on my experiences with Django and Sqlalchemy models).
You’ll notice that I posted a few question on StackOverflow while working through this Ember.js work. I was also in the #emberjs IRC channel often and asking questions in there. Adding to that numerous Google searches and bugging my coworkers and I was quickly exhausting my supply of resources.
Given the relative newness of Ember.js and the current lack of experienced folks who have built apps with it AND are willing to help in IRC, blog, answer SO questions, etc., it’s a challenging environment for a newbie. I did just stumble on EmberNoob and that may grow into a nice resource.
All of this trouble left me frustrated, confused and still staring at a looming deadline.
Trying out Backbone.js
At this point, one of my coworkers made the point that we were already using Backbone.js in many other places in our application. Now that I had a good sense of what I wanted to do in the app, it might be easier to learn Backbone instead of Ember.
I took essentially a day and ported the code I had over the Backbone.js and ended up with this bit of code.
With this, I couldn’t get past the point of a syntax error. JSLint wasn’t helping and no one in the office could figure it out. It was at this point, with 4 days of Ember experimentation and 1 day of Backbone coding, that my deadline pressure started tickling the back of my brain and I had to move on to technologies I already knew.
The tenor of this post might lead you to believe that I don’t like these two projects and think they aren’t valuable. Quite the contrary.
I’ll come back around to both Ember.js and Backbone.js again.
In the course of this work, I learned a good deal about promises and deferreds. Additionally, I was exposed to the beauty that is Underscore.js and Moment.js. That progress alone was worth delving into this stuff.
There are comments.