1 2 Zend Framework Instalacion

Curso: "PHP 5 POO con Zend Framework" 2011

AUTOR: Andrés Guzmán Fontecilla. Email: [email protected] WEB: http://www.bolsadeideas.cl/servicios/cursos-de-capacitacion/ LICENCIA: http://creativecommons.org/licenses/by-nc/2.5

1

“Instalación de Zend Framework”

Módulo 1 / parte 2

© Todos los logos y marcas utilizados en este

documento, están registrados y pertenecen a

sus respectivos dueños.



2

Objetivos

Este capítulo busca iniciarnos en todo el procedimiento de crear un proyecto Zend

incluyendo la propia instalación del framework y todos los detalles que hay que tener en

cuenta.



3

Requerimientos Mínimos

ZF al estar escrito en PHP5, un lenguaje multiplataforma, puede ejecutarse en la

mayoría de los S.O tales como Linux, Mac OS X, Microsoft Windows, Solaris, etc.

Para nosotros (aunque pueden

existir otras alternativas viables) el

"entorno ideal" sería poder contar

con un servidor GNU/Linux con un

servidor web como Apache, el

módulo mod_rewrite habilitado,

PHP5 en su versión 5.1.4 o

superior y asegurarnos que esté instalado PDO para poder realizar operaciones sobre

las bases de datos (Zend requiere que se active esta API).

PDO es una extensión que provee una capa de abstracción de acceso a datos para

PHP 5, con lo cual se consigue hacer uso de las mismas funciones para hacer

consultas y obtener datos entre distintos manejadores de bases de datos (una capa más de

abstracción).

El Mod Rewrite es un módulo para el servidor Apache que nos permite reescribir las

apariencias de las URLs. A través de diferentes reglas y condiciones se pueden

personalizar esas URLs o Permalinks de nuestras páginas de forma que podamos conseguir

enlaces más amigables para los buscadores y para nuestros visitantes. Por ej., en vez de

/index.php?mod=estadisticas&usuario=1 podríamos tener /estadisticas/usuario/1

El "entorno ideal" puede cambiar y/o

sustituir algunos componentes con otras

alternativas (por ej. en el caso de no contar

con mod_rewrite), pero lo "ideal" sería que

nuestro servidor o servicio de hosting contara

con estos servicios y trabajáramos con todas

las herramientas requeridas y con las cuales se

seleccionaron para usar con el framework.

http://es.wikipedia.org/wiki/.php

http://es.wikipedia.org/wiki/Sistema_operativo

http://es.wikipedia.org/wiki/Linux

http://es.wikipedia.org/wiki/Mac_OS_X

http://es.wikipedia.org/wiki/Microsoft_Windows

http://es.wikipedia.org/wiki/Solaris_%28sistema_operativo%29

http://es.wikipedia.org/wiki/Servidor_web

http://www.apache.org/

http://blog.unijimpe.net/como-utilizar-mod_rewrite/

http://www.php.net/downloads.php

http://ar2.php.net/pdo

http://es.wikipedia.org/wiki/API



4

Si trabajamos en GNU/Linux, casi cualquier distribución moderna

incluye PHP5, MySQL5 y Apache2 (este combo es comúnmente

llamado LAMP por las siglas de sus componentes).

.

Sin embargo, si estás más acostumbrado a la plataforma

Windows existe también un combo que se llama WAMP. Una de

las herramientas que reúne

todos los elementos anteriores necesarios de manera

muy sencilla se llama Xampp. Para instalarlo solo

tienen que seguir los pasos indicados según el paquete correspondiente a nuestro

sistema operativo.

Si nuestro GNU/Linux no tuviera PHP5, existen un paquete en Xampp que soluciona

este problema.

http://es.wikipedia.org/wiki/LAMP

http://es.wikipedia.org/wiki/WAMP

http://www.apachefriends.org/en/xampp.html

http://es.wikipedia.org/wiki/Sistema_operativo

http://www.apachefriends.org/en/xampp-linux.html



5

Primera configuración

Una vez instalado nuestro entorno de trabajo

con todos sus elementos, puede que

necesitemos hacer un par de ajustes antes de

usar ZF.

Si nuestro entorno es Windows

Al instalar Xampp no necesitamos configurar nada más ya que viene listo para usar ZF,

así que las configuraciones de más abajo no deberían requerirse, pero por las dudas

podemos revisarlas y ya conocer cómo y donde es que se configuran.

