Merge pull request #11 from ember-learn/feature/fix-images

fix and flatten images

Author: acorncom

guides/v1.10.0/controllers/index.md

@@ -80,7 +80,7 @@ nothing about which (if any) controllers are decorating it, and
 controller does not know which views are presenting its properties.
 
 <figure>
-<img src="../images/controller-guide/objects.png">
+<img src="/images/controller-guide/objects.png">
 </figure>
 
 This also means that as far as a template is concerned, all of its

guides/v1.10.0/getting-started/planning-the-application.md

@@ -1,7 +1,7 @@
 TodoMVC, despite its small size, contains most of the behaviors typical in modern single page applications. Before continuing, take a moment to understand how TodoMVC works from the user's perspective.
 
 TodoMVC has the following main features:
-<img src="../images/todo-mvc.png" width="680">
+<img src="/images/todo-mvc.png" width="680">
 
   1. It displays a list of todos for a user to see. This list will grow and shrink as the user adds and removes todos.
 

guides/v1.10.0/models/index.md

@@ -209,7 +209,7 @@ adapter. Your adapter will go and retrieve the record from your
 persistence layer; typically, this will be a JSON representation of the
 record served from an HTTP server.
 
-![Diagram showing process for finding an unloaded record](../images/guides/models/finding-unloaded-record-step1-diagram.png)
+![Diagram showing process for finding an unloaded record](/images/models/finding-unloaded-record-step1-diagram.png)
 
 As illustrated in the diagram above, the adapter cannot always return the
 requested record immediately. In this case, the adapter must make an
@@ -228,12 +228,12 @@ The store then takes that JSON, initializes the record with the
 JSON data, and resolves the promise returned to your application
 with the newly-loaded record.
 
-![Diagram showing process for finding an unloaded record after the payload has returned from the server](../images/guides/models/finding-unloaded-record-step2-diagram.png)
+![Diagram showing process for finding an unloaded record after the payload has returned from the server](/images/models/finding-unloaded-record-step2-diagram.png)
 
 Let's look at what happens if you request a record that the store
 already has in its cache.
 
-![Diagram showing process for finding an unloaded record after the payload has returned from the server](../images/guides/models/finding-loaded-record-diagram.png)
+![Diagram showing process for finding an unloaded record after the payload has returned from the server](/images/models/finding-loaded-record-diagram.png)
 
 In this case, because the store already knew about the record, it
 returns a promise that it resolves with the record immediately. It does

guides/v1.10.0/routing/link-to-router-flow.md

