A Tale of Two MVCs (A brief history of GUIs) - Yehuda Katz
- Introduction
  - speaker doing best to keep from being dry
  - technical detail about what does it mean when one says GUI
  - Motivation
    - "Current JavaScript solutions suffer from "Double MVC". You need both server and client-side MVC stacks. Conceptual complexity is very high." - DHH
    - Speaker says it makes no sense, MVC means two different things in different context.
  - In the beginning you must:
    - bootstrap objects
      - becomes more complicated the more complex your application gets
    - draw initial UI
    - translate Raw Input into User Intent
      - user did something into user means something
    - update application state
      - use the UI to drive the application state machine
    - update domain objects
      - make the state persistent (if objects are persistent)
    - notify UI of changes
    - update UI
  - Every system has stages of these... no matter how they manage to implement the MVC concept
  - At the beginning Everything manual (jQuery)
    - DOM ready, Event Handlers, Save with some AJAX thing.. do everything in your event handlers except for bootstrap objects and draw initial UI
  - In the '80s and oddly enough in '06 people learned this was a bad thing
    - example: backbone
    - separating presentation from state is very much like "MVC"
      - instead of everything happening in the view, all input goes through the controller and the view only draws
    - overview
      - bootstrap objects: adhoc
      - draw initial UI: view
      - translates raw input into intent: controller
      - update app state: controller
      - update domain objects: controller
      - notify UI of changes: observers and controller
      - update UI: view
    - problems
      - bootstrapping (it's adhoc)
      - hierarchy
      - application state
    - Rails
      - all raw user input is intercepted by the browser
      - effectively HTTP becomes a transport which we communicate with via markup
      - overview
        - bootstrap objects: router and controller
        - draw inital UI: view
        - raw input to user interpret: template/browser precomputed
        - update app state: controller in the session
        - update domain objects: controller persisted by ActiveRecord
        - notify UI of changes: http
        - update UI: browser
      - problems
        - hierarchy (no mechanism)
        - maintain browser state
        - latency
        - limited to browser mark-up
    - JavaScript
      - an improvement but still has problems
    - Presentation Model (VisualWorks)
      - Model notifies Presentation Model which then notifies the view, instead of model notifying view directly
      - adds a lot of value
      - related to presenters
      - easy to test, not bound up in UI
      - job is to separate the preparation of the view from drawing it
      - retains separation of drawing from raw event handling and interpretation
        - a special place to put logic for view information that isn't related to rendering
      - examples:
        - convert model number to visual colour
    - Coordinating/Mediating Controller (Cocoa)
      - Doesn't have the separation of View and Controller
      - goes back to the original interpretation where one object handles input and draws
      - Very similar to the Presentation Model but collapses the view into one thing because it admits they're tightly coupled anyway
      - Manages application wide state with coordinating controllers which respond to notifications (a decoupling strategy)
      - overview
        - bootstrap: coordinating controller
        - draw initial UI: view
        - raw input to user intent: view
        - application state: coordinating controller
        - <speaker moved too fast, couldn't copy>
      - problems
        - figuring out what to bootstrap
        - organising coordinating controllers
        - <speaker running out of time... moves too fast to copy>
    - Ember
      - Similar to the cocoa model above
      - UI, View, Controller, Model
      - Route is the coordinating controller
      - overview
        - <speaker is moving too fast to copy>
      - visual overview (see slides)
  - Double MVC doesn't matter -- who cares. It's just a pattern to solve a problem. With Ember Rails is only responsible for persistence.
- Closing and Thanks