Configuración Base

Editamos el archivo httpd.conf de configuración de Apache ubicado generalmente en

C:\xampp\apache\conf

Código:

#LoadModule rewrite_module modules/mod_rewrite.so

Le quitamos el comentario # dejándolo así

Código:

LoadModule rewrite_module modules/mod_rewrite.so

Una forma de verificar

nuestro entorno es

ejecutar un index.php con

un simple "phpinfo();"

http://www.apachefriends.org/en/xampp.html



6

Luego editamos el archivo php.ini en c:\xampp\php

Código:

;extension=php_pdo.dll

;extension=php_pdo_mysql.dll

Quitamos el punto y coma dejándolo así

Código:

extension=php_pdo.dll

extension=php_pdo_mysql.dll

Luego debemos reiniciar Apache para que apliquen los cambios en los archivos de

configuración.



7

Probando nuestro servidor web

Vamos a asegurarnos que todo está corriendo hasta ahora como

corresponde. Entonces creamos un archivo index.php y añadir el

siguiente contenido:

<?php echo "Hola, Mundo sin Zend Framework!";

Ahora abrimos nuestro navegador favorito (solo Firefox ;-)) y escribimos la dirección

URL http://localhost/ para ver una simple página con nuestro texto de burla al mundo

de programadores que aún no usa Zend Framework.

¡Ey! Se olvidaron de colocar el ?>! (jejeje, tontos, los atrapamos!)

¡No nos olvidamos de la etiqueta de cierre ?> de PHP! Se debe omitir intencionalmente cuando

se trata de archivos PHP que contengan sólo código PHP como por ejemplo las clases. Estamos

omitiendo intencionalmente para evitar la salida involuntaria caracteres o espacios en blanco

que se puedan producirse. De hecho, esta es una de las "mejores prácticas" recomendadas por el

estándar de Zend Framework.

http://localhost/

http://framework.zend.com/manual/en/coding-standard.html



8

Antes de empezar, cómo funciona rápidamente un MVC

El patrón MVC podría considerarse una "especialización" de una típica

"arquitectura de 3 capas" pero con una lógica de funcionamiento más ajustada a

entornos web, donde se intenta -por lo general– concentrar todas las peticiones del

exterior a través de un solo punto de entrada (clásicos sistemas "modulares")

En este nuevo diseño tendremos que todas las peticiones del usuario se dirigirán

hacia un Controller ("Controlador") que se encargará de decidir si solicita

información de la "lógica de negocio" al Model ("Modelo") y/o pasa a la View ("Vista")

para que se encargue de generar la interfaz

de usuario.

Nota: se recomienda la lectura de la

explicación escrita en Wikipedia

Aquí se puede visualizar un diagrama que

muestra la relación con sus componentes

(más adelante entraremos en detalles, por

ahora solo veremos lo básico y esencial para

entender el funcionamiento del patrón).

Aclaración importante: los patrones de diseño son "la mejor solución encontrada para

resolver un problema genérico y recurrente", pero, la solución es una "guía" y no un

"manual" para resolver un problema específico, ya que cada contexto tendrá sus

particularidades. ZF "implementa su versión" del patrón de diseño, por lo tanto no

significará nunca que lo que veamos de ZF es sinónimo puro de MVC, en realidad

veremos que existen muchos frameworks que implementan su propia versión del

patrón, y todas estarán correctas.

Un patrón de diseño es solo eso, una guía.

http://es.wikipedia.org/wiki/Modelo_Vista_Controlador

http://es.wikipedia.org/wiki/Modelo_Vista_Controlador



9

Como obtener y buscar información Oficial de Zend Framework

Unos de los principios que seguiremos en el del taller es el de leer y buscar información

en la documentación oficial de Zend Framework, cosa que la mayoría es lo que menos

hace, o lo deja como última instancia, cuando debiera ser todo lo contrario.

Este principio es conocido como RTFM es un acrónimo que en inglés significa "Read

The Fucking Manual", (Lee el maldito manual" en español).

La documentación se organiza en dos grandes puntos: el APIs y la Guía de Referencia:

1. APIs: Si estamos buscando información sobre un método particular, un atributo

de alguna clase o bien no recordamos el nombre de una constante. Aquí

podemos obtener toda la información y documentación de las clases y

componentes de Zend Framework a unos pocos clic de distancia.

2. Guía de Referencia o Manual: Con más de 1000 páginas y sobre 500 ejemplos,

