2
0

Zend_Controller-Basics.xml 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- Reviewed: no -->
  3. <sect1 id="zend.controller.basics">
  4. <title>Conceptos Básicos de Zend_Controller</title>
  5. <para>
  6. El sistema <classname>Zend_Controller</classname> está diseñado para
  7. ser liviano, modular y extensible. Se trata de un diseño minimalista
  8. para permitir flexibilidad y cierta libertad para los usuarios
  9. proporcionando al mismo tiempo una estructura suficiente para que sistemas
  10. construidos alrededor de <classname>Zend_Controller</classname>
  11. compartan algunas convenciones y layouts de código similares.
  12. </para>
  13. <para>
  14. El siguiente diagrama muestra el flujo de trabajo, y la narrativa
  15. que le sigue describe en detalle las interacciones:
  16. </para>
  17. <para>
  18. <inlinegraphic width="483" scale="100" align="center" valign="middle"
  19. fileref="figures/zend.controller.basics.png" format="PNG" />
  20. </para>
  21. <para>
  22. El flujo de procesos de <classname>Zend_Controller</classname> está implementado
  23. por varios componentes. Si bien no es necesario entender los cimientos
  24. de todos estos componentes para utilizar el sistema, tener un
  25. conocimiento práctico del proceso es de mucha utilidad.
  26. </para>
  27. <itemizedlist>
  28. <listitem>
  29. <para>
  30. <classname>Zend_Controller_Front</classname> organiza todo
  31. el flujo de trabajo del sistema <classname>Zend_Controller</classname>.
  32. Es una interpretación del patrón FrontController.
  33. <classname>Zend_Controller_Front</classname> procesa todas
  34. las solicitudes recibidas por el servidor y es responsable
  35. en última instancia de la delegación de las solicitudes a los
  36. ActionControllers
  37. (<classname>Zend_Controller_Action</classname>).
  38. </para>
  39. </listitem>
  40. <listitem>
  41. <para>
  42. <classname>Zend_Controller_Request_Abstract</classname> (a
  43. menudo denominado <code>Request Object</code>) representa
  44. el entorno de la solicitud y ofrece métodos para
  45. establecer y recuperar el controlador, los nombres de las
  46. acciones y cualquier parámetro de solicitud. Además realiza un seguimiento
  47. de si la acción que contiene ha sido enviada o no
  48. por <classname>Zend_Controller_Dispatcher</classname>.
  49. Se pueden usar extensiones del objeto abstracto para
  50. encapsular toda el entorno de la solicitud,
  51. permitiendo a los routers traer información del ámbito
  52. de la solicitud a fin de establecer el controlador
  53. y los nombres de acción.
  54. </para>
  55. <para>
  56. Por defecto, se usa
  57. <classname>Zend_Controller_Request_Http</classname>, el cual
  58. proporciona acceso a todo el ámbito de la petición
  59. HTTP.
  60. </para>
  61. </listitem>
  62. <listitem>
  63. <para>
  64. <classname>Zend_Controller_Router_Interface</classname>
  65. se usa para definir routers. El ruteo es el proceso de
  66. examinar el ámbito de la solicitud para determinar
  67. qué controlador, y qué acción del controlador debe recibir
  68. la solicitud. Este controlador, la acción, y los parámetros
  69. opcionales son luego establecidos en el objeto de la solicitud
  70. para ser procesados por
  71. <classname>Zend_Controller_Dispatcher_Standard</classname>.
  72. El ruteo (routing) ocurre sólo una vez: cuando la solicitud
  73. se recibe inicialmente y antes de enviar el primer
  74. controlador.
  75. </para>
  76. <para>
  77. El router por defecto,
  78. <classname>Zend_Controller_Router_Rewrite</classname>,
  79. toma el punto final de una URI como se especificó en
  80. <classname>Zend_Controller_Request_Http</classname>
  81. y la descompone en un controlador, una acción y parámetros,
  82. basándose en la información de la ruta del url.
  83. Como ejemplo, la URL
  84. <code>http://localhost/foo/bar/key/value</code> se
  85. decodificará para usar el controlador <code>foo</code>,
  86. la acción <code>bar</code> y especificar un parámetro
  87. <code>key</code> con el valor de <code>value</code>.
  88. </para>
  89. <para>
  90. <classname>Zend_Controller_Router_Rewrite</classname>
  91. también puede ser utilizado para igualar las rutas arbitrarios;
  92. para más información, ver <link
  93. linkend="zend.controller.router">documentación
  94. del router</link>.
  95. </para>
  96. </listitem>
  97. <listitem>
  98. <para>
  99. <classname>Zend_Controller_Dispatcher_Interface</classname>
  100. se usa para definir dispatchers. Dispatching (Despachar) es el proceso
  101. de sacar el controlador y la acción del objeto que solicita y
  102. mapearlo a un controlador archivo/clase y al método acción
  103. en la clase del controlador. Si el controlador o acción no
  104. existen, hará un manejo para determinar los controladores
  105. por defecto y las acciones a enviar.
  106. </para>
  107. <para>
  108. El proceso actual de dispatching(despacho) consta de instanciar la
  109. clase del controlador y llamar al método acción en esa
  110. clase. A diferencia del routing, que ocurre sólo una vez,
  111. el dispatching(despacho) ocurre en un bucle. Si el estado del objeto que
  112. que envía la solicita es reseteado en cualquier punto,
  113. el bucle se repetirá, llamando a cualquier acción que esté
  114. actualmente establecida en la solicitud del objeto.
  115. La primera vez el bucle termina con la solicitud del objeto,
  116. el estado de lo enviado se establece a (booleano true),
  117. que terminará el procesamiento.
  118. </para>
  119. <para>
  120. El dispatcher por defecto es
  121. <classname>Zend_Controller_Dispatcher_Standard</classname>.
  122. Se definen como controladores MixedCasedClasses cuando
  123. terminan en la palabra Controller, y los métodos de acción
  124. como camelCasedMethods cuando terminan en la palabra Action:
  125. <code>FooController::barAction()</code>. En este caso,
  126. el controlador será referido como <code>foo</code> y a la
  127. acción como <code>bar</code>.
  128. </para>
  129. <note>
  130. <title>Convenciones para Case Naming (Casos de Nombre)</title>
  131. <para>
  132. Dado que los humanos somos notablemente inconsistentes
  133. en mantener cierta sensibilidad respecto a las
  134. minúsculas y mayúsculas al escribir enlaces,
  135. Zend Framework realmente normaliza la información de la
  136. ruta a minúsculas. Esto, por supuesto, afectará cómo
  137. nombre a su controlador y a sus acciones... o referirse
  138. a ellos en los enlaces.
  139. </para>
  140. <para>
  141. Si desea que su clase controlador o el nombre del
  142. método de la acción tenga múltiples MixedCasedWords o
  143. camelCasedWords, para separar las palabras en la url
  144. necesitará hacerlo con un '-' o '.' (aunque puede
  145. configurar el carácter utilizado).
  146. </para>
  147. <para>
  148. Como ejemplo, si se va a la acción en
  149. <code>FooBarController::bazBatAction()</code>,
  150. se referirá a ella en la URL como
  151. <code>/foo-bar/baz-bat</code>
  152. o <code>/foo.bar/baz.bat</code>.
  153. </para>
  154. </note>
  155. </listitem>
  156. <listitem>
  157. <para>
  158. <classname>Zend_Controller_Action</classname>
  159. es el componente base del controlador de acción.
  160. Cada controlador es una sola clase que extiende la
  161. <classname>clase Zend_Controller_Action </classname>
  162. y debe contener uno o más métodos de acción.
  163. </para>
  164. </listitem>
  165. <listitem>
  166. <para>
  167. <classname>Zend_Controller_Response_Abstract</classname>
  168. define una clase base de respuesta utilizada para recoger y
  169. retornar respuestas de los controladores de acción.
  170. Recoge tanto a las cabeceras como al contenido del cuerpo.
  171. </para>
  172. <para>
  173. La clase de respuesta (response) por defecto es
  174. <classname>Zend_Controller_Response_Http</classname>,
  175. la cual es adecuada para usarla en un entorno HTTP.
  176. </para>
  177. </listitem>
  178. </itemizedlist>
  179. <para>
  180. El flujo de procesos de <classname>Zend_Controller</classname> es relativamente
  181. sencillo. Una solicitud es recibida por
  182. <classname>Zend_Controller_Front</classname>, la que a su vez llama a
  183. <classname>Zend_Controller_Router_Rewrite</classname>
  184. para determinar qué controlador (y la acción en ese controlador)
  185. despachar.
  186. <classname>Zend_Controller_Router_Rewrite</classname>
  187. descompone la URI a fin de establecer el controlador y el nombre de
  188. acción en la solicitud.
  189. <classname>Zend_Controller_Front</classname>
  190. entonces entra al bucle del dispatch. Llama a
  191. <classname>Zend_Controller_Dispatcher_Standard</classname>,
  192. el que pasa la solicitud para enviar al controlador y a la acción
  193. especificada en la solicitud (o el usado por defecto).
  194. Después de que el controlador ha terminado, el control vuelve a
  195. <classname>Zend_Controller_Front</classname>.
  196. Si el controlador ha indicado que debe enviarse otro controlador
  197. mediante el reinicio del estado de la condición de la solicitud,
  198. el bucle continúa y se ejecuta otro envio.
  199. En caso contrario el proceso termina.
  200. </para>
  201. </sect1>
  202. <!--
  203. vim:se ts=4 sw=4 et:
  204. -->