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…

So, views in Ember are not like views in Rails, to me they feel a lot more like a controller/presenter hybrid, perhaps like a ViewController in iOS. In fact, frequently while working on this form crud test app, I found I had a hard time deciding what logic should be in the view vs. being in the controller. This was compounded by quite a few examples on the web putting model access in the view, but I just couldn’t abide doing that, so I’ve tried to split things out as follows: template specific interactions in the views, and model interactions in the controller, but it didn’t work well.

First up, we have to make a bunch of views that just point to the templates. In the future, these would have all sorts of interesting logic…but not so much now (showing a subset):

1
2
3

App.MainHomeView = Ember.View.extend(
  templateName: "ember/templates/main/home"
)

1
2
3

App.MainLayoutView = Ember.View.extend(
  templateName: "ember/templates/main/layout"
)

1
2
3
4

App.PostsIndexView = Ember.View.extend(
  templateName: "ember/templates/posts/index"
  postsBinding: "App.postsController"
)

1
2
3

App.PostsLayoutView = Ember.View.extend(
  templateName: "ember/templates/posts/layout"
)

One interesting thing in the index view, I wanted “posts” to come from App.postsController and be updated whenever it changes. If you are used to managing @render by hand in Backbone, the Binding funtionality in Ember will be a very welcome change.

The new/edit views are different. As you see below, I tried to have the controller create the post on behalf of the view:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

App.PostsNewView = Ember.View.extend(
  tagName: "form"
  templateName: "ember/templates/posts/new"
  classNames: ["form-horizontal"]

  # different than edit to enable validation for new objects
  init: ->
    @_super()

  # called when added to the dom, like viewDidLoad
  didInsertElement: ->
    @_super()
    @$("input:first").focus()

  cancelForm: ->
    App.router.set('location','posts')

  submit: (event) ->
    formTitle = @get('title')
    formBody = @get('body')
    App.postsController.createPost({title: formTitle, body: formBody})
    event.preventDefault()
    App.router.set('location','posts')
)

For reference, this edit view changes the model directly without a controller mediating. I ran out of time evaluating Ember so I was unable to refactor it like I did with the newView above:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

App.PostsEditView = Ember.View.extend(
  tagName: "form"
  templateName: "ember/templates/posts/edit"
  classNames: ["form-horizontal"]

  # called when added to the dom, like viewDidLoad
  didInsertElement: ->
    @transaction = App.store.transaction()
    @transaction.add @get("post")
    @_super()
    @$("input:first").focus()

  cancelForm: ->
    @transaction.rollback()
    App.router.set('location','posts')

  submit: (event) ->
    post = @get("post")
    validationErrors = post.validate()
    event.preventDefault()
    if validationErrors isnt `undefined`
      App.displayError validationErrors
    else
      @transaction.commit()
      App.router.set('location','posts')
)

So, what about the controller?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

App.postsController = Ember.ArrayController.create(
  selectedPost: null

  # controllers can persist state nicely
  selectPost: (postId) ->
    @set 'selectedPost', App.store.find(App.Post,postId)

  findAll: ->
    @set 'content', App.store.findAll(App.Post) unless @get('content')

  # rather pointless transaction, also needs
  # error handling
  createPost: (data) ->
    @transaction = App.store.transaction()
    @transaction.createRecord(App.Post,data)
    @transaction.commit()
)

So with New, I get clean separation of concerns but no error handling. With the Edit pattern, I get the latter and not the former. Ugh. If I wanted to spend more time on this, it could be easily fixed by passing more state around, but this is already taking too long.

At around this time, I started hitting a different wall with Ember. It was a wall made of run loop issues, model state machine constraints, binding order dependencies, ember-data association problems, performance and latency challenges…it really felt like I just needed to wait a bit longer for the Ember core team to get it further down field. They have all these items in the issue tracker on Github and are amazing Developers. I anticipate writing about Ember again and using it in a future project, but I need to build something now and the Devs have said it’s Alpha.

Shortly after I ran into this hurdle with Ember, I got a text from my boss to take a look at Batman.js, and I’m very happy he did. Batman is what I want today from a JS Framework…and it’s almost 1.0! More next time.

You can see all the unfinished code for this app on github.