tiene un sistema de búsqueda dentro del manual, contiene en detalle todos los

Componentes de Zend Framework con una notable calidad en sus explicaciones

y códigos de ejemplo.

3. Además de contar con la documentación de las APIs y de la Guía

de Referencia de Zend Framework en el sitio de ZF con formato

HTML, tenemos disponible como descarga la versión de pdf de la guía de

referencia y la guía de estudio para la certificación.

http://es.wikipedia.org/wiki/RTFM

http://framework.zend.com/apidoc/core/

http://framework.zend.com/manual/en/

http://framework.zend.com/apidoc/core/

http://framework.zend.com/manual/en/

http://www.zend.com/community/downloads




10

Estructura de una aplicación bajo Zend Framework

Primero necesitaremos crear un directorio que representará nuestra aplicación. Para

este ejemplo usaremos el nombre “proyecto-zf”, donde posteriormente

necesitaremos crear la estructura estándar (definida por Zend) para alojar todos los

elementos que vayamos necesitando agregar de acuerdo a los componentes de MVC

que requiere nuestra aplicación.

La estructura de directorio debería de tener la siguiente forma:

proyecto-zf/

application/

controllers/

models/

views/

scripts/

helpers/

filters/

library/

public/

Podemos ver una estructura que probablemente se repetirá en la mayoría de los

framework: los directorios controllers, models y

views.

Cada vez que necesitemos crear una funcionalidad

en nuestro sistema deberemos crear cada uno de

los archivos que representarán a los componentes

del MVC para poder responder a ese

requerimiento. Por lo general crearemos en cada

directorio un controller, un modelo y una vista

(aunque esto puede variar, en esencia es la

situación más típica).

Aquí podemos empezar a entender las

ventajas de un framework a la hora de

organizar la estructura de nuestro

sistema: nunca más discutiremos donde

deberíamos ubicar el archivo de

configuración o donde deberían ir los

componentes de nuestro sistema. Ya

está resuelto y nosotros debemos seguir

la forma de trabajo definida.



11



12

Por ejemplo, si queremos crear una funcionalidad que muestre los datos de un

usuario podríamos crear un controller "Usuario" que pedirá al modelo "Usuario" los

datos de un ID determinado y que posteriormente requerirá que una vista "ver" genere

dinámicamente el código html para representar todos esos datos.

La url se vería de esta forma:

http://proyecto-zf/usuario/ver/id/1

Esta url la podemos descomponer de la siguiente manera:

1. proyecto-zf : nombre de nuestro proyecto, que será sustituido oportunamente

por la url oficial de nuestro sitio, como bolsadeideas.cl

2. usuario : nuestro controller visto desde el exterior

3. ver : sería la "acción" ("action") que ejecutará nuestro controller (cada controller

podrá tener una o más acciones).

4. id : nuestro parámetro de entrada de datos a través de get

5. 1 : el valor pasado por parámetros.

Aquí se aplica un principio llamado "Convención sobre Configuración " (que se

popularizó con el surgimiento de Ruby On Rails) donde en vez de contar con un

extenso y complejo archivo de configuración para definir cómo traducir la url y generar

que todos los componentes entiendan qué y cómo deben reaccionar, se pasa a una

convención y se elimina el problema de configuración (y aquí es donde entra en juego

nuestro bootstrap):


http://es.wikipedia.org/wiki/Ruby_On_Rails



13

el primer bloque que va de la primer barra ("/") posterior al nombre del

proyecto hasta la siguiente barra se corresponderá con el nombre del

controller. Por lo tanto deberá existir un archivo físico UsuarioController.php

en el directorio "controllers" (si no existe, el sistema dará error por no

encontrarlo).

el segundo bloque hasta la siguiente barra será la "acción" y se traducirá

como un método del controller con la siguiente nomenclatura "verAction".

Y todo lo que siga a continuación será siempre los parámetros con la siguiente

estructura: "parámetro/valor/parámetro/valor".

Nuevamente, encontramos la misma ventaja que al principio, tenemos resuelta la

forma de organizar nuestro sistema y donde colocar cada componente y

funcionalidad, que no es poco si consideramos el tiempo que se puede perder en tratar

de definir todas estas reglas y estructuras si las discutimos de cero con un equipo de

personas donde cada uno tiene su propia opinión de cómo hacerlo.



14

Diseño "No Modular" versus "Modular"

