daily pastebin goal
77%
SHARE
TWEET

Untitled

a guest Sep 20th, 2013 110 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. A Tale of Two MVCs (A brief history of GUIs) - Yehuda Katz
  2. - Introduction
  3.   - speaker doing best to keep from being dry
  4.   - technical detail about what does it mean when one says GUI
  5.   - Motivation
  6.     - "Current JavaScript solutions suffer from "Double MVC". You need both server and client-side MVC stacks. Conceptual complexity is very high." - DHH
  7.     - Speaker says it makes no sense, MVC means two different things in different context.
  8.   - In the beginning you must:
  9.     - bootstrap objects
  10.       - becomes more complicated the more complex your application gets
  11.     - draw initial UI
  12.     - translate Raw Input into User Intent
  13.       - user did something into user means something
  14.     - update application state
  15.       - use the UI to drive the application state machine
  16.     - update domain objects
  17.       - make the state persistent (if objects are persistent)
  18.     - notify UI of changes
  19.     - update UI
  20.   - Every system has stages of these... no matter how they manage to implement the MVC concept
  21.   - At the beginning Everything manual (jQuery)
  22.     - DOM ready, Event Handlers, Save with some AJAX thing.. do everything in your event handlers except for bootstrap objects and draw initial UI
  23.   - In the '80s and oddly enough in '06 people learned this was a bad thing
  24.     - example: backbone
  25.     - separating presentation from state is very much like "MVC"
  26.       - instead of everything happening in the view, all input goes through the controller and the view only draws
  27.     - overview
  28.       - bootstrap objects: adhoc
  29.       - draw initial UI: view
  30.       - translates raw input into intent: controller
  31.       - update app state: controller
  32.       - update domain objects: controller
  33.       - notify UI of changes: observers and controller
  34.       - update UI: view
  35.     - problems
  36.       - bootstrapping (it's adhoc)
  37.       - hierarchy
  38.       - application state
  39.     - Rails
  40.       - all raw user input is intercepted by the browser
  41.       - effectively HTTP becomes a transport which we communicate with via markup
  42.       - overview
  43.         - bootstrap objects: router and controller
  44.         - draw inital UI: view
  45.         - raw input to user interpret: template/browser precomputed
  46.         - update app state: controller in the session
  47.         - update domain objects: controller persisted by ActiveRecord
  48.         - notify UI of changes: http
  49.         - update UI: browser
  50.       - problems
  51.         - hierarchy (no mechanism)
  52.         - maintain browser state
  53.         - latency
  54.         - limited to browser mark-up
  55.     - JavaScript
  56.       - an improvement but still has problems
  57.     - Presentation Model (VisualWorks)
  58.       - Model notifies Presentation Model which then notifies the view, instead of model notifying view directly
  59.       - adds a lot of value
  60.       - related to presenters
  61.       - easy to test, not bound up in UI
  62.       - job is to separate the preparation of the view from drawing it
  63.       - retains separation of drawing from raw event handling and interpretation
  64.         - a special place to put logic for view information that isn't related to rendering
  65.       - examples:
  66.         - convert model number to visual colour
  67.     - Coordinating/Mediating Controller (Cocoa)
  68.       - Doesn't have the separation of View and Controller
  69.       - goes back to the original interpretation where one object handles input and draws
  70.       - Very similar to the Presentation Model but collapses the view into one thing because it admits they're tightly coupled anyway
  71.       - Manages application wide state with coordinating controllers which respond to notifications (a decoupling strategy)
  72.       - overview
  73.         - bootstrap: coordinating controller
  74.         - draw initial UI: view
  75.         - raw input to user intent: view
  76.         - application state: coordinating controller
  77.         - <speaker moved too fast, couldn't copy>
  78.       - problems
  79.         - figuring out what to bootstrap
  80.         - organising coordinating controllers
  81.         - <speaker running out of time... moves too fast to copy>
  82.     - Ember
  83.       - Similar to the cocoa model above
  84.       - UI, View, Controller, Model
  85.       - Route is the coordinating controller
  86.       - overview
  87.         - <speaker is moving too fast to copy>
  88.       - visual overview (see slides)
  89.   - Double MVC doesn't matter -- who cares. It's just a pattern to solve a problem. With Ember Rails is only responsible for persistence.
  90. - Closing and Thanks
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top