Gii la herramienta de Yii Framework que agiliza el desarrollo de aplicaciones

En el post anterior, mostramos cómo realizar el primer proyecto con Yii Framework, un framework orientado a objetos para el desarrollo de aplicaciones web con php, que permite la máxima reutilización en la programación web. Ahora damos un paso más, para explicar Gii, una herramienta proporcionada por este framework. Gii es un potente generador de código que, mediante un asistente nos guiará para que podamos crear nuestras clases del modelo, la vista y el controlador sin picar ninguna línea de código.

Entorno de desarrollo

  • OS X Yosemite (10.10.3) – SSOO
  • MAMP (3.2.1) (PHP 5,6,7, MySQL 5.0.11-dev y Apache 2.2.29) – Lenguaje, Servidor y gestor de bases de datos).
  • Sublime Text (3) – Editor de texto
  • Yii Framework (2.0.4) – Framework de desarrollo PHP
  • Composer (1.0-dev) – Gestor de dependencias para PHP

Primero hay que seguir los pasos del Post anterior, Yii Framework: mi primer proyecto y crear un proyecto basado en la plantilla básica al que llamaremos “basic”. Este proyecto implementa un sistema de login “ficticio” para los usuarios y por lo tanto, le añadí un mecanismo de autenticación que atacase a una BBDD, así como un formulario de alta de usuarios que permitiese acercarnos más a una aplicación web real.  Para ello reutilicé el código generado por otro proyecto, limpio y desde cero, creado a partir de la plantilla avanzada.

La estructura de carpetas que obtuvimos al final quedó de la siguiente forma:

gii1

Por lo tanto tenemos una carpeta que identifica las 3 partes del patrón MVC en el que se basan las aplicaciones desarrolladas con Yii: models, views, controllers.

Dentro de models se encuentra la clase User (dada por el fichero User.php), sobre la que trabajaremos en este post.

Primeros pasos con Gii

En el navegador introducir la siguiente URL (atentos al puerto que hayáis definido vosotros, el mío es el que trae establece por defecto mamp – 8888): http://localhost:8888/basic/web/index.php?r=gii debe aparecernos la siguiente web:

gii2

En la URL, hemos introducido el parámetro “r” para indicar dónde queremos dirigirnos, esto también podemos hacerlo para el resto de páginas que vayamos creando en nuestra aplicación, como:

Empecemos con Gii, primero vamos a ver la opción Model Generator desde la cual se realiza el mapeo de las tablas que están en nuestra base de datos a las clases (.php) que representan nuestro modelo, como es el caso de User. En este caso ya disponemos de un archivo que representa nuestra clase, pero si no existiese, Gii lo generaría y en su contenido escribiría todo el código necesario para establecer el mapeo.

Tal vez os estéis preguntando: ¿Qué ocurre si el fichero ya está generado? Buena pregunta para empezar a familiarizarnos con la magia de esta herramienta. Fijaos en la siguiente imagen, cuando introducimos los valores de los campos que solicita:

gii3

Gii nos indica que puede sobre escribir (overwrite) el archivo que ya existe en nuestro proyecto (models/User.php) introduciendo una serie de cambios (diff). Si clicamos sobre diff vemos que gii dispone de un comparador de código similar al que traen las herramientas de versionado de código, donde podemos ver (marcado en verde) qué nos propone Gii añadir y qué quitar (en rojo):

gii4

Ha llegado el momento de experimentar con Gii y ver como funciona realmente, para ello vamos a generar una parte muy interesante de nuestro proyecto como es la administración de los usuarios registrados que hasta ahora solo podíamos consultar mediante phpmyadmin  u otros gestores de BBDD.

Para ello vamos a la segunda opción que marqué: CRUD Generator. Como ya habréis deducido, esta opción nos permite generar las opciones de Lectura (Create), Consulta (Read), Actualización (Update) y Borrado (Delete):

gii5

las vistas desde las que se invocan estos métodos. Si abrimos el fichero del controlador encontramos métodos como:

public function actionIndex() {...}

public function actionView($id) {...}

public function actionCreate() {...}

public function actionUpdate($id) {...}

public function actionDelete($id) {...}

Estos métodos son invocados desde las vistas para realizar las operaciones CRUD contra la tabla User y por supuesto se pueden modificar según nuestras necesidades. Pulsemos “Generate” para que Gii autogenere nuestro código:

gii6

A partir de ahora podemos visualizar los usuarios dados de alta en la base de datos y administrarlos de forma visual e intuitiva desde nuestra aplicación web, con solo acceder a la URL: http://localhost:8888/basic/web/index.php?r=user

gii7

En cuanto a los ficheros de las views, destacar que, el fichero con nombre _form es el que representa el formulario base con el que se construyen los formularios de creación (create.php) y actualización (update.php) de manera que si queremos, por ejemplo, mostrar la información de forma distinta a la hora de crear un usuario que al darlo de alta pero utilizando los mismos campos, deberíamos modificar los ficheros create y update y si lo que queremos es que cuando demos de alta o editemos la información de un usuario nos solicite un campo concreto, debemos incluirlo dentro el fichero _form. Veamos su contenido para realizar un ejemplo:

gii8