ZF permite dos tipos de estrategias a la hora de organizar nuestro sistema, la forma

"no modular" (como vimos recién) y la forma "modular", que lo único que haría es

agregar un nivel más en nuestra url y una nueva estructura de directorios que se

repetirá por cada módulo, generando una nueva estructura MVC dentro de cada uno.

El ejemplo anterior


Cambiaría por

http://proyecto-zf/admin/usuario/ver/id/1

Y la estructura de directorios mantendría la convención que el primer segmento

representará siempre al módulo al cual debemos dirigirnos.

¿De qué nos sirve?

Nos permite agregar un nivel más de organización en nuestros sistemas, crear módulos

que podrían ser usados entre aplicaciones.

¿Qué recomiendan?

Aprender a usar el “sistema modular”, la mayor dificultad es aprender a organizarse y

definir claramente los módulos que tendrá nuestro sistema. El error más común es

contar con módulos y crear controllers con el mismo nombre (porque no se nos ocurrió

un nombre para cada uno): /usuario/usuario/ver/id/1


http://proyecto-zf/admin/usuario/ver/id/1



15

La estructura se vería de la siguiente forma:

En la misma estructura que el primer

ejemplo "no modular" donde antes teníamos

un subdirectorio que representaba el lugar

donde guardar todos nuestros controllers,

ahora tenemos un nivel mayor de

abstracción y de organización: el módulo

Ilustración 1 - Ejemplo del proyecto Zend Framework

En vez de tener el manejo de usuarios y de

administradores todos juntos en un mismo

directorio de controllers, bien podríamos

tener un "módulo" organizado para

resolver cada tema en particular, y que

posteriormente hasta podría reusarse

entre proyectos.

Aquí podemos visualizar el contenido de

ambos módulos: admin y usuarios, donde

cada uno mantiene la misma organización

MVC pero con su propio contenido de

acuerdo a la responsabilidad del módulo.



16

Podemos utilizar la estructura de directorio del proyecto que mejor se adapte a

nuestras necesidades. Esto es lo que hace a Zend Framework ser flexible, y la

estructura del proyecto de ZF no es una excepción. No hay nada especial sobre la estructura del

proyecto anterior, con excepción de algunos de los componentes MVC que estaremos utilizando

y explicaremos a continuación.

En esta primer etapa usaremos una versión "no modular" del sistema.



17

El directorio "public"

El directorio public deberá tener todos los archivos que pueden ser directamente

accesibles desde nuestro servidor (archivos públicos, que no nos debería afectar en

nada si son bajados desde el exterior de forma anónima), tales como el "bootstrap"

(index.php), imágenes, css, js etc... y deberá incluir su respectivo archivo .htaccess

con las reglas de acceso. En esencia se busca que cualquier acceso a nuestra

estructura sea redirigida a nuestro index.php para tener el control por un único punto de

acceso, a menos que digamos lo contrario, como sucede con las imágenes, css y js,

que deben poder accederse de forma pública o no funcionarían.

Vamos a asumir que estamos corriendo sobre nuestra máquina local y que nuestro

directorio public es accesible mediante la url: http://localhost/proyecto-zf

TIPS

Si tenemos la ruta a nuestro servidor web en

c:\xampp\htdocs podemos decirle a nuestro IDE que

cree en este directorio todos los proyectos, lo que nos

permitirá de forma simple poder trabajar en varios

sistemas a la vez accediendo a

http://localhost/nombreproyecto

http://localhost/quickstart



18

Recordar: “configuración versus convención”, si respetamos las reglas

de nombres el framework logra encontrar los componentes que tiene

que ejecutar.

Instalando Zend Framework

Ahora debemos bajar el código fuente del framework

desde el sitio oficial en download latest e instalarlo

dentro de nuestro directorio "library" con el nombre

"Zend". Es decir copiar del library del framework que

descargamos y descomprimimos hacia el library de

nuestro proyecto.

Además de la descarga del las librerías y

componentes de Zend Framework, podemos

descargar la guía de Referencia para el desarrollador

y la guía de estudio para la certificación en formato

pdf.

Creando nuestro archivo .htaccess

ZF está diseñado implementando el patrón Front Controller: éste patrón se encarga

de recibir y controlar todas las peticiones que vienen desde una URL (exterior), y según

estos parámetros de petición direcciona hacia un controlador especifico (de acuerdo a

la información que definimos en la url), posteriormente llama a la acción deseada de

