Hola a todos, traigo a ustedes una mini-guía para la utilización de Yii-Framework. Sirve para empezar a utilizar este Framework de desarrollo ágil muy recomendable para todo tipo de proyectos web, espero les sirva, cualquier duda estoy disponible en @Joge23_rm o por correo joge23@gmail.com. Saludos.

NOMENCLATURA

Cambios a líneas

Agregados de líneas

INSTALACIÓN

Lo primero que debes hacer es descargar el  Framework del sitio: http://www.yiiframework.com/ (versión actual: v1.1.13)

Descomprimir y colocar carpeta sin renombrar (para mantener un control de la versión utilizada para cada proyecto) en la carpeta de elección, sugerida en ambiente linux: /opt/

Para la creación del proyecto utilizamos el Shell de Linux, estando en la carpeta donde se va a alojar el proyecto se escribe /opt/yii_version/framework/yiic webapp nombreProyecto

          p.e. jorge@jorge:/var/www$ /opt/yii-1.1.13.e9e4a0/framework/yiic webapp prueba

El sistema te solicitará confirmar la creación del proyecto, recordar que esto generará una carpeta con el nombre de dicho proyecto en donde estes ubicado. Puedes probar tu proyecto creado, en este ejemplo en el navegador:

http://localhost/prueba/

** En caso de mostrar el siguiente error

PHP warning

date() [<a href=’function.date’>function.date</a>]: It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘America/Chicago’ for ‘CDT/-5.0/DST’ instead

Verificar la configuración de PHP el default_time_zone (Este problema suele presentarse con Zend Studio)

Ya en este punto podrás ver tu sitio funcionando.

A partir de aquí se configurarán los archivos del proyecto, no debes modificar los del Framework a menos que sea muy necesario.

Podemos identificar que se han creado las carpetas de nuestro proyecto, debemos identificar la carpeta Protected que es donde estan los archivos de configuración, las extensiones, y el MVC (Models, Views, Controllers). En este punto están los de la estructura básica del proyecto.

CONFIGURACIÓN Y BASES DE DATOS

prueba/protected/config/main.php

<?php

// uncomment the following to define a path alias

// Yii::setPathOfAlias(‘local’,’path/to/local-folder’);

// This is the main Web application configuration. Any writable

// CWebApplication properties can be configured here.