Si desde nuestro navegador accedemos a la URL: http://localhost:8888/basic/web/index.php?r=user%2Fcreate o bien pulsamos sobre el botón “Create user” vemos que lo que genera el código anterior es un único campo con el que dar de alta al usuario. Esto no es muy práctico porque como mínimo un nombre de usuario y un password deberíamos poder crear ya que son los datos básicos para la autenticación, así que vamos a añadir estos y un campo email en el archivo _form.php antes del campo status. Si volvemos al navegador y refrescamos (Ctrl+R) vemos nuestros 3 nuevos campos listos para recoger los datos del usuario que vamos a crear:

gii9

Es más, si editamos el usuario que ya teníamos creado inicialmente vemos que también aparecen estos campos:

gii10

Si queremos, podemos aportar comportamientos distintos entre los formularios de creación y actualización, por ejemplo, como hemos hecho aquí, hemos incluido el campo “created_at” para indicar la fecha de creación del usuario. Para ello he modificado el código del fichero update.php eliminando la renderización del fichero _form .php y añadiendo directamente el contenido de este último fichero mas el campo “created_at”. Lo vemos a continuación:

gii11

Probando el código

Vamos a dar de alta un usuario en el sistema a través de la administración:

gii12

El resultado que debe mostraros es el siguiente:

gii13

El sistema indica que se ha creado un nuevo usuario, pero… algo falla, ¡No aparecen todos los datos que habíamos introducido! Aunque el status si lo ha registrado ¿Dónde está la información correspondiente a ”username”, “password_hash” y “email”? Si consultamos esto directamente en BBDD lo verificamos, se ha generado un nuevo registro pero sin estos datos:

gii14

Entonces… ¿No funciona?

Tal vez alguno de vosotros ya se ha dado cuenta de lo que ocurre o bien, sin darse cuenta, fue precavido y en el paso en el que hablábamos de la generación de las clases del modelo con Gii copió algunos de los cambios que proponía la herramienta, concretamente los que afectaban al método rules de la clase User:

gii15

Al aplicarnos, el código de la función sería algo así:

public function rules()
{
return [
[‘status’, ‘default’, ‘value’ => self::STATUS_ACTIVE],
[‘status’, ‘in’, ‘range’ => [self::STATUS_ACTIVE,                     self::STATUS_DELETED]],
[[‘username’, ‘password_hash’, ’email’], ‘required’],
];
}

Si queréis investigar podéis incluir todo lo que propone Gii pero en mi caso solo he incluido la línea que afecta a los campos en cuestión:

[[‘username’, ‘password_hash’, ’email’], ‘required’],

Con esto estamos definiendo una regla de validación, concretamente required, para los campos username, password_hash email de manera que, se obliga al usuario que rellena el formulario a introducir estos valores. Veamos que ocurre cuando volvemos a crear un nuevo usuario tras añadir nuestras líneas de código:

gii16

Como vemos esta vez si hemos podido crear nuestro usuario con los datos completos. Y ahora os preguntaréis… Y ¿Qué ocurre cuando tenemos campos opcionales y por tanto que puedan dejarse en blanco? Vamos con un ejemplo, seguid estos dos pasos:

  1. Desde phpmyadmin, localizad vuestra tabla usuario de la BBDD y modificad el campo email para que permita valores nulos.
  2. Modificad la última línea que añadimos para que el campo email no sea required:
  3. [['username', 'password_hash'], ‘required’],

    Si damos de alta un tercer usuario vemos que el campo email, de nuevo no aparece registrado ¿Cierto? Pues bien, vamos a utilizar la herramienta de Yii para depurar el código php que vamos ejecutando. Para ello pulsamos sobre la opción LOG de la barra inferior desde el navegador:gii17

    Y a continuación vemos los mensajes generados entre los cuales debéis encontrar uno similar al que aparece en la siguiente imagen:

gii18

Dado el mensaje Falied to set unsafe attribute ’email’ in ‘app\models\User vemos que se indica la línea 65 del fichero UserController.php donde se produce el error. Si lo abrimos vemos que en esa línea el código es el siguiente:

if ($model->load(Yii::$app->request->post()) && $model->save()) {...}

En resumen todo esto se explica porque Yii, por defecto tiene predefinido un mecanismo de seguridad que prevee que se introduzcan valores vacíos en nuestra BBDD que puedan generar inconsistencias o problemas en otras zonas de la web donde se haga uso de ellos. De manera que mientras no indiquemos en algún sitio que en nuestro modelo existen campos que deben ser almacenados INCLUSO CUANDO EL VALOR INTRODUCIDO ES VACÍO, Yii no nos permitirá guardar la información relativa a estos campos.

Para eso Yii nos provee de un tipo de validación llamada safe, con lo que nuestro problema queda resuelto tras añadirla a la función rules. Veamos cómo queda el código:

gii19

Bien! Pues para finalizar, vamos a ver qué ocurre ahora si introducimos el email a la hora de crear un usuario:

gii20

Vemos que estoy introduciendo el email, aunque podría dejarlo vacío si quisiese ya que ya no es un campo required en mi modelo. Y el resultado es el siguiente:

gii21

Os dejo el código del proyecto en este repositorio y os invito a que experimentéis con los campos de vuestro modelo y a que creéis campos nuevos que permitan crear una entidad Usuario en base a las necesidades de vuestro proyecto. Eso sí! acordaros de incluir los nuevos campos en la BBDD también.

Vicente Montaño. Analista en Novanotio.

2018-10-03T09:35:42+00:00 3 agosto 2015 |Categorías: Entornos tecnológicos|Etiquetas: , , , |Sin comentarios

Deje su comentario