@@ -23,7 +23,7 @@ App.Router.map(function() {
 This would mean there are currently three nested active routes in this
 application. The `ApplicationRoute`, `AboutRoute` and the `AboutFaqRoute`.
 
-<img src="../images/guides/routing/active-route.png" alt="Active route" class="highlight">
+<img src="/images/guides/routing/active-route.png" alt="Active route" class="highlight">
 
 Lets assume a user clicks on a `link-to` for the `UserProfileRoute` like
 the one below.
@@ -48,7 +48,7 @@ Next Ember will trigger a `willTransition` action on the currently
 active routes starting with the leaf-most route (in this example the
 `AboutFaqRoute`).
 
-<img src="../images/guides/routing/willtransition-event.png" alt="Active route" class="highlight">
+<img src="/images/guides/routing/willtransition-event.png" alt="Active route" class="highlight">
 
 The argument for the `willTransition` action is the transition
 object. This gives each active route, the opportunity to decide
@@ -89,7 +89,7 @@ as well as allow for any of the
 hooks to reject elsewhere. If any of these hooks return a promise, the
 transition will pause until the promise resolves/rejects.
 
-<img src="../images/guides/routing/route-model-validation.png" alt="Active route" class="highlight">
+<img src="/images/guides/routing/route-model-validation.png" alt="Active route" class="highlight">
 
 If the promise rejects, and `error` action is triggered from the
 erroring route and upwards with the rejected/thrown error. Calling
@@ -107,7 +107,7 @@ routes and
 [setup](http://emberjs.com/api/classes/Ember.Route.html#method_setup)
 on the newly entered routes.
 
-<img src="../images/guides/routing/sync-phase.png" alt="Active route" class="highlight">
+<img src="/images/guides/routing/sync-phase.png" alt="Active route" class="highlight">
 
 If any errors are thrown, the transition promise will be rejected and
 the `error` action will be triggered from the erroring route and

guides/v1.10.0/templates/actions.md

@@ -117,7 +117,7 @@ When an action is triggered, but no matching action handler is
 implemented on the controller, the current route, or any of the
 current route's ancestors, an error will be thrown.
 
-![Action Bubbling](../images/template-guide/action-bubbling.png)
+![Action Bubbling](/images/template-guide/action-bubbling.png)
 
 This allows you to create a button that has different behavior based on
 where you are in the application. For example, you might want to have a

guides/v1.10.0/understanding-ember-data/record-lifecycle.md

@@ -29,30 +29,30 @@ When you request a record using `Person.find(1)`, Ember Data will ask
 the store to find the record (`store.find(Person, 1)`).
 
 <figure>
-  <img src="../images/ember-data-guide/step1.png">
+  <img src="/images/ember-data-guide/step1.png">
 </figure>
 
 If the adapter has not already loaded the record into the store, the
 store will ask the adapter to fetch it.
 
 <figure>
-  <img src="../images/ember-data-guide/step2.png">
+  <img src="/images/ember-data-guide/step2.png">
 </figure>
 
 Since the adapter's request is asynchronous, the store will return a new
 `Person` instance immediately. At this point, the record has no backing
 data.
 
 <figure>
-  <img src="../images/ember-data-guide/step3.png">
+  <img src="/images/ember-data-guide/step3.png">
 </figure>
 
 ## Step 2: Adapter Loads Data Into the Store
 
 At some point later, the server will return some data to the adapter.
 
 <figure>
-  <img src="../images/ember-data-guide/step5.png">
+  <img src="/images/ember-data-guide/step5.png">
 </figure>
 
 Once the adapter receives the data hash, it loads it into the store.
@@ -63,7 +63,7 @@ This will, in turn, notify all attributes (`DS.attr`) and relationships
 (`DS.hasMany` and `DS.belongsTo`).
 
 <figure>
-  <img src="../images/ember-data-guide/step6.png">
+  <img src="/images/ember-data-guide/step6.png">
 </figure>
 
 ## Step 3: Getting an Attribute
@@ -83,7 +83,7 @@ data hash loads in from the server, the registered observer will call
 `person.get('firstName')`.
 
 <figure>
-  <img src="../images/ember-data-guide/step7.png">
+  <img src="/images/ember-data-guide/step7.png">
 </figure>
 
 ## Step 4: Materialization
@@ -92,15 +92,15 @@ Because this is the first time the record needs its backend-provided
 data, it will ask the store to load it in using `materializeData`.
 
 <figure>
-  <img src="../images/ember-data-guide/step8.png">
+  <img src="/images/ember-data-guide/step8.png">
 </figure>
 
 The store will, in turn, ask the adapter to materialize the data. This
 allows the adapter to apply adapter-specific mappings to the
 backend-provided data hash.
 
 <figure>
-  <img src="../images/ember-data-guide/step9.png">
+  <img src="/images/ember-data-guide/step9.png">
 </figure>
 
 Finally, the adapter asks its serializer object to perform the
@@ -110,27 +110,27 @@ backend-provided data hashes into records, and serializing records into
 JSON hashes for the backend.
 
 <figure>
-  <img src="../images/ember-data-guide/step10.png">
+  <img src="/images/ember-data-guide/step10.png">
 </figure>
 
 The serializer is now responsible for extracting the information from
 the backend-provided data hash and hydrating the record object. First,
 it populates the record's `id`.
 
 <figure>
-  <img src="../images/ember-data-guide/step11.png">
+  <img src="/images/ember-data-guide/step11.png">
 </figure>
 
 Next, it populates the record's attributes.
 
 <figure>
-  <img src="../images/ember-data-guide/step12.png">
+  <img src="/images/ember-data-guide/step12.png">
 </figure>
 
 Finally, it populates the `belongsTo` association.
 
 <figure>
-  <img src="../images/ember-data-guide/step13.png">
+  <img src="/images/ember-data-guide/step13.png">
 </figure>
 
 Once the adapter finishes materializing the record, it returns the
@@ -164,7 +164,7 @@ template would look something like this:
 {{#if isLoaded}}
   <p>{{name}}</p>
 {{else}}
-  <img src="../images/spinner.gif">
+  <img src="/images/spinner.gif">
 {{/if}}
 ```
 

guides/v1.10.0/understanding-ember/the-view-layer.md

@@ -21,7 +21,7 @@ In a typical client-side application, views may represent elements nested inside
 Here is a simple example, representing one main app view, a collection nested inside of it, and individual items nested inside of the collection.
 
 <figure>
-  <img src="../../images/view-guide/view-hierarchy-simple.png">
+  <img src="/images/view-guide/view-hierarchy-simple.png">
 </figure>
 
 This system works well at first glance, but imagine that we want to open Joe's Lamprey Shack at 8am instead of 9am. In this situation, we will want to re-render the App View. Because the developer needed to build up the references to the children on an ad-hoc basis, this re-rendering process has several problems.
@@ -31,7 +31,7 @@ In order to re-render the App View, the App View must also manually re-render th
 In order to avoid these problems, Ember's view hierarchy has the concept of child views baked in.
 
 <figure>
-  <img src="../../images/view-guide/view-hierarchy-ember.png">
+  <img src="/images/view-guide/view-hierarchy-ember.png">
 </figure>
 
 When the App View re-renders, Ember is responsible for re-rendering and inserting the child views, not application code. This also means that Ember can perform any memory management for you, such as cleaning up observers and bindings.
@@ -45,13 +45,13 @@ In the past, web developers have added event listeners to individual elements in
 However, this approach often does not scale when dealing with large numbers of interactive elements. For example, imagine a `<ul>` with 100 `<li>`s in it, with a delete button next to each item. Since the behavior is the same for all of these items, it would be inefficient to create 100 event listeners, one for each delete button.
 
 <figure>
-  <img src="../../images/view-guide/undelegated.png">
+  <img src="/images/view-guide/undelegated.png">
 </figure>
 
 To solve this problem, developers discovered a technique called "event delegation". Instead of registering a listener on each element in question, you can register a single listener for the containing element and use `event.target` to identify which element the user clicked on.
 
 <figure>
-  <img src="../../images/view-guide/delegated.png">
+  <img src="/images/view-guide/delegated.png">
 </figure>
 
 Implementing this is a bit tricky, because some events (like `focus`, `blur` and `change`) don't bubble. Fortunately, jQuery has solved this problem thoroughly; using jQuery's `on` method reliably works for all native browser events.
@@ -75,7 +75,7 @@ While the process of displaying a template is automatic for developers, under th
 This is the approximate lifecycle of an Ember view:
 
 <figure>
-  <img src="../../images/view-guide/view-lifecycle-ember.png">
+  <img src="/images/view-guide/view-lifecycle-ember.png">
 </figure>
 
 ##### 1. Template Compilation
@@ -99,7 +99,7 @@ Once the main view has finished rendering, the render process has created a tree
 Here is a simple example:
 
 <figure>
-  <img src="../../images/view-guide/render-buffer.png">
+  <img src="/images/view-guide/render-buffer.png">
 </figure>
 
 In addition to children (Strings and other `RenderBuffer`s), a `RenderBuffer` also encapsulates the element's tag name, id, classes, style, and other attributes. This makes it possible for the render process to modify one of these properties (style, for example), even after its child Strings have rendered. Because many of these properties are controlled via bindings (e.g. using `bind-attr`), this makes the process robust and transparent.
@@ -130,7 +130,7 @@ In addition to these cases, the application may sometimes want to explicitly re-
 The process looks something like:
 
 <figure>
-  <img src="../../images/view-guide/re-render.png">
+  <img src="/images/view-guide/re-render.png">
 </figure>
 
 ### The View Hierarchy
@@ -156,7 +156,7 @@ var view = Ember.View.create({
 This will create a small view hierarchy that looks like this:
 
 <figure>
-  <img src="../../images/view-guide/simple-view-hierarchy.png">
+  <img src="/images/view-guide/simple-view-hierarchy.png">
 </figure>
 
 You can move around in the view hierarchy using the `parentView` and `childViews` properties.
@@ -227,14 +227,14 @@ please use the form below to submit a complaint to the FDA.
 Rendering this template would create a hierarchy like this:
 
 <figure>
-  <img src="../../images/view-guide/public-view-hierarchy.png">
+  <img src="/images/view-guide/public-view-hierarchy.png">
 </figure>
 
 Behind the scenes, Ember tracks additional virtual views for the
 Handlebars expressions:
 
 <figure>
-  <img src="../../images/view-guide/virtual-view-hierarchy.png">
+  <img src="/images/view-guide/virtual-view-hierarchy.png">
 </figure>
 
 From inside of the `TextArea`, the `parentView` would point to the
@@ -445,7 +445,7 @@ Calling `appendChild` does two things:
    buffer.
 
 <figure>
-  <img src="../../images/view-guide/template-appendChild-interaction.png">
+  <img src="/images/view-guide/template-appendChild-interaction.png">
 </figure>
 
 You may not call `appendChild` on a view after it has left the rendering
@@ -534,7 +534,7 @@ is automatically instantiated, if necessary, and added to the
 `childViews` array.
 
 <figure>
-  <img src="../../images/view-guide/container-view-shorthand.png">
+  <img src="/images/view-guide/container-view-shorthand.png">
 </figure>
 
 ### Template Scopes

guides/v1.10.0/views/index.md

@@ -19,7 +19,7 @@ application.
 For example, imagine you have a list of todo items. Next to each todo is
 a button to delete that item:
 
-![Todo List](./images/todo-list.png)
+![Todo List](/images/views/todo-list.png)
 
 The view is responsible for turning a _primitive event_ (a click) into a
 _semantic event_: delete this todo! These semantic events are first sent
@@ -28,4 +28,4 @@ router, which is responsible for reacting to the event based on the
 current state of the application.
 
 
-![Todo List](./images/primitive-to-semantic-event.png)
+![Todo List](/images/views/primitive-to-semantic-event.png)

guides/v1.11.0/controllers/index.md

@@ -80,7 +80,7 @@ nothing about which (if any) controllers are decorating it, and
 controller does not know which views are presenting its properties.
 
 <figure>
-<img src="../images/controller-guide/objects.png">
+<img src="/images/controller-guide/objects.png">
 </figure>
 
 This also means that as far as a template is concerned, all of its

guides/v1.11.0/models/index.md

@@ -206,7 +206,7 @@ adapter. Your adapter will go and retrieve the record from your
 persistence layer; typically, this will be a JSON representation of the
 record served from an HTTP server.
 
-![Diagram showing process for finding an unloaded record](../images/guides/models/finding-unloaded-record-step1-diagram.png)
+![Diagram showing process for finding an unloaded record](/images/models/finding-unloaded-record-step1-diagram.png)
 
 As illustrated in the diagram above, the adapter cannot always return the
 requested record immediately. In this case, the adapter must make an
@@ -225,12 +225,12 @@ The store then takes that JSON, initializes the record with the
 JSON data, and resolves the promise returned to your application
 with the newly-loaded record.
 
-![Diagram showing process for finding an unloaded record after the payload has returned from the server](../images/guides/models/finding-unloaded-record-step2-diagram.png)
+![Diagram showing process for finding an unloaded record after the payload has returned from the server](/images/models/finding-unloaded-record-step2-diagram.png)
 
 Let's look at what happens if you request a record that the store
 already has in its cache.
 
-![Diagram showing process for finding an unloaded record after the payload has returned from the server](../images/guides/models/finding-loaded-record-diagram.png)
+![Diagram showing process for finding an unloaded record after the payload has returned from the server](/images/models/finding-loaded-record-diagram.png)
 
 In this case, because the store already knew about the record, it
 returns a promise that it resolves with the record immediately. It does