Managing display logic with classes
Looking at setup.coffee, we can see that a lot of the remaining code deals with formatting HTML output. A lot of it is specific to displaying animal descriptions, so let's start with that. We could move these functions to the Pet class, but it's considered a best practice to separate the business logic of your application from the display logic. Mixing data operations with display output tends to create tightly coupled code, making it very difficult to make changes to either the backend or the frontend later on.
Instead, we'll separate this logic into view classes. These will concern themselves with displaying the page and responding to user input, but will leave any manipulation of the data to the other classes. We'll start with the view for a single pet. Let's create a new class in pet_view.coffee.
class window.PetView constructor: (@pet) ->
This class' constructor takes a single argument, a Pet object. It will obtain values from this object when building...
