I defined toString on both of the models because when a JS object instance is rendered as text, toString is called automatically.
My app defines /crepes and /ingredients, and I want each of those pages to show a side-bar nav that lists all items and provides a link to create a new item. So, I added a nav to my Rails layout where I will render my Creperie.ContextNavView. I attach the Batman.View with the data-view view binding:
Then, I defined a custom Batman.View called ContextNavView.
I defined the prototype’s source attribute to point to the HTML template which I will create next. That way, Batman knows where to find the HTML for this view. This is the same as passing the source to the constructor, eg, new Creperie.ContextNavView(source: 'layouts/context_nav').
I also defined the viewDidAppear hook for this view. You can define hooks for any point in a Batman.View’s lifecycle. I set up an observer on my app’s currentRoute.controller.
classCreperie.ContextNavViewextendsCreperie.ApplicationViewsource: 'layouts/context_nav'# my HTML templateviewDidAppear: ->Creperie.observe"currentRoute.controller",(newValue, oldValue) ->currentController = newValueitemClassName = Batman.helpers.singularize(Batman.helpers.camelize(currentController))# camelize and singularize the controller nameitemClass = Creperie[itemClassName]ifitemClass?@set'itemClass',itemClass@set'itemRoute',currentController
This is made possible because Batman (v 0.15.0) keeps track of the current route at MyApp.currentRoute (which you can access in your code or in the console as MyApp.get('currentRoute')). Since my controllers are all defined with Rails-style names, I can count on the controller names matching the model that I want to display.
Last, I defined the template which ContextNavView uses as its source: