Zend_Controller-Basics.xml 9.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- Reviewed: no -->
  3. <sect1 id="zend.controller.basics">
  4. <title>Zend_Controller Basics</title>
  5. <para>
  6. The <classname>Zend_Controller</classname> system is designed to be
  7. lightweight, modular, and extensible. It is a minimalist design to
  8. permit flexibility and some freedom to users while providing enough
  9. structure so that systems built around <classname>Zend_Controller</classname>
  10. share some common conventions and similar code layout.
  11. </para>
  12. <para>
  13. The following diagram depicts the workflow, and the narrative following
  14. describes in detail the interactions:
  15. </para>
  16. <para>
  17. <inlinegraphic width="483" scale="100" align="center" valign="middle"
  18. fileref="figures/zend.controller.basics.png" format="PNG" />
  19. </para>
  20. <para>
  21. The <classname>Zend_Controller</classname> workflow is implemented by several
  22. components. While it is not necessary to completely understand the
  23. underpinnings of all of these components to use the system, having a
  24. working knowledge of the process is helpful.
  25. </para>
  26. <itemizedlist>
  27. <listitem>
  28. <para>
  29. <classname>Zend_Controller_Front</classname> orchestrates the entire
  30. workflow of the <classname>Zend_Controller</classname> system. It is
  31. an interpretation of the FrontController pattern.
  32. <classname>Zend_Controller_Front</classname> processes all requests
  33. received by the server and is ultimately responsible for
  34. delegating requests to ActionControllers
  35. (<classname>Zend_Controller_Action</classname>).
  36. </para>
  37. </listitem>
  38. <listitem>
  39. <para>
  40. <classname>Zend_Controller_Request_Abstract</classname> (often
  41. referred to as the <emphasis>Request Object</emphasis>) represents
  42. the request environment and provides methods for setting and
  43. retrieving the controller and action names and any request
  44. parameters. Additionally it keeps track of whether or not
  45. the action it contains has been dispatched by
  46. <classname>Zend_Controller_Dispatcher</classname>. Extensions to the
  47. abstract request object can be used to encapsulate the
  48. entire request environment, allowing routers to pull
  49. information from the request environment in order to set the
  50. controller and action names.
  51. </para>
  52. <para>
  53. By default, <classname>Zend_Controller_Request_Http</classname> is
  54. used, which provides access to the entire <acronym>HTTP</acronym> request
  55. environment.
  56. </para>
  57. </listitem>
  58. <listitem>
  59. <para>
  60. <classname>Zend_Controller_Router_Interface</classname> is used to
  61. define routers. Routing is the process of examining the
  62. request environment to determine which controller, and
  63. action of that controller, should receive the request. This
  64. controller, action, and optional parameters are then set in
  65. the request object to be processed by
  66. <classname>Zend_Controller_Dispatcher_Standard</classname>. Routing
  67. occurs only once: when the request is initially received and
  68. before the first controller is dispatched.
  69. </para>
  70. <para>
  71. The default router,
  72. <classname>Zend_Controller_Router_Rewrite</classname>, takes a
  73. <acronym>URI</acronym> endpoint as specified in
  74. <classname>Zend_Controller_Request_Http</classname> and decomposes it
  75. into a controller, action, and parameters based on the path information
  76. in the <acronym>URL</acronym>. As an example, the <acronym>URL</acronym>
  77. <filename>http://localhost/foo/bar/key/value</filename> would be
  78. decoded to use the <emphasis>foo</emphasis> controller,
  79. <emphasis>bar</emphasis> action, and specify a parameter
  80. <emphasis>key</emphasis> with a value of <emphasis>value</emphasis>.
  81. </para>
  82. <para>
  83. <classname>Zend_Controller_Router_Rewrite</classname> can also be used
  84. to match arbitrary paths; see <link
  85. linkend="zend.controller.router">the router documentation</link>
  86. for more information.
  87. </para>
  88. </listitem>
  89. <listitem>
  90. <para>
  91. <classname>Zend_Controller_Dispatcher_Interface</classname> is used to
  92. define dispatchers. Dispatching is the process of pulling
  93. the controller and action from the request object and
  94. mapping them to a controller file (or class) and action method in
  95. the controller class. If the controller or action do not
  96. exist, it handles determining default controllers and
  97. actions to dispatch.
  98. </para>
  99. <para>
  100. The actual dispatching process consists of instantiating the
  101. controller class and calling the action method in that
  102. class. Unlike routing, which occurs only once, dispatching
  103. occurs in a loop. If the request object's dispatched status
  104. is reset at any point, the loop will be repeated, calling
  105. whatever action is currently set in the request object. The
  106. first time the loop finishes with the request object's
  107. dispatched status set (<type>Boolean</type> <constant>TRUE</constant>),
  108. it will finish processing.
  109. </para>
  110. <para>
  111. The default dispatcher is
  112. <classname>Zend_Controller_Dispatcher_Standard</classname>. It defines
  113. controllers as MixedCasedClasses ending in the word
  114. Controller, and action methods as camelCasedMethods ending
  115. in the word Action:
  116. <methodname>FooController::barAction()</methodname>. In this case, the
  117. controller would be referred to as <emphasis>foo</emphasis> and
  118. the action as <emphasis>bar</emphasis>.
  119. </para>
  120. <note>
  121. <title>Case Naming Conventions</title>
  122. <para>
  123. Since humans are notoriously inconsistent at
  124. maintaining case sensitivity when typing links, Zend
  125. Framework actually normalizes path information to
  126. lowercase. This, of course, will affect how you name
  127. your controller and actions... or refer to them in
  128. links.
  129. </para>
  130. <para>
  131. If you wish to have your controller class or action
  132. method name have multiple MixedCasedWords or
  133. camelCasedWords, you will need to separate those words
  134. on the url with either a '-' or '.' (though you can
  135. configure the character used).
  136. </para>
  137. <para>
  138. As an example, if you were going to the action in
  139. <methodname>FooBarController::bazBatAction()</methodname>, you'd
  140. refer to it on the url as <filename>/foo-bar/baz-bat</filename>
  141. or <filename>/foo.bar/baz.bat</filename>.
  142. </para>
  143. </note>
  144. </listitem>
  145. <listitem>
  146. <para>
  147. <classname>Zend_Controller_Action</classname> is the base action
  148. controller component. Each controller is a single class
  149. that extends the <classname>Zend_Controller_Action</classname> class
  150. and should contain one or more action methods.
  151. </para>
  152. </listitem>
  153. <listitem>
  154. <para>
  155. <classname>Zend_Controller_Response_Abstract</classname> defines a
  156. base response class used to collect and return responses
  157. from the action controllers. It collects both headers and
  158. body content.
  159. </para>
  160. <para>
  161. The default response class is
  162. <classname>Zend_Controller_Response_Http</classname>, which is
  163. suitable for use in an <acronym>HTTP</acronym> environment.
  164. </para>
  165. </listitem>
  166. </itemizedlist>
  167. <para>
  168. The workflow of <classname>Zend_Controller</classname> is relatively simple. A
  169. request is received by <classname>Zend_Controller_Front</classname>, which in turn
  170. calls <classname>Zend_Controller_Router_Rewrite</classname> to determine which
  171. controller (and action in that controller) to dispatch.
  172. <classname>Zend_Controller_Router_Rewrite</classname> decomposes the <acronym>URI</acronym>
  173. in order to set the controller and action names in the request.
  174. <classname>Zend_Controller_Front</classname> then enters a dispatch loop. It
  175. calls <classname>Zend_Controller_Dispatcher_Standard</classname>, passing it the
  176. request, to dispatch to the controller and action specified in the
  177. request (or use defaults). After the controller has finished, control
  178. returns to <classname>Zend_Controller_Front</classname>. If the controller has
  179. indicated that another controller should be dispatched by resetting the
  180. dispatched status of the request, the loop continues and another
  181. dispatch is performed. Otherwise, the process ends.
  182. </para>
  183. </sect1>
  184. <!--
  185. vim:se ts=4 sw=4 et:
  186. -->