Permalink
Browse files

Minor updates

  • Loading branch information...
1 parent 5dec61b commit b93b9aca6680e3b9417a06dd88c7a05606bb8b75 @addyosmani committed Mar 30, 2013
View
BIN backbone-fundamentals.epub
Binary file not shown.
View
8 backbone-fundamentals.md
@@ -200,11 +200,11 @@ An example of a server-side web application framework which tries to apply MVC t
* Views represent your user interface, often taking the form of HTML that will be sent down to the browser. They're used to present application data to anything making requests from your application.
* Controllers offer the glue between models and views. Their responsibility is to process requests from the browser, ask your models for data and then supply this data to views so that they may be presented to the browser.
-Interestingly, although there's a clear separation of concerns that is MVC-like in Rails, it is actually using a different pattern called [Model2](http://en.wikipedia.org/wiki/Model2). Justifications for this include that Rails does not notify views from the model and controllers just pass model data directly to the view.
+Although there's a clear separation of concerns that is MVC-like in Rails, it is actually using a different pattern called [Model2](http://en.wikipedia.org/wiki/Model2). Justifications for this include that Rails does not notify views from the model and controllers just pass model data directly to the view.
-That said, even for the server-side workflow of receiving a request from a URL, baking out an HTML page as a response and separating your business logic from your interface has many benefits, the largest being maintainability. In the same way that keeping your UI cleanly separate from your database records is useful in server-side frameworks, it's wqually as useful to keep your UI cleanly separated from your data models in JavaScript (as we will read more about shortly).
+That said, even for the server-side workflow of receiving a request from a URL, baking out an HTML page as a response and separating your business logic from your interface has many benefits. In the same way that keeping your UI cleanly separate from your database records is useful in server-side frameworks, it's wqually as useful to keep your UI cleanly separated from your data models in JavaScript (as we will read more about shortly).
-Other server-side implementations of MVC (such as the PHP [Zend](http://zend.com) framework) implement the [Front Controller](http://en.wikipedia.org/wiki/Front_Controller_pattern) design pattern. This pattern layers an MVC stack behind a single point of entry. This single point of entry means that all HTTP requests (e.g., `http://www.example.com`, `http://www.example.com/whichever-page/`, etc.) are routed by the server's configuration to the same handler, independent of the URI.
+Other server-side implementations of MVC (such as the PHP [Zend](http://zend.com) framework) also implement the [Front Controller](http://en.wikipedia.org/wiki/Front_Controller_pattern) design pattern. This pattern layers an MVC stack behind a single point of entry. This single point of entry means that all HTTP requests (e.g., `http://www.example.com`, `http://www.example.com/whichever-page/`, etc.) are routed by the server's configuration to the same handler, independent of the URI.
When the Front Controller receives an HTTP request it analyzes it and decides which class (Controller) and method (Action) to invoke. The selected Controller Action takes over and interacts with the appropriate Model to fulfill the request. The Controller receives data back from the Model, loads an appropriate View, injects the Model data into it, and returns the response to the browser.
@@ -228,7 +228,7 @@ Several [studies](http://radar.oreilly.com/2009/07/velocity-making-your-site-fas
In addition to resulting in a great deal of duplicated content being served back to the user, this approach affects both latency and the general responsiveness of the user experience. A trend to improve perceived latency in the past few years has been to move towards building Single Page Applications (SPAs) - apps which after an initial page load are able to handle subsequent navigations and requests for data without the need for a complete reload.
-When a user navigates to a new view, additional content required for the view is requested using an XHR (XMLHttpRequest), typically communicating with a server-side REST API or endpoint. Ajax (Asynchronous JavaScript and XML) makes communication with the server asynchronous so that data is transferred and processed in the background, allowing the user to work on other parts of a page without interaction. This improves usability and responsiveness.
+When a user navigates to a new view, additional content required for the view is requested using an XHR (XMLHttpRequest), typically communicating with a server-side REST API or endpoint. [Ajax](https://en.wikipedia.org/wiki/Ajax_(programming))(Asynchronous JavaScript and XML) makes communication with the server asynchronous so that data is transferred and processed in the background, allowing the user to work on other parts of a page without interaction. This improves usability and responsiveness.
SPAs can also take advantage of browser features like the [History API](http://diveintohtml5.info/history.html) to update the address seen in the location bar when moving from one view to another. These URLs also make it possible to bookmark and share a particular application state, without the need to navigate to completely new pages.
View
11 backbone-fundamentals.rtf
@@ -184,15 +184,15 @@ Ruby On Rails
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Models represent the data in an application and are typically used to manage rules for interacting with a specific database table. You generally have one table corresponding to one model with much of your application\u8217's business logic living within these models.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Views represent your user interface, often taking the form of HTML that will be sent down to the browser. They\u8217're used to present application data to anything making requests from your application.\par}
{\pard \ql \f0 \sa0 \li360 \fi-360 \bullet \tx360\tab Controllers offer the glue between models and views. Their responsibility is to process requests from the browser, ask your models for data and then supply this data to views so that they may be presented to the browser.\sa180\par}
-{\pard \ql \f0 \sa180 \li0 \fi0 Interestingly, although there\u8217's a clear separation of concerns that is MVC-like in Rails, it is actually using a different pattern called {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Model2"}}{\fldrslt{\ul
+{\pard \ql \f0 \sa180 \li0 \fi0 Although there\u8217's a clear separation of concerns that is MVC-like in Rails, it is actually using a different pattern called {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Model2"}}{\fldrslt{\ul
Model2
}}}
. Justifications for this include that Rails does not notify views from the model and controllers just pass model data directly to the view.\par}
-{\pard \ql \f0 \sa180 \li0 \fi0 That said, even for the server-side workflow of receiving a request from a URL, baking out an HTML page as a response and separating your business logic from your interface has many benefits, the largest being maintainability. In the same way that keeping your UI cleanly separate from your database records is useful in server-side frameworks, it\u8217's wqually as useful to keep your UI cleanly separated from your data models in JavaScript (as we will read more about shortly).\par}
+{\pard \ql \f0 \sa180 \li0 \fi0 That said, even for the server-side workflow of receiving a request from a URL, baking out an HTML page as a response and separating your business logic from your interface has many benefits. In the same way that keeping your UI cleanly separate from your database records is useful in server-side frameworks, it\u8217's wqually as useful to keep your UI cleanly separated from your data models in JavaScript (as we will read more about shortly).\par}
{\pard \ql \f0 \sa180 \li0 \fi0 Other server-side implementations of MVC (such as the PHP {\field{\*\fldinst{HYPERLINK "http://zend.com"}}{\fldrslt{\ul
Zend
}}}
- framework) implement the {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Front_Controller_pattern"}}{\fldrslt{\ul
+ framework) also implement the {\field{\*\fldinst{HYPERLINK "http://en.wikipedia.org/wiki/Front_Controller_pattern"}}{\fldrslt{\ul
Front Controller
}}}
design pattern. This pattern layers an MVC stack behind a single point of entry. This single point of entry means that all HTTP requests (e.g., {\f1 http://www.example.com}, {\f1 http://www.example.com/whichever-page/}, etc.) are routed by the server\u8217's configuration to the same handler, independent of the URI.\par}
@@ -210,7 +210,10 @@ studies
}}}
have confirmed that improvements to latency can have a positive impact on the usage and user engagement of sites and apps. This is at odds with the traditional approach to web app development which is very server-centric, requiring a complete page reload to move between one page to the next. Even with heavy caching in place, the browser still has to parse the CSS, JS and HTML and render the interface to the screen.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 In addition to resulting in a great deal of duplicated content being served back to the user, this approach affects both latency and the general responsiveness of the user experience. A trend to improve perceived latency in the past few years has been to move towards building Single Page Applications (SPAs) - apps which after an initial page load are able to handle subsequent navigations and requests for data without the need for a complete reload.\par}
-{\pard \ql \f0 \sa180 \li0 \fi0 When a user navigates to a new view, additional content required for the view is requested using an XHR (XMLHttpRequest), typically communicating with a server-side REST API or endpoint. Ajax (Asynchronous JavaScript and XML) makes communication with the server asynchronous so that data is transferred and processed in the background, allowing the user to work on other parts of a page without interaction. This improves usability and responsiveness.\par}
+{\pard \ql \f0 \sa180 \li0 \fi0 When a user navigates to a new view, additional content required for the view is requested using an XHR (XMLHttpRequest), typically communicating with a server-side REST API or endpoint. {\field{\*\fldinst{HYPERLINK "https://en.wikipedia.org/wiki/Ajax_(programming)"}}{\fldrslt{\ul
+Ajax
+}}}
+(Asynchronous JavaScript and XML) makes communication with the server asynchronous so that data is transferred and processed in the background, allowing the user to work on other parts of a page without interaction. This improves usability and responsiveness.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 SPAs can also take advantage of browser features like the {\field{\*\fldinst{HYPERLINK "http://diveintohtml5.info/history.html"}}{\fldrslt{\ul
History API
}}}
View
8 chapters/02-fundamentals.md
@@ -36,11 +36,11 @@ An example of a server-side web application framework which tries to apply MVC t
* Views represent your user interface, often taking the form of HTML that will be sent down to the browser. They're used to present application data to anything making requests from your application.
* Controllers offer the glue between models and views. Their responsibility is to process requests from the browser, ask your models for data and then supply this data to views so that they may be presented to the browser.
-Interestingly, although there's a clear separation of concerns that is MVC-like in Rails, it is actually using a different pattern called [Model2](http://en.wikipedia.org/wiki/Model2). Justifications for this include that Rails does not notify views from the model and controllers just pass model data directly to the view.
+Although there's a clear separation of concerns that is MVC-like in Rails, it is actually using a different pattern called [Model2](http://en.wikipedia.org/wiki/Model2). Justifications for this include that Rails does not notify views from the model and controllers just pass model data directly to the view.
-That said, even for the server-side workflow of receiving a request from a URL, baking out an HTML page as a response and separating your business logic from your interface has many benefits, the largest being maintainability. In the same way that keeping your UI cleanly separate from your database records is useful in server-side frameworks, it's wqually as useful to keep your UI cleanly separated from your data models in JavaScript (as we will read more about shortly).
+That said, even for the server-side workflow of receiving a request from a URL, baking out an HTML page as a response and separating your business logic from your interface has many benefits. In the same way that keeping your UI cleanly separate from your database records is useful in server-side frameworks, it's wqually as useful to keep your UI cleanly separated from your data models in JavaScript (as we will read more about shortly).
-Other server-side implementations of MVC (such as the PHP [Zend](http://zend.com) framework) implement the [Front Controller](http://en.wikipedia.org/wiki/Front_Controller_pattern) design pattern. This pattern layers an MVC stack behind a single point of entry. This single point of entry means that all HTTP requests (e.g., `http://www.example.com`, `http://www.example.com/whichever-page/`, etc.) are routed by the server's configuration to the same handler, independent of the URI.
+Other server-side implementations of MVC (such as the PHP [Zend](http://zend.com) framework) also implement the [Front Controller](http://en.wikipedia.org/wiki/Front_Controller_pattern) design pattern. This pattern layers an MVC stack behind a single point of entry. This single point of entry means that all HTTP requests (e.g., `http://www.example.com`, `http://www.example.com/whichever-page/`, etc.) are routed by the server's configuration to the same handler, independent of the URI.
When the Front Controller receives an HTTP request it analyzes it and decides which class (Controller) and method (Action) to invoke. The selected Controller Action takes over and interacts with the appropriate Model to fulfill the request. The Controller receives data back from the Model, loads an appropriate View, injects the Model data into it, and returns the response to the browser.
@@ -64,7 +64,7 @@ Several [studies](http://radar.oreilly.com/2009/07/velocity-making-your-site-fas
In addition to resulting in a great deal of duplicated content being served back to the user, this approach affects both latency and the general responsiveness of the user experience. A trend to improve perceived latency in the past few years has been to move towards building Single Page Applications (SPAs) - apps which after an initial page load are able to handle subsequent navigations and requests for data without the need for a complete reload.
-When a user navigates to a new view, additional content required for the view is requested using an XHR (XMLHttpRequest), typically communicating with a server-side REST API or endpoint. Ajax (Asynchronous JavaScript and XML) makes communication with the server asynchronous so that data is transferred and processed in the background, allowing the user to work on other parts of a page without interaction. This improves usability and responsiveness.
+When a user navigates to a new view, additional content required for the view is requested using an XHR (XMLHttpRequest), typically communicating with a server-side REST API or endpoint. [Ajax](https://en.wikipedia.org/wiki/Ajax_(programming))(Asynchronous JavaScript and XML) makes communication with the server asynchronous so that data is transferred and processed in the background, allowing the user to work on other parts of a page without interaction. This improves usability and responsiveness.
SPAs can also take advantage of browser features like the [History API](http://diveintohtml5.info/history.html) to update the address seen in the location bar when moving from one view to another. These URLs also make it possible to bookmark and share a particular application state, without the need to navigate to completely new pages.
View
8 index.html
@@ -517,9 +517,9 @@ <h3 id="mvc-applied-to-the-web"><a href="#TOC">MVC Applied To The Web</a></h3>
<li>Views represent your user interface, often taking the form of HTML that will be sent down to the browser. They’re used to present application data to anything making requests from your application.</li>
<li>Controllers offer the glue between models and views. Their responsibility is to process requests from the browser, ask your models for data and then supply this data to views so that they may be presented to the browser.</li>
</ul>
-<p>Interestingly, although there’s a clear separation of concerns that is MVC-like in Rails, it is actually using a different pattern called <a href="http://en.wikipedia.org/wiki/Model2">Model2</a>. Justifications for this include that Rails does not notify views from the model and controllers just pass model data directly to the view.</p>
-<p>That said, even for the server-side workflow of receiving a request from a URL, baking out an HTML page as a response and separating your business logic from your interface has many benefits, the largest being maintainability. In the same way that keeping your UI cleanly separate from your database records is useful in server-side frameworks, it’s wqually as useful to keep your UI cleanly separated from your data models in JavaScript (as we will read more about shortly).</p>
-<p>Other server-side implementations of MVC (such as the PHP <a href="http://zend.com">Zend</a> framework) implement the <a href="http://en.wikipedia.org/wiki/Front_Controller_pattern">Front Controller</a> design pattern. This pattern layers an MVC stack behind a single point of entry. This single point of entry means that all HTTP requests (e.g., <code>http://www.example.com</code>, <code>http://www.example.com/whichever-page/</code>, etc.) are routed by the server’s configuration to the same handler, independent of the URI.</p>
+<p>Although there’s a clear separation of concerns that is MVC-like in Rails, it is actually using a different pattern called <a href="http://en.wikipedia.org/wiki/Model2">Model2</a>. Justifications for this include that Rails does not notify views from the model and controllers just pass model data directly to the view.</p>
+<p>That said, even for the server-side workflow of receiving a request from a URL, baking out an HTML page as a response and separating your business logic from your interface has many benefits. In the same way that keeping your UI cleanly separate from your database records is useful in server-side frameworks, it’s wqually as useful to keep your UI cleanly separated from your data models in JavaScript (as we will read more about shortly).</p>
+<p>Other server-side implementations of MVC (such as the PHP <a href="http://zend.com">Zend</a> framework) also implement the <a href="http://en.wikipedia.org/wiki/Front_Controller_pattern">Front Controller</a> design pattern. This pattern layers an MVC stack behind a single point of entry. This single point of entry means that all HTTP requests (e.g., <code>http://www.example.com</code>, <code>http://www.example.com/whichever-page/</code>, etc.) are routed by the server’s configuration to the same handler, independent of the URI.</p>
<p>When the Front Controller receives an HTTP request it analyzes it and decides which class (Controller) and method (Action) to invoke. The selected Controller Action takes over and interacts with the appropriate Model to fulfill the request. The Controller receives data back from the Model, loads an appropriate View, injects the Model data into it, and returns the response to the browser.</p>
<p>For example, let’s say we have our blog on <code>www.example.com</code> and we want to edit an article (with <code>id=43</code>) and request <code>http://www.example.com/article/edit/43</code>:</p>
<p>On the server side, the Front Controller would analyze the URL and invoke the Article Controller (corresponding to the <code>/article/</code> part of the URI) and its Edit Action (corresponding to the <code>/edit/</code> part of the URI). Within the Action there would be a call to, let’s say, the Articles Model and its <code>Articles::getEntry(43)</code> method (43 corresponding to the <code>/43</code> at the end of the URI). This would return the blog article data from the database for edit. The Article Controller would then load the (<code>article/edit</code>) View which would include logic for injecting the article’s data into a form suitable for editing its content, title, and other (meta) data. Finally, the resulting HTML response would be returned to the browser.</p>
@@ -533,7 +533,7 @@ <h3 id="mvc-applied-to-the-web"><a href="#TOC">MVC Applied To The Web</a></h3>
<h3 id="client-side-mvc-single-page-apps"><a href="#TOC">Client-Side MVC &amp; Single Page Apps</a></h3>
<p>Several <a href="http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html">studies</a> have confirmed that improvements to latency can have a positive impact on the usage and user engagement of sites and apps. This is at odds with the traditional approach to web app development which is very server-centric, requiring a complete page reload to move between one page to the next. Even with heavy caching in place, the browser still has to parse the CSS, JS and HTML and render the interface to the screen.</p>
<p>In addition to resulting in a great deal of duplicated content being served back to the user, this approach affects both latency and the general responsiveness of the user experience. A trend to improve perceived latency in the past few years has been to move towards building Single Page Applications (SPAs) - apps which after an initial page load are able to handle subsequent navigations and requests for data without the need for a complete reload.</p>
-<p>When a user navigates to a new view, additional content required for the view is requested using an XHR (XMLHttpRequest), typically communicating with a server-side REST API or endpoint. Ajax (Asynchronous JavaScript and XML) makes communication with the server asynchronous so that data is transferred and processed in the background, allowing the user to work on other parts of a page without interaction. This improves usability and responsiveness.</p>
+<p>When a user navigates to a new view, additional content required for the view is requested using an XHR (XMLHttpRequest), typically communicating with a server-side REST API or endpoint. <a href="https://en.wikipedia.org/wiki/Ajax_(programming)">Ajax</a>(Asynchronous JavaScript and XML) makes communication with the server asynchronous so that data is transferred and processed in the background, allowing the user to work on other parts of a page without interaction. This improves usability and responsiveness.</p>
<p>SPAs can also take advantage of browser features like the <a href="http://diveintohtml5.info/history.html">History API</a> to update the address seen in the location bar when moving from one view to another. These URLs also make it possible to bookmark and share a particular application state, without the need to navigate to completely new pages.</p>
<p>The typical SPA consists of smaller pieces of interface representing logical entities, all of which have their own UI, business logic and data. A good example is a basket in a shopping web application which can have items added to it. This basket might be presented to the user in a box in the top right corner of the page (see the picture below):</p>
<figure>

0 comments on commit b93b9ac

Please sign in to comment.