nuestro controlador.

Esto significa que se debe reescribir todas las peticiones a un único script PHP

que inicializará el FrontController, de ahí la razón de por qué si queremos acceder a

un directorio particular el sistema (a través de las reglas de .htaccess) redireccionará

Descargamos Zend

Framework "Última

versión tar.gz".

Luego lo descomprimimos,

y copiamos la carpeta

Zend (ubicada en

\library\Zend) en el

directorio library de

nuestro proyecto

(c:/xampp/htdocs/zf-

proyecto/library).

http://framework.zend.com/download/latest



http://www.programacion.net/java/tutorial/patrones/4/#pagina4



19

todas las peticiones a nuestro "bootstrap" (index.php) para luego a través del

FrontController decidir a qué controller derivar el control del sistema.

Para el servidor web Apache se debe crear el archivo proyecto-zf /public/.htaccess

con el siguiente contenido:

Código:

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} -s [OR]

RewriteCond %{REQUEST_FILENAME} -l [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^.*$ - [NC,L]

RewriteRule ^.*$ index.php [NC,L]

Esta regla de sobreescritura se entregará a todas las peticiones de URLs que no

terminen en .js, .ico, .gif, .jpg, .png, or .css a través de index.php. El archivo

index.php es la puerta de entrada a nuestra aplicación, equivaldría al método "main" de

Java o C, por eso se lo conoce comúnmente con el nombre bootstrap, que quiere

decir el “arranque”, o proceso de inicio de la aplicación.

Casi sin darte cuenta, eso es todo! Zend Framework está instalado y listo para usar.

Repasemos

1. Creamos nuestro proyecto

2. Creamos la estructura de directorios

3. Creamos nuestro bootstraps con su .htaccess

4. Bajamos Zend en el directorio library

¡Estamos listos!



20



21

Mi primer Bootstrap

Lo primero que tenemos que definir es cuál es nuestro bootstrap por defecto, para ello

seguiremos el manual de Zend y crearemos nuestro index.php

Antes de empezar necesitamos crear un archivo “.htaccess” y lo guardamos dentro de

la carpeta “public” del proyecto. Debe de contener el siguiente código:

RewriteEngine On RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ - [NC,L] RewriteRule ^.*$ index.php [NC,L]

A continuación creamos nuestro “index.php” (bootstrap) y lo guardaremos dentro de la

carpeta “public” junto a nuestro .htaccess. Deberá contener el siguiente código:

<?php

error_reporting(E_ALL | E_STRICT);

$rootPath = dirname(dirname(__FILE__));

set_include_path(get_include_path() . PATH_SEPARATOR . $rootPath . '/library' .

PATH_SEPARATOR);

require_once 'Zend/Controller/Front.php';

$frontController = Zend_Controller_Front::getInstance();

$frontController->setControllerDirectory('../application/controllers')

->throwExceptions(true)

->dispatch();

Listo, esto es lo mínimo para funcionar:

1. Agregamos el máximo de detalle para los errores (ya que estamos

desarrollando)

2. definimos cual es la ruta por defecto donde está posicionado el sistema

3. definimos la ruta por defecto para encontrar la librería del framework

4. requerimos el Front Controller

http://framework.zend.com/docs/quickstart/create-a-bootstrap-file



22

5. y definimos cual es la ruta donde se deben buscar los controllers (por defecto

buscará un archivo con el nombre IndexController.php)

Nuestro “Controlador por Defecto”

Debemos crear el archivo “IndexController.php” guardándolo dentro del directorio

“application /controllers” del proyecto. Debe de contener lo siguiente:

<?php

require_once "Zend/Controller/Action.php";

class IndexController extends Zend_Controller_Action

{

public function indexAction()

{

$this->view->titulo = "Bienvenido a Zend Framework";

}

}

Lo que hicimos aquí es definir el controller por defecto, mantuvimos la

"convención" de crear un IndexController y extendemos de la clase Zend_Controller

_Action toda la estructura y funcionalidad base que debe contar un Controller.



23

Importante: Convención de Nombres

Aquí nos enfrentamos por primera vez a una convención de nombres

para una clase que es completamente ajena y distinta a los

estándares preestablecidos. Lo habitual sería que una clase se

llamara ZendControllerAction (como en Java), pero Zend decidió que

en el nombre de la clase se define la ruta para llegar a ella (conocido

caso del problema de manejo de paquetes / espacios de nombres de

PHP).

Por consiguiente, si tenemos una clase que dice Zend_Controller

_Action la debemos buscarla físicamente dentro de

library/Zend/Controller/Action.php

Y su nombre interno será

abstract class Zend_Controller_Action implements

Zend_Controller_Action_Interface

Recomendamos como ejercicio empezar a conocer el código de

ZF: busquen dentro del directorio library y editen el código fuente de

Action.php e investiguen un rato cómo está escrito, cómo funciona, el

uso de PHPDoc, etc.

http://phpsenior.blogspot.com/2006/04/php5-diseo-en-3-capas-y-problemas-con.html

http://phpsenior.blogspot.com/2006/04/php5-diseo-en-3-capas-y-problemas-con.html



24

Continuando con el ejemplo, tenemos un método:

public function indexAction()

{

$this->view->titulo = "Bienvenido a Zend Framework";

$this->render();

}

…que contiene una sentencia que crea un atributo "titulo", algo que posteriormente

dentro de la vista lo veremos cómo $this->titulo, como si fuera un atributo público de

la vista que fue cargado desde el controller.

La sentencia render() se usa para especificar que el control de la ejecución del

controller se dirija a la vista.

TIPS

Aunque podemos eliminar la línea “render” de

nuestro controller, cuando termine la ejecución

del método este irá automáticamente a su

vista. De todas formas se sugiere siempre hacer

uso del “render”, ya que ZF se puede configurar

que la aplicación no haga esta resolución

automática y todo nuestro sistema dejaría de

funcionar.



25

¡¿Atributos Públicos?!

Aquí es donde nos empezamos a dar cuenta que el estándar de

POO “prohibido los atributos públicos” no se cumple al pié de

la letra, y que en este nuevo contexto de MVC y de solución Zend

estaría aceptada esta práctica.

Podríamos razonar que en sí no estamos diseñando una clase

“Vista” de cero, estamos trabajando con un componente que

existe previamente y que estamos accediendo a sus datos

públicos de forma “ágil”

( bueno, ni nosotros nos creímos esta explicación ;-), pero la

razón real debe haber sido ofrecernos una forma “ágil” de pasar

los datos entre el Controller y la Vista. Nosotros no podemos

definir métodos get/set porque la instancia ya se encuentra

creada y los atributos los estamos definiendo “dinámicamente” )



