Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Linking up Front Controller pattern

  • Loading branch information...
commit 5dec61b123502746655fa11e95ac9b1d5a2aa25a 1 parent fd52da8
@addyosmani authored
View
BIN  backbone-fundamentals.epub
Binary file not shown
View
2  backbone-fundamentals.md
@@ -204,7 +204,7 @@ Interestingly, although there's a clear separation of concerns that is MVC-like
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).
-Other server-side implementations of MVC (such as the PHP [Zend](http://zend.com) framework) implement the 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., `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) 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.
View
5 backbone-fundamentals.rtf
@@ -192,7 +192,10 @@ Model2
{\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 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}
+ framework) 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}
{\pard \ql \f0 \sa180 \li0 \fi0 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.\par}
{\pard \ql \f0 \sa180 \li0 \fi0 For example, let\u8217's say we have our blog on {\f1 www.example.com} and we want to edit an article (with {\f1 id=43}) and request {\f1 http://www.example.com/article/edit/43}:\par}
{\pard \ql \f0 \sa180 \li0 \fi0 On the server side, the Front Controller would analyze the URL and invoke the Article Controller (corresponding to the {\f1 /article/} part of the URI) and its Edit Action (corresponding to the {\f1 /edit/} part of the URI). Within the Action there would be a call to, let\u8217's say, the Articles Model and its {\f1 Articles::getEntry(43)} method (43 corresponding to the {\f1 /43} 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 ({\f1 article/edit}) View which would include logic for injecting the article\u8217'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.\par}
View
2  chapters/02-fundamentals.md
@@ -40,7 +40,7 @@ Interestingly, although there's a clear separation of concerns that is MVC-like
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).
-Other server-side implementations of MVC (such as the PHP [Zend](http://zend.com) framework) implement the 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., `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) 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.
View
2  index.html
@@ -519,7 +519,7 @@ <h3 id="mvc-applied-to-the-web"><a href="#TOC">MVC Applied To The Web</a></h3>
</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 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., <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>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>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>
Please sign in to comment.
Something went wrong with that request. Please try again.