Last time, we quickly setup our app’s models and controllers…noting that they looked very similar to their server-side brethren.
Now let’s get some views…binding is done via HTML5 data- attributes, which is nice for your designer friends:
Last time, we quickly setup our app’s models and controllers…noting that they looked very similar to their server-side brethren.
Now let’s get some views…binding is done via HTML5 data- attributes, which is nice for your designer friends:
So, Rails is ready, let’s get Batman talking. It turns out to be really easy.
First let’s run the generator that comes with batman-rails:
1
| |
Similar to my last few posts, I’d like to explore Batman.js through building a simple CRUD app. Specifically my requirements are:
This first post is going to be really similar to getting ready for Ember, but has a few differences now that I’ve carried the Batman implementation all the way through and some master branches have changed (life on the edge). Here we go…
Since I’m moving on from Ember for now, here’s one last recipe to almost get some real-time single model functionality with Pusher and Ember.
Last time we found some cool libraries to complement Ember.js by throwing a state machine at our routing dilemma. It was verbose, but it met our need. With the router in place, we now need some views to respond to the router and render the templates (the logic-less presentation layer). Lots of code, on we go…
In the first part of this series, I built a working Rails server vending a super simple API. In the second post, I made the simple connection to model level integration in the client. Now, let’s see if we can get a single resource working in the client, just like a scaffolded server side implementation. It’s not going to be super useful, but it should be a building block for more useful things.
So, we’ll need a working router, controller, views, and templates. Sounds like a few posts…ah well.
I didn’t study Computer Science in college, and to a degree, I’ve always wondered what I missed.
Almost 30 years ago, I learned to program the first computer in our home, the venerable Timex Sinclair ZX81. Ever since then, I have been constantly coding…but I found Physics and Math to be more interesting to me for my fields of academic study.
What’s interesting, of course, is that everything I worked on as an undergrad had me writing software. Though my study was Physics, my practice was all software. After graduating and some additional graduate education, I got caught up in the whole Internet thing and have been coding ever since.
Well, after so many years working in software and building cool stuff, it’s time for me to fill in that incomplete education. To start it off, I’m going to read Skiena and blog a bit about my experience.
This should be fun!
Previously I setup a Rails server to vend the most basic JSON API using the very interesting ActiveModelSerializers gem. Now it’s time to turn my attention to hooking up Ember.js. Specifically my goal in this series is to build a single resource like Rails scaffolding, but have most of the work on the client side and just APIs, auth, and business logic on the server.
Today, I’d like to look at building an app with a Rails server-side implementation and an Ember.js client. The goal of this post is to get Ember and Rails integrated and a single resource fully wired up.
I’ve done some work in Backbone.js and Spine.js, but the Keynote by @wycats yesterday has motivated me to take a look at Ember, so let’s dig in.
So I decided to use Octopress for all sorts of wonderful reasons…simple to setup, free to host on Github, looks nice, writing entries like I write code.
Here’s what I did to get it working (assumes you have the basics installed):
1 2 3 4 5 6 | |