26

Creando nuestra vista index.phtml

Ahora solo nos queda crear el archivo de vista con extensión .phtml (estándar

definido por Zend). Creamos un archivo de nombre “index.phtml” y lo guardamos

dentro de la carpeta “application/views/scripts/index/”.

Siguiendo las "convenciones", siempre necesitamos crear para la vista un

directorio que se llame igual que el controller. En este caso crearemos una carpeta

llamada "index", igual que el controller IndexController.php.

Dentro de index.phtml escribimos lo siguiente:

<h3><?php echo $this->titulo ?></h3>

<p>Hola Mundo con Zend Framework! :-)</p>

Ahora, si hicimos todo correctamente, lo probamos escribiendo la siguiente dirección en

el navegador:

http://localhost/proyecto-zf/public/

¡Felicitaciones!, ¡hemos terminado nuestro primer

proyecto con Zend Framework “Hola Mundo”!.

¡Ey! ¿la primer línea no

tiene un ";" al final?

Bueno, en este caso

tampoco es necesario ya

que le estamos diciendo a

PHP con el ?> que no

sigue nada más, por lo

tanto el ";" se puede

evitar

http://localhost/proyecto-zf/public/



27

En resumen

En este ejemplo logramos recibir una petición del exterior a través de la url /proyecto-

zf/public/, que gracias al bootstrap redirigió el control al controller por defecto

IndexController, y este le pasó los datos necesarios a la vista, y esta, se encargó de

visualizar el valor recibido como si fuera un atributo propio (creado dinámicamente).

Tarea: Intenta seguir todos estos pasos y cumplir con este ejemplo, si tienes dudas o

problemas, envía una consulta al foro.

Posteriormente, antes de terminar la

semana, recibirás una “tarea desafío”

relacionada con los temas vistos en este

módulo!

Fin.

Envía tus consultas a los foros!

Aquí es cuando debes sacarte todas las dudas

haciendo consultas en los foros

correspondientes

1 2 Zend Framework Instalacion

Documents

Transcript of 1 2 Zend Framework Instalacion