El objeto request es un objeto de valor simple que es pasado entre Zend_Controller_Front y el router, dispatcher, y clases de controlador. Empaqueta los nombres del módulo solicitado, controlador, acción, y los parámetros opcionales, así como el resto del entorno de la solicitud, ya sea HTTP, el CLI, o PHP-GTK. El nombre del módulo es accedido por getModuleName() y setModuleName(). El nombre del controlador es accedido por getControllerName() y setControllerName(). El nombre de la acción que llamar dentro del controlador es accedido por getActionName() y setActionName(). Los parámetros accesibles por la acción son un array asociativo de pares clave/valor que son recuperados por getParams() y configurados con setParams(), o configurados individualmente por getParam() y setParam(). Basado en el tipo de solicitud, puede haber más métodos disponibles. La solicitud por defecto usada, Zend_Controller_Request_Http, por ejemplo, tiene métodos para recuperar la URI de la solicitud, ruta de la información, parámetros $_GET y $_POST, etc. El objeto request es pasado al controlador front, o si no es provisto, es instanciado al principio del proceso dispatcher, antes de que ocurra el enrutamiento. Es pasado a través de todos los objetos en la cadena del dispatcher. Adicionalmente, la solicitud objeto es particularmente útil en pruebas. El desarrolador puede cambiar el entorno de la solicitud, incluyendo módulos, controladores, acciones, parámetros, URI, etc, y pasar la solicitud objeto al controlador front para probar el flujo de la aplicación. Cuando se vincula con el objeto respuesta , es posible elaborar y precisar una unidad de pruebas de aplicaciones MVC. Zend_Controller_Request_Http encapsula el acceso a relevantes valores tal como el nombre de la llave y el valor para el controlador y variables de aación enrutamiento y todos los parámetros adicionales analizados desde el URI. Adiccionalmente permite el acceso a valores contenidos en las superglobales como miembros públicos y administra la actual base URL y la solicitud URI. los valores Superglobales no pueden ser determinados en una solicitud objeto, en vez usar los métodos setParam() y getParam() para determinar o recuperar los parámetros del usuario. Cuando se accede a datos Superglobales a través Zend_Controller_Request_Http como propiedades de miembros públicos, es necesario mantener en mente que el nombre de la propiedad (supergloabl array key) corresponda a una supergloabl en un específico orden de precedencia:1. GET, 2. POST, 3. COOKIE, 4. SERVER, 5. ENV. Las supergloables específicas pueden ser accedidas usando un método público como una alternativa. Por ejemplo, el valor original de $_POST['user'] puede ser accedido llamando a getPost('user') en la solicitud objeto. Esto incluye getQuery() para recuperar elementos $_GET, y getHeader() para recuperar la solicitud de los encabezadores (headers). Sea cauteloso cuando accede a los datos de la solicitud objeto como no es filtrado en ninguna manera. El router y dispatcher valida y filtra datos para usar con sus tareas, pero dejan los datos intactos en la solicitud objeto. Como 1.5.0, se puede recuperar los datos sin procesar a través del método getRawBody(). Este método retorna falso si los datos han sido enviados de esa manera, pero si no retorna el cuerpo entero del post. Esto es primordialmente útil para aceptar el contenido cuando se desarrolla una aplicación MVC simple. Usted puede determinar parámetros de usuario en la solicitud objeto usando setParam() y recuperar los mismos despues usando getParam(). El router hace uso de esta funcionalidad para determinar parámetros correspondientes en la solicitud URI a la solicitud objeto. En orden para hacer el mismo trabajo, getParam() recupera actualmente desde muchas fuentes. En orden de prioridad, estas incluyen: parámetros de usuario determinados a través de setParam(), parámetros GET, y finalmente parámetros POST. Ser conciente de esto cuando se sacan datos a través de este método. Si se desea sacar solo desde parámetros se configura a través de setParam(), use getUserParam(). Además, a partir de 1.5.0, puede bloquear el parámetro que se buscará en las fuentes. setParamSources() le permite especificar un array vacío o un array con uno o más de los valores '_GET' o '_POST', indicando que fuente de parámetro se permite (por defecto, ambos son permitidos); si se desea restringir el acceso a solamente '_GET' especificar setParamSources (array('_GET')). Si está usando Apache 404 handler para pasar If you are using Apache's 404 handler to pass incoming requests to the front controller, or using a PT flag with rewrite rules, $_SERVER['REDIRECT_URL'] contains the URI you need, not $_SERVER['REQUEST_URI']. If you are using such a setup and getting invalid routing, you should use the Zend_Controller_Request_Apache404 class instead of the default Http class for your request object: setRequest($request); ]]> This class extends the Zend_Controller_Request_Http class and simply modifies the autodiscovery of the request URI. It can be used as a drop-in replacement. Zend_Controller_Request_Http allows Zend_Controller_Router_Rewrite to be used in subdirectories. Zend_Controller_Request_Http will attempt to automatically detect your base URL and set it accordingly. For example, if you keep your index.php in a webserver subdirectory named /projects/myapp/index.php, base URL (rewrite base) should be set to /projects/myapp. This string will then be stripped from the beginning of the path before calculating any route matches. This frees one from the necessity of prepending it to any of your routes. A route of 'user/:username' will match URIs like http://localhost/projects/myapp/user/martel and http://example.com/user/martel. Automatic base URL detection is case sensitive, so make sure your URL will match a subdirectory name in a filesystem (even on Windows machines). If it doesn't, an exception will be raised. Should base URL be detected incorrectly you can override it with your own base path with the help of the setBaseUrl() method of either the Zend_Controller_Request_Http class, or the Zend_Controller_Front class. The easiest method is to set it in Zend_Controller_Front, which will proxy it into the request object. Example usage to set a custom base URL: setControllerDirectory('./application/controllers') ->setRouter($router) ->setBaseUrl('/projects/myapp'); // set the base url! $response = $controller->dispatch(); ]]> getMethod() allows you to determine the HTTP request method used to request the current resource. Additionally, a variety of methods exist that allow you to get boolean responses when asking if a specific type of request has been made: isGet() isPost() isPut() isDelete() isHead() isOptions() The primary use case for these is for creating RESTful MVC architectures. Zend_Controller_Request_Http has a rudimentary method for detecting AJAX requests: isXmlHttpRequest(). This method looks for an HTTP request header X-Requested-With with the value 'XMLHttpRequest'; if found, it returns TRUE. Currently, this header is known to be passed by default with the following JS libraries: Prototype/Scriptaculous (and libraries derived from Prototype) Yahoo! UI Library jQuery MochiKit Most AJAX libraries allow you to send custom HTTP request headers; if your library does not send this header, simply add it as a request header to ensure the isXmlHttpRequest() method works for you. The base request class used for all request objects is the abstract class Zend_Controller_Request_Abstract. At its most basic, it defines the following methods: La solicitud objeto es un contenedor para entorno de la solicitud. La cadena del controlador sólo necesita saber cómo establecer y recuperar el controlador, la acción, los parámetros opcionales, y el estado del despachador. Por defecto, la solicitud buscará sus propios parámetros mediante el controlador o las llaves de la acción con el fin de determinar el controlador y la acción. Para ampliar esta clase, o uno de sus derivados, cuando se necesita la clase solicitud que interactue con un entorno específico con el fin de recuperar los datos para su uso en las tareas antes descritas. Los ejemplos incluyen el entorno HTTP , un entorno CLI, o un entorno de PHP-GTK.