UNIVERSIDAD PRIVADA TELESUP FACULTAD DE INGENIERÍA Y ARQUITECTURA CARRERA PROFESIONAL DE INGENIERÍA DE SISTEMAS E INFORMÁTICA V CICLO
MONOGRAFÍA: YII FRAMEWORK
AUTORES: Bailon Victorio, Luis Armando Rodriguez Tume, Bruce Arnold Alex Román Casahuamán, Florencio
DOCENTE: Atunga Vergara Jose Timoteo
LIMA - PERÚ 2017
Dedicatoria
A Dios por la sabiduría e inteligencia inteligencia que que nos da día a día. A nuestros padres por el apoyo incondicional que nos brindan. A todas aquellas personas con sed de conocimiento y deseos de superación, que leen hoy estas páginas y premian pre mian el esfuerzo de este trabajo.
ii
Agradecimientos
Agradecemos
en
primer
lugar
a
Dios por permitirnos finalizarlo con éxito nuestro trabajo de investigación; y en segundo
lugar,
pero
no
menos
importante, a nuestros queridos padres, por su respaldo emocional, moral y económico. En nuestro agradecimiento
ésta
oportunidad,
reconocimiento a nuestro
y profesor
Atunga Vergara Jose Timoteo, por su instruida orientación.
iii
ÍNDICE ÍNDICE .......................................................................................................................................... iv CAPÍTULO I INTRODUCCIÓN .................................................................................................. 6 OBJETIVOS .................................................................................................................................. 7 CAPÍTULO II MARCO TEÓRICO .................................................... .............................................................................................. .......................................... 8 2.1. Framework ............................................... ...................................................... .............................................................................. ........................ 8 2.2. Yii ............................................................................................................................................ 8 2.2.1. Requerimientos ......................................................................................................... 8 2.2.2. Para que es bueno utilizar yii? ............................................... ................................. 8 2.2.3. Cómo se compara yii con otros frameworks? ...................................................... 9 2.3. Instalación ................................................ ...................................................... .............................................................................. ........................ 9 2.3.1. Requerimientos ......................................................................................................... 9 2.4. Creacion de una aplicación yii .................................................. ........................................ 10 2.4.1. Conectándose a base de datos ...................................................... ............................................................................ ...................... 13 2.5. Fundamentos ...................................................................................................................... 13 2.5.1. Modelo vista controlador (MVC) ........................................................................... 13 2.5.2. Script de entrada ..................................................... ..................................................................................................... ................................................ 16 2.5.3. Aplicación ................................................................................................................. 16 2.5.4. Controlador ...................................................................................................................... ...................................................................................................................... 20 2.5.4.1. Ruta (route) .................................................. .................................................... ......................................................... ..... 20 2.5.4.2. Instanciación de controlador ............................................... ............................... 21 2.5.4.3. Acción (Action) ..................................................................................................... 22 ................................................................... .............. 24 2.5.5. Modelo (Model) ............................................. .....................................................
2.5.6. Vista (View) ...................................................................................................................... 26 2.5.6.1. Esquema (Layout) ............................................................................................... 27 ................................................................... .............. 27 2.5.6.2. Widget ................................................. .....................................................
2.5.6.3. Vistas de sistema ................................................ ................................................. 29 2.6. Trabajando con formularios .............................................................................................. 30 iv
2.6.1. Descripción............................................................................................................... 30 2.6.2. Creando el modelo ................................................. ................................................. 30 2.6.2.5.
La declaración de atributos seguros ..................................................... ................................................................. ............ 37
2.6.2.6. Activación-Validación .................................................................................................. 39 2.6.2.7. Recuperación de errores de validación ........................................................ .................................................................... ............ 40 2.6.2.8. Las etiquetas de atributos .......................................................................................... 41 2.6.4. Creando el formulario ..................................................... ............................................................................................. ........................................ 43 2.6.5. Colectando entradas tabulares .............................................. ............................... 46 2.7. Trabajando con Base de Datos ................................................ ........................................ 48 2.7.1. Descripción............................................................................................................... 48 2.7.2. Objetos de acceso a BD ........................................................................................ 49 CONCLUSIONES....................................................................................................................... 55 RECOMENDACIONES ............................................................................................................. 55 Bibliografía................................................................................................................................... 57
v
CAPÍTULO I INTRODUCCIÓN
Muchos de los que se dedican al desarrollo de software software utilizan, conocen o, como como mínimo, se han tropezado con el concepto de framework (cuya traducción aproximada sería “marco de trabajo”).
Sin embargo, el concepto de framework no es sencillo de definir, a pesar de que cualquiera con experiencia programando captará su sentido de manera casi intuitiva, y es muy posible que esté utilizando su propio framework (aunque no lo llame así). En este trabajo se presentara uno de los Frameworks más usados para el desarrollo web, Yii Framework es un framework PHP basado en componentes de alta performance para desarrollar aplicaciones Web de gran escala. El mismo permite la máxima reutilización en la programación web y puede acelerar el proceso de desarrollo.
OBJETIVOS
1) Desarrollo de un CRUD (Create, Read, Update, Delete) con una base de datos. 2) Conocer las diferentes funciones que ofrece Yii. 3) Aprender a usar Yii Framework para desarrollo web.
CAPÍTULO II MARCO TEÓRICO 2.1. Framework 1Un
framework, es una estructura conceptual y tecnológica de soporte
definido, normalmente con artefactos o módulos de software concretos, que puede servir de base para la organización y desarrollo de software. Vamos, una manera de hacernos más fácil la programación.
2.2. Yii Yii es un framework PHP basado en componentes de alta performance para desarrollar aplicaciones Web de gran escala. El mismo permite la máxima reutilización en la programación web y puede acelerar el proceso de desarrollo. El nombre Yii (pronunciado /i:/) es por fácil (en inglés: easy), eficiente (en inglés: efficient) y extensible (en inglés: extensible)
2.2.1. Requerimientos Para correr una aplicación Web Yii, usted necesita tener un servidor Web con soporte PHP 5.1.0 o superior. Para desarrolladores que deseen utilizar Yii, el entendimiento de Programación Orientada a Objetos (OOP) será de gran ayuda ya que Yii es un framework totalmente basado en OOP.
2.2.2. Para que es bueno utilizar yii? Yii es un framework genérico de programación Web que puede ser utilizado para todo tipo de aplicaciones Web. Gracias a que es e s liviano de correr y está
1
Orix Systems, 2017)
equipado con soluciones de cacheo sofisticadas, es adecuado para desarrollar aplicaciones de gran tráfico como portales, foros, sistemas de administración de contenidos (CMS), Sistemas de comercio electrónico (ecommerce), etc.
2.2.3. Cómo se compara yii con otros frameworks? Como la mayoría de los frameworks PHP, Yii es un framework MVC (modelovista-controlador). Yii sobresale frente a frameworks PHP en su eficiencia, su gran cantidad de características y su clara documentación. Yii ha sido diseñado cuidadosamente desde el principio para el desarrollo de aplicaciones de Web. No es ni un subproducto de un proyecto ni un conglomerado de tra bajo de terceros. Es el resultado de la vasta experiencia de los autores en desarrollo de aplicaciones Web y de la investigación y la reflexión de los más populares los frameworks de programación Web y aplicaciones.
2.3. Instalación Para instalar Yii solo debe seguir los siguientes 2 pasos: 1. Descargar el framework Yii Yii de yiiframework.com. 2. Descomprimir el archivo a un directorio accesible accesible por el servicio Web.
2.3.1. Requerimientos Luego de instalar Yii, usted puede verificar si su server satisface todos los requerimientos para utilizar Yii. Para hacerlo debe hacer accesible el script de verificación de requerimientos para utilizar Yii. Usted puede acceder al script de verificación de requerimientos en la siguiente URL en un explorador Web:
http://hostname/path/to/ http://hostname/path/to/yii/requireme yii/requirements/index.php nts/index.php
El requerimiento mínimo de Yii es que su server soporte PHP 5.1.0 o superior. Yii ha sido testeado con Apache HTTP server en los sistemas operativos Windows y Linux. También puede funcionar en otras plataformas que soporten PHP 5.
2.4. Creacion de una aplicación yii Para ingresar al mundo de Yii, en esta sección le indicamos como crear nuestra primera aplicación Yii. Usaremos la poderosa p oderosa herramienta yiic que puede ser utilizada para automatizar la creación del código de ciertas tareas. Por conveniencia asumimos que YiiRoot es el directorio donde Yii se encuentra instalado y WebRoot es la ruta del documento de tu Web Server. Ejecute yiic en la línea de comandos de la siguiente manera: % YiiRoot/framework/yiic webapp WebRoot/testdrive
Esto creará una aplicación Yii esqueleto en el directorio WebRoot/testdrive. Esta aplicación contiene la estructura de directorios requerida por la mayoría de las aplicaciones Yii. Sin escribir ni una sola línea de código, nosotros podemos probar nuestra primera aplicación Yii ingresando a la siguiente URL en un explorador Web:
http://hostname/testdriv http://hostname/testdrive/index.php e/index.php
Como vemos, la aplicación contiene tres páginas: homepage (la página inicial), contact (página de contacto) y login (página de login de usuario). La página inicial muestra información de la aplicación y del estado del usuario logueado, la página de contacto contiene un formulario para rellenar y enviar sus consultas y la página de login de usuario permite a los mismos autenticarse para acceder a contenidos que necesitan privilegios de acceso. Mire las siguientes pantallas para má s detalles.
Ilustración 1 Home page
Ilustración 2 Contact page
Ilustración 3 Contact page with input errors
Ilustración 4 Contact page with success
Ilustración 5 Login page
2.4.1. Conectándose a base de datos La mayoría de las aplicaciones Web utilizan bases de datos. Nuestra aplicación test-drive no es una excepción. Para utilizar una base de datos, primero se debe decir a la aplicación como conectarse a la misma. Esto se realiza
modificando
el
archivo
de
configuración
aplicación WebRoot/testdrive/protected WebRoot/testdrive/protected/config/main.php /config/main.php como
de se
muestra a continuación.
2.5. Fundamentos 2.5.1. Modelo vista controlador (MVC) Yii implementa el diseño de patrón modelo-vista controlador (model-viewcontroller MVC) el cual es adoptado ampliamente en la programación Web. MVC tiene por objeto separar la lógica del negocio de las consideraciones de la interfaz de usuario para que los desarrolladores puedan modificar cada parte más fácilmente sin afectar a la otra. En MVC el modelo representa la información (los datos) y las reglas del negocio; la vista contiene elementos de la interfaz de usuario como textos, formularios de e ntrada; y el controlador administra la comunicación entre la vista y el modelo.
Más allá del MVC, Yii también introduce un front-controller llamado aplicación el cual representa el contexto de ejecución del procesamiento del pedido. La aplicación resuelve el pedido del usuario y la dispara al controlador apropiado para tratamiento futuro. El siguiente diagrama muestra la estructura estática de una aplicación Yii" Ilustración 6 Estructura estática de aplicación Yii
2.5.1.1. Un flujo de tareas típico El siguiente diagrama muestra un típico flujo de tareas de una aplicación Yii cuando resuelve un pedido de usuario:
Ilustración 7 Un típico flujo de tareas de una aplicación Yii
1. Un usuario hace una una petición al script de entrada web / index.php. 2. El script de entrada carga la configuración de la aplicación y crea una instancia de aplicación para manejar la solicitud. 3. La aplicación resuelve la ruta solicitada con la ayuda del componente de aplicación de solicitud. 4. La aplicación crea una instancia de controlador para gestionar la solicitud. solicitud. 5. El controlador crea una una instancia de acción y realiza realiza los filtros para la acción. 6. Si falla algún filtro, la acción se cancela. 7. Si todos los filtros pasan, la acción se ejecuta. 8. La acción carga un modelo de datos, posiblemente desde una base de datos. 9. La acción convierte una vista, proporcionándola con el modelo de datos. 10. El resultado renderizado render izado se devuelve al componente de aplicación de respuesta.
11.
El componente de respuesta envía el resultado renderizado al navegador del usuario.
2.5.2. Script de entrada El script de entrada es el script de inicio y es el que se ocupa de procesar el pedido del usuario inicialmente. Es el único script PHP que el usuario puede pedir directamente para ejecutarse. En la mayoría de los casos, el script de entrada de una aplicación Yii contiene un código tan simple como el siguiente,
// remove the following line when in production production mode defined( defined ('YII_DEBUG' 'YII_DEBUG') ) or define('YII_DEBUG' 'YII_DEBUG', ,true); // include Yii Yii bootstrap bootstrap file 'path/to/yii/framework/yii.php') ); require_once('path/to/yii/framework/yii.php' // create application application instance instance and run $configFile= $configFile ='path/to/config/file.php' 'path/to/config/file.php'; ; Yii:: Yii ::createWebApplication createWebApplication ($configFile )-> ->run run() (); ;
Este script incluye el archivo principal de Yii framework yii.php, crea la instancia de aplicación web con la configuración especificada e inicia su ejecución.
2.5.2.1. Modo Debug Una aplicación Yii puede correr en modo debug o modo producción según el valor de la constante YII_DEBUG. Por predeterminado el valor de esta constante es false lo que significa modo producción. Para correr su aplicación en modo debug defina esta constante con el valor true antes de incluir el archivo yii.php. Ejecutar aplicaciones en modo debug es menos eficiente ya que debe mantener los logos internamente. Por otro lado el modo debug es de mucha ayuda durante la etapa de desarrollo ya que provee información de debug rica cuando ocurre el error.
2.5.3. Aplicación Aplicación (Application) representa repre senta la el contexto de ejecución de cada pedido a la aplicación. Su principal tarea es resolver el pedido del usuario y dispararlo al controlador apropiado para procesamiento futuro. También se utiliza como el lugar
principal para configuraciones que deben estar en el nivel de aplicación. Por esta razón application es también llamado front-controller (controlador principal). Application es creado como un singleton por el script de entrada. El singleton Application puede ser accedido en cualquier lugar mediante Yii::app().
2.5.3.1. Configuración de aplicación Por predeterminado, application es una instancia de CWebApplication. CWebApplication. Para customizarlo normalmente se provee un archivo de configuración (o un arreglo) para inicializar los valores de sus propiedades cuando la instancia application es creada. Una alternativa de personalizar la aplicación es extender CWebApplication. CWebApplication. La configuración es un arreglo de pares llave-valor (key-value). Cada par representa el nombre de una propiedad p ropiedad de la instancia de la aplicación y cada valor representa el valor inicial de la correspondiente propiedad. Por ejemplo, la siguiente configuración configura las propiedades name y defau ltController de application. array( 'name'=> 'name' =>'Yii 'Yii Framework', Framework' , 'defaultController'=> 'defaultController' =>'site' 'site', , )
Usualmente guardamos la configuración en un archivo de script PHP separado (ejemplo: protected/config/main.php). Dentro del script retornamos el arreglo de configuración como a continuación: return array(... ...) );
Para aplicar estas configuraciones pasamos el nombre del archivo de configuración
como
parámetro
al
constructor
de
application
o
a Yii::createWebApplication() como en el siguiente ejemplo el cual es usualmente utilizado en el Script de entrada:
a pplication 2.5.3.2. Directorio base de application
El directorio base de Application refiere a la ruta de directorio que contiene todos los scripts PHP sensibles de seguridad y datos de la misma. Por predeterminado es un subdirectorio llamado protected pro tected que se encuentra bajo el directorio que contiene el Script de Entrada. Puede ser modificado configurando la propiedad basePath en la configuración de application. Las cosas que contiene el directorio base deben ser protegidas para que no sean accesibles por usuarios Web. Con el Apache HTTP server esto se realiza fácilmente creando un archivo .htaccess dentro de ntro del directorio base. El contenido del archivo .htaccess debe ser el siguiente:
deny from all
2.5.3.3. Componentes de application Las funcionalidades de la aplicación pueden ser fácilmente customizadas y enriquecidas con la arquitectura flexible de componentes. Application administra un juego de componentes de aplicación en los que cada uno implementa características específicas. Por ejemplo, appliction resuleve un pedido
de
usuario
con
la
ayuda
de
los
componentes CUrlManager y CHttpRequest. Configurando
la
propiedad components de
application,
podemos
personalizar la class y propiedades de cada uno de los componentes utilizados
en
application.
Por
ejemplo
podemos
configurar
el
componente CMemCache para que utilice múltiples servers encache para realizar el cacheo,
array( ...... 'components'=> 'components' =>array( ...... 'cache'=> 'cache' =>array( 'class'=> 'class' =>'CMemCache' 'CMemCache', , 'servers'=> 'servers' =>array( array('host' 'host'=> =>'server1' 'server1', , 'port'=> 'port'=>11211 11211, , 'weight'=> 'weight' =>60 60) ), 'host'=> =>'server2' 'server2', , 'port' 'port'=> =>11211 11211, , 'weight' 'weight'=> =>40 40) ), array('host' ), ), ), )
En
el
ejemplo
anterior
agregamos
el
elemento cache en
el
arreglo components. El elemento cache define que la clase del componente será CMemCache y la propiedad servers` debe ser inicializada como lo indica. Para
acceder
a
un
componente
de
application
utilice Yii::app()-
>ComponentID, en donde ComponentID indica el ID del componente que desea (ejemplo: Yii::app()->cache). Un componente de aplicación puede ser deshabilitado mediante su configuración indicando la propiedad enabled con un valor false en su configuración. En el caso de intentar acceder a un componente deshabilitado, application le devolver Null.
2.5.3.4. Ciclos de vida de la aplicación Cuando se maneja un pedido de usuario, la aplicación realizará el siguiente ciclo de vida: 1. Configurará el autocargado autocargado de clases y el manejador de errores; 2. Registrará los componentes del núcleo de la aplicación; 3. Cargará la configuración de la aplicación; 4. Inicializará la aplicación mediante CApplication::init() CApplication::init()
Carga de componentes de aplicación static;
5. Ejecuta el evento onBeginRequest; 6. Procesa el pedido de usuario:;
7.
Resuelve el pedido de usuario;
Crea el controlador
Ejecuta el controlador; Ejecuta el evento onEndReques
2.5.4. Controlador Un controlador es una instancia de CController o una de las clases que lo heredan. Es creado por la aplicación cuando un usuario realiza un pedido para ese controlador. Cuando un controlador se ejecuta se realizar el pedido de la acción que utiliza los modelos necesarios y muestra la información a través de la vista apropiada. Una acción, en su forma más simple, es un método de la clase controlador cuyo nombre comienza con action. Un controlador tiene una acción predeterminada. Cuando el usuario no especifica que acción se debe ejecutar, esta será la que se ejecute. Por predeterminado la acción default tiene el nombre de index. Puede ser personalizada modificando la configuración CController::defaultAction. Abajo se encuentra el mínimo código de una clase controlador. Dado que este controlador no tiene ninguna acción definida, pedirle resultará en una excepción.
class SiteController extends CController { }
2.5.4.1. Ruta (route) Los controladores y acciones están definidas por IDs. El ID del controlador se encuentra en la forma de path/to/xyz el cual es interpretado como el archivo de clase controlador protected/controllers/path/to/XyzController.php, donde xyz debe ser remplazada por el nombre de su controlador (ejemplo: post corresponde a protected/controllers/PostController.php). El ID
de acción es el nombre del método sin el prefijo action. Por ejemplo si el controlador contiene el método actionEdit el ID de la acción correspondiente será edit. Los usuarios realizan pedidos por un controlador y acción en términos de ruta. Una ruta se encuentra formada por la concatenación de un ID de controlador y un ID de acción separados por una barra. Por ejemplo la ruta post/edit se
refiere
a PostController y
a
su
acción edit.
Por
predeterminado la urlhttp://hostname/index.php?r=post/edit` realiza el pedido a él ese controlador y esa acción.
Nota: Por predeterminado las rutas distinguen mayúsculas de minúsculas. Desde la versión 1.0.1 es posible utilizar rutas que no distingan mayúsculas de minúsculas modificando en la configuración de la aplicación la propiedad CUrlManager::caseSensitive en false. Cuando esta propiedad no está activada, asegúrese de seguir las convención de que los directorios que contienen controladores deben ser llamados con minúsculas y que ambos, controller map y action map usan claves en minúsculas. Desde la versión 1.0.3 una aplicación puede contener modules. La ruta de una acción de controlador dentro de un módulo cumple es de la forma moduleID/controllerID/actionID. Para más información y detalle vea la sección acerca de módulos.
2.5.4.2. Instanciación de controlador Una instancia de controlador es creada cuando CWebApplication maneja un pedido de usuario. Dado el ID del controlador, la aplicación utilizará las siguientes reglas para determinar cuál es la clase del controlador y cual la ruta al archivo de clase.
Si CWebApplication::catchAllRequest se encuentra especificado, el controlador será creado basado en esta es ta propiedad y se ignorará el ID de controlador especificado por el usuario. Esto es usado mayoritariamente
para dejar la aplicación en un modo de mantenimiento y muestre una página con información estática.
Si
el
ID
se
encuentra
en CWebApplication::controllerMap,
la
configuración de controlador correspondiente se utilizará para crear la instancia del controlador.
Si el ID se encuentra en el formato 'path/to/xyz', la clase de controlador asumida será XyzCOntroller y el archivo de clase correspondiente será protected/controllers/path/to/XyzController.php. Por ejemplo si el ID del
controlador
es admin/user será
controlador UserController y
el
resuelto archivo
por
el de
clase protected/controllers/admin/UserController.php. En caso de que el archivo de clase no exista, un error 404 CHttpException será lanzado. En el caso que se utilicen modules (disponibles desde la versión 1.0.3), El proceso descripto anteriormente es ligeramente diferente. En particular, la aplicación verificará si el ID refiere a un controlador dentro de un módulo y si esto es así, el módulo será instanciado y luego se instanciará el controlador.
2.5.4.3. Acción (Action) Como lo mencionamos anteriormente una acción puede ser definida mediante su nombre y comenzando con la palabra action. action. Una forma más avanzada de realizar esto es definir una un a clase acción y pedirle al controlador que la instancie cuando es requerida. Esto permite que las acciones sean reusadas y genera más reusabilidad. Para definir una nueva clase acción, realice lo siguiente:
class UpdateAction extends CAction { public function run run() () { // place the action logic here } }
Para que el controlador sepa que debe utilizar esta acción hacemos override del método actions() método actions() en nuestra clase controlador de la siguiente manera: class PostController extends CController { actions() () public function actions { return array( 'edit'=> 'edit' =>'applicati 'application.controll on.controllers.post.Up ers.post.UpdateAction' dateAction' , ); } }
En
el
ejemplo
anterior
usamos
la
ruta
alias
application.controllers.post.UpdateAction para especificar que el archivo clase de la acción es protected/controllers/post/UpdateAction.php. Escribiendo acciones basados en clases podemos organizar la aplicación de manera modular.
Por ejemplo, la siguiente estructura de directorios puede ser utilizada para organizar el código de los controladores:
protected/ controllers/ PostController.php UserController.php post/ CreateAction.php ReadAction.php UpdateAction.php user/ CreateAction.php ListAction.php ProfileAction.php UpdateAction.php
2.5.5. Modelo (Model) Un modelo es una instancia de CModel y de las clases que lo heredan. Los modelos son utilizados para mantener los datos y sus reglas de negocio relevantes. Un modelo representa un solo objeto de datos. El mismo puede ser una fila en una tabla de base de datos o un formulario de ingresos por usuario. Cada campo del objeto de datos está representado por un atributo en e l modelo. El atributo tiene una etiqueta y esta se puede validar contra un juego de reglas. Yii implementa dos tipos de modelos: modelo de formulario y active rec ord (registro activo). Ambos extienden de la misma clase base CModel. Un modelo formulario es una instancia de CFormModel. El modelo formulario es utilizado para mantener la colección de datos de las entradas del usuario. Esos
datos coleccionados, utilizados y descartados. Por ejemplo, en una página de login, nosotros podemos utilizar un modelo de formulario para representar la información del nombre de usuario y su contraseña que son provistas por un usuario final. Active Record (AR) es un patrón de diseño utilizado para abstraer la base de datos de una forma orientada a objetos. Cada objeto AR es una instancia de CActiveRecord o una de las clases c lases que lo heredan, representando una única fila de la tabla de base de datos. Los campos de la fila son representados por propiedades del objeto AR. Puede encontrar más información de AR en Active Record.
2.5.6. Vista (View) Una vista es un script PHP que consiste básicamente en elementos de la interfaz de usuario (user interface - UI). La misma puede contener expresiones PHP, pero es recomendable que estas expresiones no modifiquen los datos del modelo y se mantengan relativamente simples. Para el mantener la separación de la lógica y la presentación se recomienda que la gran parte de la lógica se encuentre en el modelo y no en la vista. Una vista tiene el mismo nombre que es utilizada para identificar un archivo script de vista cuando se presenta. El nombre de la vista es el mismo que el nombre del archivo de la vista. Por ejemplo, la vista edit se refiere a el archivo script de vista llamado edit.php. edit.php. Para presentar una vista llame a CController::render() con el nombre
de
la
vista.
Este
método
buscara
la
vista
dentro
del
directorio protected/views/ControllerID. Dentro del script de vista podemos acceder al controlador u tilizando $this. De esta forma podemos pasmar cualquier propiedad del controlador en la vista evaluando $this->propertyName. También podemos utilizar la siguiente forma de llamado a la función render del controlador para pasar datos a la vista.
$this->render $this-> render( ('edit' 'edit', , array( 'var1'=> 'var1' =>$value1 $value1, , 'var2'=> 'var2' =>$value2 $value2, , )); )) ;
En el ejemplo anterior, el método render() extraera el segundo parámetro array en el script de vista para que lo podamos acceder como variables locales $var1 y $var2.
2.5.6.1. Esquema (Layout) El esquema o layout es un tipo de vista especial espe cial que es utilizado para decorar vistas. El mismo contiene usualmente porciones de la interfaz de usuario que son comunes a travez de muchas vistas. Por ejemplo, el esquema o layout puede contener la porción de header y footer y embeber dentro el contenido de la vista,
......header here ......header here...... ...... ......footer ...... footer here here...... ......
En donde $content contiene el resultado de la presentación pr esentación de d e la vista contenida. El esquema o layout es aplicado implícitamente cuando se llama a la funcion render().
Por
predeterminado,
el
script
de
la
vista protected/views/layouts/main.php es utilizado como el esquema. Esto puede
ser
personalizado
modificando CWebApplication::layout o CController::layout. Para presentar una vista sin aplicarle ningún esquema, llame a la funcion renderPartial() en vez de la función render().
2.5.6.2. Widget Un widget es una instancia de CWidget de CWidget o una clase que lo hereda. Es un componente con propósito presentacional principalmente. Los widgets son usualmente embebidos en los scripts de vista para generar interfaces de usuarios complejas y contenidas en los mismos widgets. Por ejemplo, un widget calendario puede ser utilizado para presentar una interfaz de usuario compleja de calendario. Los widgets nos ayudan a tener mayor reusabilidad de la interfaz de usuario.
Para utilizar un widget realice lo siguiente en un script de vista:
->beginWidget beginWidget ('path.to.WidgetClass' ); ?> ...body ... body content that may be captured by the widget widget... ... ->endWidget endWidget() (); ; ?>
O sino también
->widget widget( ('path.to.WidgetClass' ); ?>
El segundo se utiliza cuando el widget no necesita ninguno contenido es su cuerpo. Los widgets pueden ser configurados para customizarse según su comportamiento. Esto es realizado mediante la configuración de sus valores de
propiedades
iniciales
cuando
se
llama
al
método CBaseController::beginWidget método CBaseController::beginWidget o al método CBaseController::widget. método CBaseController::widget. Por ejemplo, cuando se utiliza el widget CMaskedTextField, CMaskedTextField, se puede identificar que máscara se desea utilizar. Podemos hacerlo pasandole un array con los valores de las propiedades inicialmente de la siguiente forma, donde las claves del array son los nombres de las propiedades y los valores del array los valores iniciales de las correspondientes propiedades del widget:
$this ->widget widget( ('CMaskedTextField' ,array( 'mask'=> 'mask' =>'99/99/9999' '99/99/9999' )); )) ; ?>
Para definir un nuevo widget extienda CWidget extienda CWidget y sobrecargue los métodos init() métodos init() y run():
class MyWidget extends CWidget { init() () public function init { // this method method is called by by CController::beginWi CController::beginWidget() dget() } public function run run() () { // this method method is called by by CController::endWidg CController::endWidget() et() }
}
Como un controlador el widget también puede tener sus propias vistas. Por predeterminado, los archivos de vista de un widget se encuentran dentro del subdirectorio views del directorio que contiene el archivo de clase widget. Estas vistas pueden ser presentadas llamando al método CWidget::render(), método CWidget::render(), similarmente a como se realiza en un controlador. La única diferencia es que no se le aplicará ningún esquema o layout a la vista de un widget.
2.5.6.3. Vistas de sistema Las vistas de sistema es la forma de referirse a las vistas utilizadas por Yii para mostrar los errores y la información del logueo. Por ejemplo, cuando un se realiza un pedido de un controlador o una acción inexistente, Yii lanzará una excepción explicando el error. Yii mostrará el error utilizando la vista del sistema específica para el mismo. Los nombres de las vistas del sistema siguen ciertas reglas. Nombres como errorXXX refieren a vistas que muestran las CHttpException con código de error XXX. XXX. Por ejemplo, si CHttpException es lanzada con el código de error 404, la vista error404 será error404 será la que se mostrará. Yii provee un conjunto de vistas de sistema predeterminados que se pueden localizar en framework/views. framework/views. Las mismas pueden ser personalizadas creando
las
vistas
con
de protected/views/system. protected/views/system.
el
mismo
nombre
de
archivo
dentro
2.6. Trabajando con formularios 2.6.1. Descripción La recopilación de datos de los usuarios u suarios a través de los formularios HTML es una de las tareas más importantes en el desarrollo de aplicaciones Web. Además de diseñar formas, los desarrolladores tienen que rellenar el formulario con los valores de datos por defecto o existentes, validar la entrada del usuario, mostrar mensajes de error apropiados para la entrada inválida, y guardar la entrada en almacenamiento persistente. Yii simplifica en gran medida el flujo de trabajo con su arquitectura MVC. Los siguientes pasos suelen ser necesarios cuando se trata de formas de Yii:
Crear una clase de modelo que representa representa los campos de datos para ser recogidos
Crear una acción de controlador con el código código que responde a formar presentación.
Crear un formulario en el archivo de script de vista asociada a la acción del controlador.
2.6.2. Creando el modelo 2.6.2.1. La Creación de Modelos Antes de escribir el código HTML necesario para un formulario, hay que decidir qué tipo de datos esperamos de los usuarios finales y las reglas que estos datos deben cumplir. Una clase de modelo se puede utilizar para registrar esta información. Un modelo es el lugar central para mantener las entradas de usuario y la validación de ellos. Dependiendo de la forma en que hacemos uso de la entrada del usuario, podemos crear dos tipos de modelo. Si se recoge la entrada del usuario, usado y luego desechado, tendríamos crear un modelo un modelo de formulario ; si se recoge y se guarda en la base de datos de la entrada del usuario, usaríamos un registro un registro activo en su lugar. Ambos tipos de
modelo comparten la misma clase de base CModel que define el interfaz común sea necesario por la forma.
2.6.2.2. Definiendo el Model Class A continuación creamos una LoginFormclase LoginFormclase del modelo utilizado para recolectar información del usuario en una página de inicio de sesión. Debido a que la información de acceso sólo se utiliza para autenticar al usuario y no necesita ser salvado, creamos LoginForm como un modelo de formulario. class LoginForm extends CFormModel { public $username ; public $password ; $rememberMe= =false; public $rememberMe }
Tres
atributos
se
declaran
en:
LoginForm: $username, $passwordy $rememberMe. Se utilizan para mantener el nombre de usuario y la contraseña introducida introducida por el usuario, y la opción si el usuario quiere recordar su inicio de sesión. Debido a que $ rememberMe un valor predeterminado false, false, la opción correspondiente cuando se muestra inicialmente en la forma de la conexión será sin marcar.
2.6.2.3. Declaración de reglas de validación Una vez que un usuario envía sus entradas y el modelo se rellena, es necesario asegurarse de que las entradas son válidas antes de usarlos. Esto se hace mediante la validación de las entradas contra un conjunto de reglas. Se especifica las reglas de validación del rules(), método que debe devolver un conjunto de configuraciones de reglas.
class LoginForm extends CFormModel { public $username ; public $password ; public $rememberMe =false; private $_identity ;
rules() () public function rules { return array( array('username, password' , 'required' ), 'rememberMe', , 'boolean' 'boolean') ), array('rememberMe' array('password' , 'authenticate' 'authenticate') ), ); } $params) ) public function authenticate ($attribute ,$params { $this-> $this ->_identity _identity =new UserIdentity ($this $this-> ->username username, ,$this $this>password ); if(!$this $this-> ->_identity _identity-> ->authenticate authenticate ()) $this-> $this ->addError addError( ('password' 'password', ,'Incorrect username or password.') password.' ); } }
El código anterior especifica que username y password son ambos necesario, password debe ser autenticado, y rememberMe debe ser un valor booleano. Cada regla que devuelve rules() debe ser del siguiente formato:
array('AttributeList' 'AttributeList', , 'Validator' 'Validator', , 'on'=> 'on' =>'ScenarioList' 'ScenarioList', , ...additional ... additional options options) )
donde AttributeList donde AttributeListes es una cadena de nombres de atributos separados por comas que necesitan ser validado según la regla; Validator especifica especifica
qué
debe
realizarse
tipo
de
validación; el onparámetro onparámetro es opcional que especifica una lista de escenarios en los que la regla se debe aplicar; y opciones adicionales son pares nombre-valor que se utilizan para inicializar el validador correspondiente valores de las propiedades de los componentes . Desde la versión 1.1.11 es posible lista negra escenarios. Si no desea llevar a cabo la validación por alguna regla cuando escenarios particulares están activos podría especificar exceptel exceptel parámetro que contiene sus nombres. n ombres. La sintaxis es la misma que para onel onel parámetro. Lista de escenarios ( ony ony exceptparámetros) exceptparámetros) podría especificarse en dos formas diferentes, que significa lo mismo: // arbitrary array array with scenario scenario names 'on'=> 'on' =>array('update' 'update', , 'create' 'create') ), // string with with scenario names names separated with with commas (spaces (spaces are ignored) 'except'=> 'except' =>'ignore, 'ignore, this, scenarios, at-all' ,
Hay tres formas de especificar Validator en en una regla de validación. En primer lugar, Validator puede puede ser el nombre de un método en la clase del modelo, como authenticateen authenticateen el ejemplo anterior. El método de validación debe ser de la siguiente firma: /** * @param string $attribute the name of the attribute to be validated * @param array $params options specified in the validation rule */ public function ValidatorName ($attribute ,$params $params) ) { ... }
En segundo lugar, Validator puede ser el nombre de una clase de validador. Cuando se aplica la regla, se creará una instancia de la clase de validador para llevar a cabo la validación real. Las opciones adicionales en la regla se utilizan para par a inicializar los valores de atributo
de
la
instancia. Una
clase
de
validador
debe
extenderse
desde CValidator desde CValidator . En tercer lugar, Validatorpuede ser un alias predefinido a una clase de validador. En el ejemplo anterior, a nterior, el nombre required es el alias a CRequiredValidator que asegura el valor del atributo a ser validado no está vacío. A continuación se muestra la lista completa de los alias de validación predefinidos:
boolean: boolean: Alias de CBooleanValidator de CBooleanValidator , asegurando el atributo tiene un
valor
que
es
o
bien CBooleanValidator bienCBooleanValidator
::
TrueValue o CBooleanValidator :: falseValue .
captcha: Alias de CCaptchaValidator de CCaptchaValidator , asegurando el atributo es igual al código de verificación que aparece en una de CAPTCHA .
compare: Alias de CCompareValidator de CCompareValidator , asegurando el atributo es igual a otro atributo o constante.
email: Alias de CEmailValidator de CEmailValidator , asegurando el atributo es una dirección válida de correo electrónico.
date: Alias de CDateValidator de CDateValidator , asegurando el atributo representa una fecha, hora, fecha y hora o un valor válido.
default: Alias de CDefaultValueValidator de CDefaultValueValidator , la asignación de un valor por defecto de los atributos especificados.
exist: Alias de CExistValidator de CExistValidator , asegurando el valor del atributo se puede encontrar en la columna de la tabla especificada.
file: Alias de CFileValidator de CFileValidator , asegurando el atributo contiene el nombre de un archivo cargado.
filter: Alias de CFilterValidator de CFilterValidator , transformando el atributo con un filtro.
in: Alias de CRangeValidator de CRangeValidator , asegurando los datos se encuentra entre una lista de pre-especificado de valores.
length: Alias de CStringValidator de CStringValidator , asegurando la longitud de los datos está dentro de cierto rango.
match: Alias de CRegularExpressionValidator de CRegularExpressionValidator , asegurando los datos coinciden con una expresión regular.
numerical: Alias de CNumberValidator de CNumberValidator , asegurando que el dato es un número válido.
required: Alias de CRequiredValidator de CRequiredValidator , asegurando el atributo no está vacío.
type: Alias de CTypeValidator de CTypeValidator , asegurando el atributo es del tipo de datos específico.
unique: Alias de CUniqueValidator de CUniqueValidator , asegurando que el dato es único en una columna de tabla de base de datos.
url: Alias de CUrlValidator de CUrlValidator , asegurando que el dato es una URL válida.
A continuación se enumeran algunos ejemplos del uso de los validadores predefinidos: / username is required 'required') ), array('username' , 'required' // username must must be between between 3 and 12 characters characters array('username' , 'length' 'length', , 'min' 'min'=> =>3 3, 'max' 'max'=> =>12 12) ), // when in register register scenario, scenario, password password must match password2 password2 'compare', , 'compareAttribute' => =>'password2' 'password2', , array('password' , 'compare' 'on'=> 'on' =>'register' 'register' ), // when in login login scenario, scenario, password must must be authenticated authenticated 'authenticate', , 'on' 'on'=> =>'login' 'login') ), array('password' , 'authenticate'
2.6.2.4. Securing attribute assignments Después se crea una instancia de modelo, a menudo necesitamos para rellenar sus atributos con los datos presentados por los usuarios finales. Esto se puede hacer hac er de forma conveniente utilizando la siguiente asignación masiva:
$model=new LoginForm ; $model= $_POST[ ['LoginForm' 'LoginForm'])) ])) if(isset($_POST $model-> $model ->attributes attributes =$_POST $_POST[ ['LoginForm' 'LoginForm'] ];
La última afirmación se llama asignación masiva que asigna cada entrada
en $_POST['LoginForm']
el
atributo
de
modelo
correspondiente. Es equivalente a las siguientes asignaciones: $_POST[ ['LoginForm' 'LoginForm'] ] as $name $name=> =>$value $value) ) foreach($_POST { if($name is a safe attribute attribute) ) $model-> $model ->$name $name= =$value $value; ; }
Es crucial para determinar qué atributos son seguros. Por ejemplo, si nos exponemos la clave principal de una tabla para estar seguro, entonces el atacante podría tener la oportunidad de modificar la clave principal del registro dado y por lo tanto alterar los datos que no está autorizado.
2.6.2. 2.6 .2.5. 5.
La declaración de atributos seguros
Un atributo se considera seguro si aparece en una regla de validación que se aplica en el escenario dado. Por ejemplo, 'required', , 'on' 'on'=> =>'login, 'login, register' ), array('username, password' , 'required' 'email', , 'required' 'required', , 'on' 'on'=> =>'register' 'register' ), array('email'
En lo anterior, los username y passwordse passwordse requieren atributos en el login escenario, login escenario, mientras que los username, username, password y email los atributos son necesarios en register el escenario. Como resultado, si realizamos
una
masiva
asignar
cuando
se
encuentra
en loginescenario, loginescenario, solamente usernamey usernamey password será asignado de forma masiva, ya que son los únicos atributos que aparecen en las reglas de validación para login. login. Por otro lado, si el escenario es register , los tres atributos pueden ser asignados de forma masiva. // in login scenario scenario $model= $model =new User User( ('login' 'login') ); $_POST[ ['User' 'User'])) ])) if(isset($_POST $model-> $model ->attributes attributes =$_POST $_POST[ ['User' 'User'] ]; // in register register scenario $model= $model =new User User( ('register' ); if(isset($_POST $_POST[ ['User' 'User'])) ])) $model-> $model ->attributes attributes =$_POST $_POST[ ['User' 'User'] ];
Entonces, ¿por qué utilizamos esta política para determinar si un atributo es seguro o no? La razón detrás es que si un atributo ya tiene una o varias reglas de validación para comprobar su validez. Es importante recordar que las reglas de validación se utilizan para comprobar los datos de entrada del usuario en lugar de los datos que generamos en el código (por ejemplo, marca de d e tiempo, clave primaria
generada automáticamente). Por lo tanto, NO agregar reglas de validación para aquellos atributos que no esperan aportaciones de los usuarios finales. A veces, queremos declarar un atributo atributo que es es seguro, a pesar de que que en realidad no tienen ninguna regla específica para ello. Un ejemplo es atributo de contenido de un artículo que puede tomar cualquier entrada del usuario. Podemos utilizar el especial saferegla saferegla para lograr este objetivo:
'safe') ) array('content' , 'safe'
Para completar, hay también una unsaferegla unsaferegla que se utiliza para declarar explícitamente un atributo que no es seguro:
array('permission' , 'unsafe' 'unsafe') )
Para las entradas de datos que no son seguros, tenemos que asignarlos a los atributos correspondientes usando declaraciones individuales, como la siguiente:
$model->permission $model-> permission= ='admin' 'admin'; ; $model-> $model ->id id= =1;
2.6.2.6. Activación-Validación Una vez que un modelo se rellena con los datos enviados por los usuarios, podemos llamar CModel CModel :: validate ()para () para activar el proceso de validación de datos. El método devuelve un valor que indica si la validación es correcta o no. Para CActiveRecord Para CActiveRecord modelos, validación también puede ser activado automáticamente cuando llamamos su CActiveRecord su CActiveRecord :: save () método. Podemos establecer un escenario con el escenario el escenario de la propiedad y con ello indica que se debe aplicar conjunto de reglas de validación. La validación se realiza en un escenario base. El escenario El escenario propiedad especifica qué escenario el modelo está siendo utilizado en y qué conjunto de reglas de validación se debe utilizar. Por ejemplo, en el loginescenario, sólo queremos validar los username y las password entradas
de
un
modelo
de
usuario; mientras
que
en
el register escenario, necesitamos validar más entradas, tales como email, address, etc. El siguiente ejemplo muestra cómo debe realizarse la validación en el register escenario:
// creates a User User model in register scenario. scenario. It is equivalent to: to: // $model=new User; // $model->scenario='reg $model->scenario='register'; ister'; $model= $model =new User User( ('register' ); // populates the the input values values into the model model $model-> $model ->attributes attributes= =$_POST $_POST[ ['User' 'User'] ]; // performs the the validation validation if($model $model-> ->validate validate()) ()) // if the inputs inputs are valid ... else ...
Los escenarios de aplicación que una regla se asocia pueden especificar a través de la onopción onopción de la regla. Si la onopción onopción no está
activada, significa que la regla se utilizará para todos los escenarios. Por ejemplo,
public function rules rules() () { return array( array('username, password' , 'required' ), array('password_repeat' 'password_repeat', , 'required' , 'on' 'on'=> =>'register' 'register') ), array('password' 'password', , 'compare' 'compare', , 'on' 'on'=> =>'register' 'register' ), ); }
La primera regla se aplicará en todos los escenarios, mientras que los dos siguientes reglas sólo se aplicarán en el register escenario.
2.6.2.7. Recuperación de errores de validación Una vez que se realiza la validación, los posibles errores serán almacenados en el objeto del de l modelo. Podemos recuperar los mensajes de error llamando CModel :: getErrors () y CModel :: getError () . La diferencia entre los dos métodos es que el primer método devolverá todos los errores para el atributo modelo especificado mientras que el segundo método sólo devolverá el primero error.
2.6.2.8. Las etiquetas de atributos Al diseñar un formulario, a menudo necesitamos para mostrar una etiqueta para cada campo de entrada. La etiqueta le dice al usuario qué tipo de información que se espera que entre en el campo. Aunque podemos codificar una etiqueta en una vista, que ofrecería una mayor flexibilidad y conveniencia, si lo especificamos en el modelo correspondiente. Por defecto, CModel defecto, CModel se devuelva el nombre de un atributo como su etiqueta. Esto se puede modificar para requisitos particulares sobreescribiendo los attributeLabels los attributeLabels () método. Como veremos en los apartados siguientes, especificando las etiquetas en el modelo nos permite crear una forma más rápida y potente.
2.6.3. Creando la acción
Una vez que tenemos un modelo, podemos empezar a escribir la lógica que se necesita para manipular el modelo. Ponemos esta lógica dentro de una acción del controlador. Para el ejemplo de forma de la conexión, se necesita el código siguiente:
public function actionLogin () { $model= $model =new LoginForm ; if(isset($_POST $_POST[ ['LoginForm' 'LoginForm'])) ])) { // collects user user input data data $model-> $model ->attributes attributes =$_POST $_POST[ ['LoginForm' 'LoginForm'] ]; // validates validates user input and and redirect to previous page page if validated if($model $model-> ->validate validate()) ()) $this-> $this ->redirect redirect( (Yii Yii:: ::app app() ()-> ->user user-> ->returnUrl returnUrl) ); } // displays the the login form $this-> $this ->render render( ('login' 'login', ,array('model' 'model'=> =>$model $model)) )); ; }
En lo anterior, primero creamos una LoginForminstancia LoginFor minstancia de modelo; Si la solicitud es una solicitud POST (es decir, la forma de la conexión se presenta),
poblamos $model con
los
datos
presentados $_POST['LoginForm']; entonces validar la entrada y si tiene éxito, redirigir el navegador del usuario a la página que anteriormente necesitaba autenticación. Si la validación falla, o si se accede inicialmente a la acción, que hacen que la loginvista cuyo contenido desee se describe en el apartado siguiente. Vamos a prestar especial atención a la siguiente declar ación PHP que aparece en la acción login: $model-> $model ->attributes attributes= =$_POST $_POST[ ['LoginForm' 'LoginForm'] ];
Como describimos en en Asegurando de misiones de atributos , esta línea de código rellena el modelo con los datos enviados por los usuarios. La attributespropiedad se define por CModel CModel que espera una matriz de pares de nombre-valor y asigna a cada valor al atributo
de modelo correspondiente. Así que si $_POST['LoginForm']nos da una gama tan amplia, el código cód igo anterior sería equivalente a la siguiente larga (suponiendo que todos los atributos necesarios está presen te en la matriz):
$model->username $model-> username =$_POST $_POST[ ['LoginForm' 'LoginForm'][ ]['username' 'username' ]; $model-> $model ->password password =$_POST $_POST[ ['LoginForm' 'LoginForm'][ ]['password' 'password' ]; $model-> $model ->rememberMe rememberMe= =$_POST $_POST[ ['LoginForm' 'LoginForm'][ ]['rememberMe' 'rememberMe'] ];
La tarea que queda ahora es crear la vista login que debe contener un formulario HTML con los campos de entrada necesarios.
2.6.4. Creando el formulario Escribir el loginpunto de vista es sencillo. Empezamos con una formetiqueta cuyo atributo de acción debe ser la dirección URL de la loginacción descrita anteriormente. A continuación, introduzca etiquetas y campos de entrada para los atributos declarados en la LoginFormclase. Al final insertamos un botón de envío, que se puede hacer clic los usuarios para enviar el formulario. Todo esto puede hacerse en el código HTML puro. Yü proporciona algunas clases de ayuda para facilitar la composición de vista. Por ejemplo, para crear un campo de entrada de texto, podemos llamar chtml chtml :: textField () ; para crear una lista desplegable, llame chtml llame chtml :: DROPDOWNLIST () .
A
continuación,
utilizamos html utilizamos html para
crear
el
formulario
de
acceso. Suponemos que la variable $model representa la instancia LoginForm.
-->
El
código
anterior
genera
una
forma
más
dinámica. Por
ejemplo, HTML ejemplo, HTML :: activeLabel () genera una etiqueta asociada con el atributo modelo especificado. Si el atributo tiene un error de entrada, la clase CSS de la etiqueta será cambiado a error, que cambia la apariencia de la etiqueta con estilos CSS correspondiente. Del mismo modo, html modo, html :: activeTextField () genera un campo de entrada de texto para el atributo modelo especificado y cambia su clase CSS a cualquier error de entrada.
Si utilizamos el archivo de estilo CSS form.css proporcionada proporc ionada por el yiic guión, el formulario generado sería como el siguiente:
A partir de la versión 1.1.1, un nuevo widget llamado CActiveForm llamado CActiveForm se proporciona para par a facilitar la creación c reación de formularios. formu larios. El widget es capaz de soportar sin problemas la validación y consistente en ambos lados de cliente y servidor. Usando CActiveForm Usando CActiveForm , el código de la vista anterior se puede reescribir como:
-->
2.6.5. Colectando entradas tabulares A veces queremos recolectar información del usuario en un modo por lotes. Es decir, el usuario puede introducir la información para múltiples instancias de modelo y presentar todos a la vez. Llamamos a esta entrada de tabla porque los campos de entrada a menudo se presentan en una tabla HTML. Para trabajar con la entrada de tabla, primero tenemos que crear o rellenar una matriz de instancias de modelo, dependiendo de si estamos insertar o actualizar los datos. A continuación, recuperar los datos de entrada del usuario de la $_POSTvariable y asignamos a cada modelo. Una ligera diferencia de entrada de un modelo único es que
recuperamos
los
datos
de
entrada
usando $_POST['ModelClass'][$i]en lugar de $_POST['ModelClass'].
public function actionBatchUpdate () { // retrieve items items to be updated updated in a batch batch mode // assuming each each item is of of model class class 'Item' $items= $items =$this $this-> ->getItemsToUpdate getItemsToUpdate () (); ; if(isset($_POST $_POST[ ['Item' 'Item'])) ])) { $valid= $valid =true; foreach($items as $i $i=> =>$item $item) ) { $_POST[ ['Item' 'Item'][ ][$i $i])) ])) if(isset($_POST $item-> $item ->attributes attributes =$_POST $_POST[ ['Item' 'Item'][ ][$i $i] ]; $valid= $valid =$item $item-> ->validate validate() () && && $valid $valid; ; } if($valid $valid) ) // all items items are valid // ...do something something here } // displays the the view to collect collect tabular input $this-> $this ->render render( ('batchUpdate' 'batchUpdate', ,array('items' 'items'=> =>$items $items)) )); ; }
Tener la acción listo, tenemos que trabajar en la batchUpdate para mostrar los campos de entrada en una tabla HTML.
-->
Observamos a lo anterior que usamos "[$i]name" en lugar de "name"como segundo parámetro al llamar chtml chtml :: activeTextField . Si hay algún error de validación, los campos de entrada correspondientes se resaltan automáticamente, al igual que la entrada de un único modelo que describimos anteriormente.
2.7. Trabajando con Base de Datos 2.7.1. Descripción Yii provee un poderoso soporte para la programación con bases de datos. Construído sobre la extensión PHP de Obejotos de Datos (PDO), los Objetos de Acceso a Datos de Yii (DAO) habilitan el acceso a diferentes sistemas de administración de bases de datos (DBMS) en una interfaz uniforme simple. Las aplicaciones desarrolladas usando el DAO de Yii pueden ser fácilmente cambiadas para usar un DBMS diferente sin la necesidad de modificar el código de acceso a los datos. Los Registros Activos de Yii (AR), implementados con un enfoque ampliamente adoptado de Mapeo Objeto-Relacional, simplifican aún más la programación con bases de datos. Representado una tabla en términos de una clase y una fila como una instacia de esa clase, los AR de Yii eliminan e liminan la tarea repetitiva de escribir aquellas sentencias SQL que tratan principalmente con las operaciones CRUD (create, read, update and delete; crear, leer, actualizar, borrar). Aunque el DAO y los AR de Yii pueden manejar casi todas las tareas relacionadas con la base de datos, aún puedes usar tus propias librerías en tu aplicación Yii. De hecho, el framework Yii esta cuidadosamente diseñado para ser usado en conjunto con otras librerías de terceros.
2.7.2. Objetos de acceso a BD 2.7.2.1. Estableciendo la conexión con la base de datos Para establecer la conexión con una base de datos, creamos una instancia de CDbConnetion de CDbConnetion y la activamos. Es necesario un nombre de fuente de datos (DNS) para especificar la información requerida para conectarse a la base de datos. Un nombre de usuario y contraseña pueden ser también necesarios para establecer la conexión. Será arrojada una excepción en el caso de que ocurra algún error al establecer la conexión (ej.: DNS malo o nombre de usuario/contraseña inválidos).
$connection=new CDbConnection ($dsn $connection= $dsn, ,$username $username, ,$password $password) ); // establish connection. connection. You You may try...catch try...catch possible possible exceptions exceptions $connection-> $connection ->active active= =true; ...... $connection-> $connection ->active active= =false; // close connection connection
La forma del DNS depende del driver PDO de la base de datos en uso. En general, un DNS consiste del nombre del driver PDO, seguido por dos puntos (:), seguido por la sintaxis específica del driver. Mira la Documentación
PDO para
una
información
completa.
A
continuación, una lista de los formatos DNS más comunmente utilizados:
SQLite: sqlite:/path/to/dbfile
MySQL: mysql:host=localhost;dbname=testdb
PostgreSQL: pgsql:host=localhost;port=5432;dbname=testdb
Puesto
que CDbConnetion que CDbConnetion extiende
de CApplicationComponent, de CApplicationComponent,
podemos también usarla como un Componente un Componente de Aplicación. Aplicación. Para
hacerlo, configuramos un componente de aplicación db (u otro nombre) en Configuración en Configuración de la Aplicación como sigue,
array( ...... 'components'=> 'components' =>array( ...... 'db'=> 'db' =>array( 'class'=> 'class' =>'CDbConnection' 'CDbConnection', ,
'connectionString'=>'mysql:hos 'connectionString'=> 'mysql:host=localhost t=localhost;dbname=tes ;dbname=testdb' tdb' , 'username' => =>'root' 'root', , 'password' => =>'password' 'password', , ), ), )
Podemos entonces acceder a la conexión de la base de dato s a través de Yii::app()->db (donde db es el nombre que le pusimos al componente) que ya está activada, a menos que explicitamente configuremos aCDbConnection::autoConnect aCDbConnection::autoConnect en false. Usar este enfoque, una simple conexión con la base de datos puede ser usada en diferentes lugares en nuestro código.
2.7.2.2. Ejecutando sentencias SQL Una vez establecida la conexión con la base de datos, las sentencias SQL pueden ser ejecutadas usando CDbCommand. usando CDbCommand. Se crea una instancia CDbCommand instancia CDbCommand llamando a CDbConnetion::createCommand() con
la
sentencia
especificada: $command=$connection -> $command= ->createCommand createCommand( ($sql $sql) ); // if needed, the SQL statement statement may be updated updated as follows: follows: // $command->text=$newSQ $command->text=$newSQL; L;
SQL
Una sentencia SQL es ejecutada a través de CDbCommand de CDbCommand en una de las siguientes dos maneras:
execute(): execute(): ejecuta una sentencia SQL que no es consulta, como INSERT, UPDATE y DELETE. Si es exitosa, devuelve el numero de filas afectadas por la ejecución.
query(): ejecuta query(): ejecuta una sentencia SQL que devuelve filas de datos, como SELECT.
Si
es
exitosa,
develve
una
instancia
de CDbDataReader, de CDbDataReader, a a partid de la cual se recorrer el resultado de las filas de datos. Por conveniencia, están implementados un conjunto
de
métodos queryXXX(),
los
cuales
devuelven
directamente el resultado de la consulta. Será arrojada una excepción si ocurre un error durante d urante la ejecución de una sentencia SQL.
$rowCount=$command $rowCount= $command-> ->execute execute() (); ; // resultados $dataReader= $dataReader =$command $command-> ->query query() (); ; // $rows= $rows =$command $command-> ->queryAll queryAll() (); ; // filas de resultado resultado $row= $row =$command $command-> ->queryRow queryRow() (); ; // fila de resultado resultado $column= $column =$command -> ->queryColumn queryColumn () (); ; // columna de resultado $value= $value =$command $command-> ->queryScalar queryScalar() (); ; // campo en la primer fila
ejecuta una sentencia sentencia SQL sin ejecuta una consulta SQL consulta y devuelve todas consulta todas las consulta y devuelve la consulta la primera consulta y devuelve la consulta la primera consulta y devuelve el consulta el primer
2.7.2.3. Obteniendo resultados de la consulta
Luego
de
que CDbCommand::query() que CDbCommand::query() genere
la
instancia
de CDbDataReader, de CDbDataReader, podemos podemos recuperar filas del resultado llamando a CDbDataReader::read() de manera repetida. Podemos tambien usar un CDbDataReader un CDbDataReader en en un foreach de PHP para recuperar fila a fila.
$dataReader=$command $dataReader= $command-> ->query query() (); ; // calling read() read() repeatedly repeatedly until it returns returns false while(( (($row $row= =$dataReader -> ->read read()) ())!== !==false) { ... } // usando foreach foreach para atravesar atravesar cada fila fila de datos $row) ) { ... } foreach($dataReader as $row // recuperando recuperando todos los datos datos de una vez en un único arreglo arreglo $rows= $rows =$dataReader $dataReader-> ->readAll readAll() (); ;
2.7.2.4. Usando transacciones Cuando una aplicación ejecuta unas pocas consultas, cada una leyendo y/o escribiendo información en la base de datos, es importante aseguarse que la base de datos no se quede sólo con algunas de las consultas llevadas a cabo. Para evitar esto, puede ser iniciada una transacción, representada en Yii como una instancia de CDbTransaction: de CDbTransaction:
Comenzar la transacción.
Ejecutar consultas una a una. Ninguna actualización a la base de datos es visible al mundo exterior.
Consignar la transacción. Las actualizaciones se vuelven visibles si la transacción es exitosa.
Si una de las consultas falla, la transacción entera se deshace.
El anterior flujo de trabajo puede ser implementado usando el siguiente código:
$transaction= $transaction =$connection $connection-> ->beginTransaction beginTransaction () (); ; try {
$connection -> ->createCommand createCommand ($sql1 $sql1) )-> ->execute execute() (); ; $connection -> ->createCommand createCommand ($sql2 $sql2) )-> ->execute execute() (); ; //.... other other SQL executions executions $transaction -> ->commit commit() (); ; } $e) ) // se arroja arroja una excepción excepción si una consulta consulta catch(Exception $e falla { $transaction -> ->rollBack rollBack() (); ; }
2.7.2.5. Vinculando parámetros Para evitar ataques ataques de SQL injection y para mejorar el rendimiento de sentencias SQL usadas repetidas veces, podemos "preparar" una sentencia SQL con marcadores de posición pos ición de parámetros opcionales, que son marcadores que serán reemplazados con los parámetros reales durante el proceso de vinculación de parámetros. El driver subyacente de la base de datos lo hará por nosotros. La vinculación de parámetros debe hacerse antes de que la sentencia SQL sea ejecutada.
// una SQL con dos marcadore marcadore de posición, posición, ":username" ":username" and ":email" $sql= $sql ="INSERT INTO users(user users(username, name, email) VALUES(:username,:email)" VALUES(:username,:email)" ; $command= $command =$connection -> ->createCommand createCommand( ($sql $sql) ); // reemplaza el el marcador de posición ":username" ":username" con el valor real real de username $command-> $command ->bindParam bindParam( (":username" ":username", ,$username $username, ,PDO PDO:: ::PARAM_STR PARAM_STR ); // reemplaza el el marcador de posición ":email" ":email" con el valor real de de email $command-> $command ->bindParam bindParam( (":email" ":email", ,$email $email, ,PDO PDO:: ::PARAM_STR PARAM_STR) ); $command-> $command ->execute execute() (); ; // inserta otra otra fila con un nuevo conjunto conjunto de parámetros parámetros $command-> $command ->bindParam bindParam( (":username" ":username", ,$username2 ,PDO PDO:: ::PARAM_STR PARAM_STR) ); $command-> $command ->bindParam bindParam( (":email" ":email", ,$email2 $email2, ,PDO PDO:: ::PARAM_STR PARAM_STR) ); $command-> $command ->execute execute() (); ;
Los métodos bindParam() métodos bindParam() y bindValue() son muy similares. La única diferencia es que el primero vincula un parámetro con una variable PHP mientras que el último con un valor. Para parámetros que
representan grandes bloques de memoria de datos, es preferible el primero por consideraciones de rendimiento.
2.7.2.6. Vinculando columnas
Al recoger los datos del resultado de una consulta, podemos p odemos también vincular columnas con variables PHP para que qu e sean automáticamente rellenadas con los datos apropiados cada vez que una fila es recogida .
$sql="SELECT username, email FROM users" ; $sql= $dataReader= $dataReader =$connection -> ->createCommand createCommand ($sql $sql) )-> ->query query() (); ; // vincular la 1er columna (username) con la variable $username $username $dataReader-> $dataReader ->bindColumn bindColumn (1,$username $username) ); // vincular la 2da columna (email) con la variable $email $email $dataReader-> $dataReader ->bindColumn bindColumn (2,$email $email) ); while($dataReader $dataReader-> ->read read() ()!== !==false) { // $username $username e $email contienen contienen el nombre nombre de usuaario usuaario y el email de la fila actual }
CONCLUSIONES
1) Se desarrollo de un CRUD (Create, Read, Update, Delete) Delete) con una base de datos. 2) Se llegó a conocer las diferentes funciones que que ofrece Yii. Yii. 3) Se llegó aprender a usar Yii Framework para desarrollo web.
RECOMENDACIONES
1) Recomendamos utilizar las distintas distintas funciones que ofrece Yii, como por ejemplo trabajar con la base de datos, hacer consultas, etc. 2) Es importante tener conocimiento de POO(Programacion Orientado Orientado a Objetos). 3) Se recomienda usar SublimeText para un mejor y comodo desarrollo.
Bibliografía "Introducción: Qué Es Yii | The Definitive Guide To Yii | Yii PHP Framework". 2017. Yiiframework.Com. http://www.yiiframework.com/doc/guide/1.1/es/quickstart.what-is-yii.
"¿Qué Es Un Framework Y Para Qué Se Utiliza? | Orix Systems". 2017. Orix.Es. https://www.orix.es/que-es-un-framework-y-para-que-se-utiliza.