return array(

          ‘basePath’=>dirname(__FILE__).DIRECTORY_SEPARATOR.’..’,

          ‘name’=>’Prueba’,

          ‘language’=>’es’,

          // preloading ‘log’ component

          ‘preload’=>array(‘log’),

          // autoloading model and component classes

          ‘import’=>array(

                   ‘application.models.*’,

                   ‘application.components.*’,

          ),

          ‘modules’=>array(

                   // uncomment the following to enable the Gii tool

                   ‘gii’=>array(

                             ‘class’=>’system.gii.GiiModule’,

                            ‘password’=>’hfdjkhf’,

                            // If removed, Gii defaults to localhost only.

                             ‘ipFilters’=>array(‘127.0.0.1′,'::1′),

                        ),

                 ),

          // application components

          ‘components’=>array(

                   ‘user’=>array(

                             // enable cookie-based authentication

                             ‘allowAutoLogin’=>true,

                   ),

                               // JQUERY nativo desactivado

                               ‘clientScript’=>array(
‘scriptMap’=>array(
‘jquery.js’=>false,
‘jquery.min.js’=>false,
)
),

                   // uncomment the following to enable URLs in path-format

                    ‘urlManager’=>array(
‘urlFormat’=>’path’,
‘rules’=>array(
‘<controller:\w+>/<id:\d+>’=>'<controller>/view’,
‘<controller:\w+>/<action:\w+>/<id:\d+>’=>'<controller>/<action>’,
‘<controller:\w+>/<action:\w+>’=>'<controller>/<action>’,
),
),

                         ‘db’=>array(
‘connectionString’ => ‘sqlite:’.dirname(__FILE__).’/../data/testdrive.db’,
),

// uncomment the following to use a MySQL database

                         ‘db’=>array(
‘connectionString’ => ‘mysql:host=localhost;dbname=prueba’,
’emulatePrepare’=> true,
‘username’ => ‘usuario’,
‘password’ => ‘dsfsfsdfs’,
‘charset’ => ‘utf8′,
),

‘errorHandler’=>array(

                             // use ‘site/error’ action to display errors

‘errorAction’=>’site/error’,

),

‘log’=>array(

‘class’=>’CLogRouter’,

‘routes’=>array(

array(

‘class’=>’CFileLogRoute’,

‘levels’=>’error, warning’,

),

// uncomment the following to show log messages on web pages

/*

array(

‘class’=>’CWebLogRoute’,

),

*/

),

),
),

// application-level parameters that can be accessed

// using Yii::app()->params[‘paramName’]

‘params’=>array(

// this is used in contact page

‘adminEmail’=>’webmaster@example.com’,

),

);

Lo que hicimos fue modificar el nombre de nuestra aplicación, modificar el lenguaje para el sitio, descomentar el código que permite utilizar Gii (generación de modelos y crud) y le modificamos el campo de Password; agregar el código para deshabilitar el JQuery nativo (recomendado para incluir la versión más nueva y que no choquen), descomentar UrlManager (esto hace que los métodos se muestren con Friendly Url), descomentamos la configuración de DB y agregamos los datos de nuestra base de datos. Con esto finalizamos la modificación de este archivo.

CREACIÓN DE MODELOS

Es importante que el usuario www-data tenga permisos, se sugiere cambiar el propietario del proyecto cuando se utiliza el Gii(esto es porque se generan archivos a partir del navegador), en consola:

sudo chown -R www-data.www-data prueba

En el navegador: http://localhost/prueba/index.php/gii/default/login

Utilizamos nuestra contraseña (la que asignamos para el componente Gii en el archivo de configuración).

Una vez adentro, seleccionamos la sección de Model Generator y en esta parte ingresamos en el campo de Table Name el nombre de la tabla; lo demás es bueno dejarlo por Default. Seleccionamos el botón Preview y te mostrará la lista de archivos generados, en este caso sería un archivo Tablename.php, le das Generate y te regresará un mensaje de éxito.

Este es el proceso para crear los modelos de cada tabla, los cuales permitirán la conexión a la base y a dicha tabla.

p.e. Tablename::model()->findAll();//Con este comando recuperarías todos los registros de la tabla en concreto en forma de array de objetos.

CREACIÓN DE CRUD (CONSULTAS, ALTAS, BAJAS Y CAMBIOS)

A partir de nuestro archivo de modelo generado, podemos crear la consulta, altas, bajas y cambios a nuestra tabla con la opción de Crud Generator, donde sólo ingresaremos el nombre del modelo: Tablename

Al seleccionar Preview  nos mostrará todos los archivos (un Controller y varias vistas) que se van a generar, le damos Generate y listo, podemos empezar a utilizar/modificar según las necesidades del proyecto.

PUNTOS CLAVES

Modelo

Apartado de Rules: Reglas que van aplicarse tanto al Create como al Update de los registros de cada modelo.

Apartado de AttributeLabels: Permite definir las etiquetas de los campos, es muy útil si a lo largo de todo el proyecto se utilizan porque si hay un cambio sólo se modifica una vez.

Controller

Al principio se define el layout general, recomiendo moficar dicha línea y utilizar layout main,

public $layout=’//layouts/main';

El apartado de accessRules  permite definir las reglas de accesso, en la configuración por Default se da acceso a todo(*) a algunas acciones de las clases, a los usuarios logueados(@) a otras y a un usuario en específico a otras (Admin). Este puede ser customizado con opciones como ‘expression’, todo esto viene en la documentación de Yii.

Más adelante están todos los métodos de la clase, los que vienen por Default y los que se crearán para el proyecto.

Views

Gracias al Crud, por cada Controller se generán:

• index.php (Página principal, por Default viene un listado de los elementos de la tabla).
• _view.php (Se renderea parcialmente dentro de index.php, representa uno a uno los elementos que se muestran en la lista).
• view.php (Es la vista individual de cada elemento de la tabla, si se utiliza el controller tablename/1) dirigirá por Default al View de ID 1
• create/update (Contienen al _form que es donde se puede modificar al registro).

Entre otras…

Views site y Layout

En las vistas que vienen generadas desde el principio se encuentran las de Site (vistas básicas, el Index del Home, el contacto y otras. Todas estas son las vistas que serían relativamente estáticas) y las de Layout (main.php contiene el código que envuelve a todas las vistas que se renderean, es decir, el cascarón del sitio).

Espero que esta información les sea de utilidad, aquí les dejos algunos links en donde pueden encontrar más información.

http://www.yiiframework.com/

http://www.yiiframework.com/doc/guide/1.1/en/quickstart.first-app

http://www.yiiframework.com/wiki/

PECL es un repositorio de extensiones PHP, de hecho PECL quiere decir PHP Extension Community Library,  es  decir es un lugar donde están las extensiones PHP más comunes y que más son usadas por la comunidad.

Comparte el mismo sistema de empaquetado que su hermana PEAR, sólo que tiene una diferencia grande y fundamental, lo que se guarda en PECL son extensiones PHP, es decir código C que se compila para que  funcione como librería PHP, añadiendo funcionalidad al lenguaje.

Así muchas extensiones comunitarias, antes de llegar a la distribución “normal” de PHP, primero se vuelven conocidas y populares en PECL. Entonces, una extensión escrita por cualquiera necesita cumplir con los requerimientos de PECL, cubrir ciertas necesidades o carencias, documentarla y demás.

Actualmente las 5 extensiones más populares en PECL son:

1      APC

2      memcache

3      imagick

4      timezonedb

5      mongo

¿Cómo instalar una extensión con PECL?

Para instalar una extensión con PECL, solo hay que usar el comando:   pecl install memcache

Esto hará que se descargue el código fuente de la extensión desde el repositorio, se phpizará, se compilará para generar  un archivo .so, que puede ser cargado con la función dl() o añadiendo extension=memcache.so al php.ini.

Con esto ya tendremos funcionando la extensión en nuestro PHP y podremos utilizar su funcionalidad.

Espero que esto les sea de ayuda.

PHPUnit es un framework open source para el desarrollo, orientado a pruebas ó TDD para culquier código PHP. Es decir, es un framework que nos ayuda a probar nuestro código.

Ahora, ¿Por qué probar nuestro código? Bueno, Sebastian Bergmann creador de PHPUnit, dice algo muy cierto, “todos los programadores cometen errores, pero la diferencia entre los buenos programadores y los malos programadores es que los buenos programadores prueban su código para encontrar esos errores lo más pronto posible“. Y es que esperar a que el software falle por sí mismo para después corregirlo es muy costoso, lento y dificíl de corregir.

La propuesta de PHPUnit y otros frameworks para pruebas es crear pequeñas unidades que revisen funcionalidades puntuales del código y probar que funcionen como debe, además de la posibilidad de automatizar estas pruebas para ejecutarlas frecuentemente, tanto como el código cambie.

Así, para probar el código no es suficiente recargar el navegador como loco, hay que definir la funcionalidad del mismo, separarla en unidades y revisar que cada una funcione como se supone.

La vía típica para instalar PHPUnit es a través de PEAR, aunque también algunos IDEs como Zend Studio ya lo traen integrado. Una vez instalado hay que crear los tests, que no es otra cosa que métodos clases en PHP, y ejecutarlos por línea de comando o desde nuestro IDE; así obtendremos un resultado para cada test. Para que una prueba sea exitosa, todos los tests unitarios deben pasar y obtener un alto porcentaje en la cobertura de código.

Crear tests unitarios puede complicarse si nuestro código no es testeable, es decir, no se presta mucho para hacerle pruebas, saber si un código es testeable o no, crear pruebas más efectivas es algo que sólo con la práctica lograremos.

Espero esto les sea de utilidad.
Saludos.

Dentro de la programación Web es muy frecuente desarrollar una estructura modular compuesta por varios ficheros que vamos llamando según los necesitemos. Por ejemplo, todos conocemos  los includes o requires en PHP que nos permiten incluir ficheros dentro de otros. Esta técnica es especialmente útil en el marcado HTML para separar elementos comunes de las páginas como un header o un footer en archivos independientes que sólo hay que llamar cuando se necesiten.

Sin embargo, pese a que la mayoría de lenguajes incorporan de uno u otro modo esta funcionalidad (la de llamar e incluir otros archivos dentro de él mismo), JavaScript no la presenta de forma nativa. Es por ello que existen numerosas bibliotecas que expanden al lenguaje permitiendo estas inclusiones con un alto grado de control.

NOTA: Actualmente, gracias a la granularidad de los plugins en jQuery y a los patrones de expansión de módulos ya no resulta tan frecuente encontrar el getScript() como lo era en el pasado.

Si no queremos que nuestro código presente dependencias de terceros o simplemente queremos el control de nuestro propio codigo, podemos implementar nuestra propia función para añadir ficheros JavaScript a una página bajo demanda emulando la funcionalidad de estas bibliotecas o los comandos de otros lenguajes.

function CargaScript(url, callback) {
  var script = document.createElement('script');
 
  if (script.readyState) { // Internet Explorer
    script.onreadystatechange = function () {
      if (script.readyState === 'loaded' || script.readyState === 'complete') {
        script.onreadystatechange = null;
        callback();
      }
    };
  } else { // Otros Navegadores
    script.onload = function() {
      callback();
    };
  }
 
  script.src = url;
  document.getElementsByTagName('head')[0].appendChild(script);
}

Sólo tenemos que hacer la distición entre el “famoso” Internet Explorer y los demás navegadores.

El funcionamiento de este código es añadir de forma dinámica una nueva etiqueta script a la cabecera de nuestra página (head) con la dirección URL del recurso a cargar. De forma adicional, incluimos un callback al estilo jQuery que se ejecutará tan pronto como nuestro nuevo script esté disponible.

NOTA: Por otro lado, si a ti te gusta hacer la carga asincrona de tus script, es decir, poner al último el llamado de tus scripts, lo único que tienes que hacer es cambiar el Tag ‘head’ por ‘body’.

EJEMPLO DE USO

Para un ejemplo sencillo, cargaremos la biblioteca del jQuery ubicada en un CDN.

var myLibrary = 'https://ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js';
 
loadScript(myLibrary, function(){
  alert('Ha cargado JQuery!');
});

Si ejecutamos el código anterior, en cuanto el script se cargue y esté disponible, recibiremos el alert definido en el callback avisando que se ha cargado correctamente.

Muchas veces, se dice que al codificar se debe reutilizar código, esto es cierto,  pero no quiere decir que necesariamente se tenga que hacer “copy-paste” de ese código. El duplicar o clonar código dentro de un proyecto,  incrementa la dificultad para mantener el mismo aumentando los tiempos y costos.

Sí, al principio es muy simple y rápido hacer “copy-paste” de algunas o muchas líneas de código, pero si luego se detecta un error o se quiere hacer mejoras, la dificultad para lograrlo se multiplicará por el número de veces que se duplicó ese código en el proyecto. Lo ideal para reutilizar código es crear librerías de funciones o clases que sean sencillas y especializadas, de manera que mantenerlas resulte práctico y fácil.

Una herramienta que nos ayuda a detectar código PHP duplicado es phpcpd (Copy/Paste Detector (CPD) for PHP code) , la cuál fue creada por Sebastian Bergmann, el mismo de PHPUnit , y al igual que phploc se instala desde PEAR.

Instalación

Si no has usado el canal PEAR phpunit.de primero debes “descubrirlo”:

pear channel-discover pear.phpunit.de

pear channel-discover components.ez.no

Y ahora sí podemos instalar el phpcpd

pear install phpunit/phpcpd

Corriendo una prueba

/usr/local/zend/bin/phpcpd sigmabol/

phpcpd 1.3.2 by Sebastian Bergmann.

Found 8 exact clones with 550 duplicated lines in 8 files:

– application/controllers/MatrizinternaController.php:8-163

application/controllers/MatrizController.php:7-162

– application/controllers/MatrizinternaController.php:186-240

application/controllers/MatrizController.php:179-233

– library/Bvb/Grid/Deploy/Pdf.php:285-292

library/Bvb/Grid/Deploy/Pdf.php:436-443

– library/Bvb/Grid/Deploy/Print.php:111-120

library/Bvb/Grid/Deploy/Wordx.php:381-390

– library/Bvb/Grid/Deploy/Wordx.php:79-234

library/Bvb/Grid/Deploy/Odt.php:79-234

– library/Bvb/Grid/Deploy/Print.php:111-120

library/Bvb/Grid/Deploy/Odt.php:352-361

– library/Bvb/Grid/Deploy/Wordx.php:79-233

library/Bvb/Grid/Deploy/Ods.php:79-233

– library/Bvb/Grid/Deploy/Print.php:111-118

library/Bvb/Grid/Deploy/Word.php:111-118

3.64% duplicated lines out of 15116 total lines of code.

Time: 1 second, Memory: 22.25Mb

Al correr el comando nos da una salida con los archivos que tienen líneas de código duplicadas, además un porcentaje de líneas duplicadas respecto al total de líneas del proyecto, el tiempo y memoria que tomó hacer la prueba.

Conclusiones

Esta herramienta nos de una buena idea de la forma en la que reutilizamos nuestro código, lo ideal sería que el 0% de nuestro código esté repetido, por supuesto algunas veces esto no será posible y duplicaremos algo de código, pero es bueno mantener esos porcentajes por niveles bajos.

Eso nos ayuda a fomentar buenas prácticas como la creación de librerías comunes y clases extendibles( léase con la facilidad para ser extendidas por clases hijas).

Además phpcpd y las otras herramientas similares pueden ser integradas con servidores de Continuous Integration como Jenkins y phpUnderControl, lo que nos da una visión completa del QA (Quality assurance) en nuestros proyectos PHP.

Saludos.