zhubert

a tech blog

Batman.js and Rails Part 3, Views

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:

Batman.js and Rails Part 1, Server Side

Similar to my last few posts, I’d like to explore Batman.js through building a simple CRUD app. Specifically my requirements are:

  • Simple form CRUD
  • Routing of resources - nested, with nav, pagination
  • Associations - has_many, belongs_to
  • Rails idiom and integration - shouldn’t be an impedance mismatch
  • Data binding - views change automatically when data does
  • View Composition - weak, strong…just get it done
  • No Framework Poison Pills - that would be bugs and things that would jeopardize a production app
  • HAML/Coffeescript Friendly

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…

Ember.js and Rails Part 4, Client Views

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…

Ember.js and Rails, Part 3: Client Routing and Layout

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.

An Incomplete Education, Sort Of…

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!

Ember.js and Rails, Part 2: Client Side Data

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.

Getting Started With Octopress

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
$ rvm install 1.9.2 && rvm use 1.9.2
$ git clone git://github.com/imathis/octopress.git octopress # from ~/code
$ cd octopress
$ gem install bundler
$ bundle update
$ rake install