Zend_Controller-Basics.xml 11 KB

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