ScaffoldController: Modificando vistas

Hasta aquí hemos invertido tiempo en revisar el uso básico del ScaffoldController con KumbiaPHP creando nuestros CRUDs de forma rápida, modificando el estilo de las vistas (al añadir un nuevo conjunto de vistas que cargan mediante la variable de controlador $scaffold), y reemplazando comportamientos particulares para modificar el conjunto de datos (al reescribir el método index).

Nueva meta u objetivo usando ScaffoldController

Este post tiene por objetivo hacer un resumen de lo que ya hemos visto en las entregas anteriores, y sacar aún más partido al uso de scaffolding con nuestro framework, de tal manera que puedas aplicar los conceptos que se describen en otras situaciones y así buscar mantener el principio DRY: No te repitas.

En sí, el uso de Scaffolding es una declaración clara del principio DRY, pues lo usamos para no tener que copiar y pegar comportamientos que son inherentes a diferentes situaciones: como crear, actualizar, eliminar y listar registros de una tabla (a modo de ejemplo, podríamos crear controladores scaffolding o heredables para otras tareas que no sean siempre la gestión de datos en tablas).

A modo de añadir más fuerza al principio, los frameworks de desarrollo web se han creado basándose primariamente en dicha idea: escribir lo necesario, evitando repetir comportamientos, y por ende se disminuye el número de líneas de código, el nivel de errores y, por ende, el tiempo de desarrollo y mantenimiento de los sistemas o aplicaciones creados con ellos.

Por eso es que existe una clasificación de carpetas: para controladores, modelos, vistas, ayudantes (helpers), librerías particulares, y librerías externas (vendors).

Si necesita comprender más los conceptos básicos de nuestro framework puede ver Kumbia Essentials.

Manos a la obra

Como ya se mencionó, un scaffolding es una estrategia para no repetir código que se usa en labores comunes. Hasta aquí lo hemos usado para tener un CRUD de la tabla que representa las categorías, y también nos ha permitido sobrescribir la forma en que hacemos la presentación de la acción index (listar los registros de la tabla).

Ahora iremos un poco más lejos

  1. Modificaremos la vista particular de la acción index.
  2. Sobrescribiremos nuestro controlador para modificar el comportamiento al guardar y actualizar los registros.

El cliente nos pide modificar la visualización de la lista de categorías para quitar de ella los atributos de fecha y renombrar el atributo nombre y categorías por Nombre Categoría y Categoría Padre. También nos solicita modificar el comportamiento de la acción crear para que el formulario aparezca limpio para agregar nuevamente, en vez de viajar a index una vez enviado el formulario.

De igual forma debe hacerse para que la acción editar recargue el formulario modificado en vez de viajar a index. Iremos de lo fácil a lo menos fácil.

Continue reading “ScaffoldController: Modificando vistas”

ScaffoldController: Modificando comportamientos y contenidos

Read More
Vista index con categoría relacionada como texto

La entrega anterior hablamos acerca del uso de la técnica de Scaffolding para CRUD con KumbiaPHP usando la clase ScaffoldController. Espero que muchos se hayan sorprendido gratamente con la funcionalidad que ciertamente ahorra mucho trabajo rutinario, ya que es altamente flexible.

Para que se entusiasmen, dentro de las posibilidades  tenemos: reescribir métodos y modificar comportamientos en controladores, modificar los archivos de vista, e incluso puedes crear tus propios scaffoldings. Pero bueno, vamos paso a paso.

Manos a la obra con ScaffoldController

Vamos a trabajar en base a supuestos. Supongamos que queremos mostrar el nombre de la categoría padre para aquellas categorías que estén anidadas.

Lista de categorías

Como se ve en la lista, las categorías relacionadas sólo se ven con su identificador.
Por lo tanto, vamos a modificar la fuente de datos que pasamos a la vista Index para que ésta pueda presentar los contenidos respectivos.

En el modelo

Lo que vamos a hacer es crear un método que cumpla con lo que queremos lograr: mostrar el contenido de la tabla de categorías incluyendo el nombre de la categoría padre en aquellas categorías que heredan de otra. De este modo tendremos una modificación como la siguiente:

Archivo: models/categorias.php

<?php

class Categorias extends ActiveRecord 
{

    function getCategorias($page = 1) 
    {
        return $this->paginate(
            'columns: categorias.id, categorias.nombre, cat.nombre as categorias_id, categorias.creada_at, categorias.actualizada_in', 
            'join: left outer join categorias cat on categorias.categorias_id = cat.id',
            "page: $page", 'order: categorias.id desc');
    }

}

En el controlador

El segundo cambio lo haremos desde el controlador, para cargar los cambios que hemos hecho en el modelo. Lo que reemplazaremos (porque es una sobre escritura de index en ScaffoldController) será la función index tal como se muestra a continuación.

Archivo: controllers/categorias_controller.php

<?php
class CategoriasController extends ScaffoldController
{
    public $model = 'Categorias';

    public function index($page=1)
    {
        $this->data = (new Categorias)->getCategorias($page);
    }
 
}

Continue reading “ScaffoldController: Modificando comportamientos y contenidos”

Scaffolding para CRUD (ABM) sencillos (y no tanto) – primera parte

Read More
Scaffold

Los inicios

Cuando comenzó el fenómeno de los frameworks de desarrollo web, una de sus banderas de lucha estuvo de la mano de los scaffoldings (andamios).

Un scaffold es en sí una técnica que proveen muchos frameworks, con la que podrás tener un gestor de datos para una tabla particular escribiendo una cantidad mínima de código (en KumbiaPHP bastan 7 líneas de código – excluyendo 2 líneas de encabezado php – ).

En mis primeros años de kumbiero comencé creando un controlador para las acciones clásicas de CRUD (Create, Read, Update y Delete), un modelo para apuntar la tabla de la base de datos y al menos 3 archivos de vista (index, agregar y editar).

Para hacer el CRUD de otra tabla copiaba el controlador inicial en el nuevo, luego editaba todo lo que correspondía, y lo mismo hacía para el modelo y las vistas.

Como verán es un trabajo arduo, pero no es tanto trabajo… a menos que tengas más de 10 tablas.

Si pueden hacer el ejercicio de mirar el bosque desde lejos, casi todos los CRUDs creados tienen las mismas acciones, y usan las mismas vistas (con sus leves diferencias).

La iluminación

Fue entonces que un día de IRC (el chat que usábamos antes), los colegas del core de KumbiaPHP me presentaron a ScaffoldController.

Es un amigo silencioso, puesto que está alojado en default/app/libs, pero además es un amigo confiable, pues hereda de AdminController (eso quiere decir que si damos cierta habilidad de autenticación al AdminController, los controllers que hagamos usando ScaffoldController también estarán asegurados).

Configuración inicial

Si este es un proyecto que ha iniciado desde cero, deberá configurar el acceso a la base de datos antes de continuar.

Para eso usaremos el archivo default/app/config/database.ini. En él se definen los entornos de datos que usará nuestra aplicación, los que normalmente son: development (desarrollo) y production (producción)

Archivo databases.ini de KumbiaPHP

Los parámetros de configuración que debemos revisar son:

  • host: Nombre de red o dirección ip del equipo en el cual está instalada la base de datos.
  • username: usuario de la base de datos.
  • password: contraseña del usuario de la base de datos.
  • name: nombre de la base de datos.
  • type: el tipo de base de datos que usará el proyecto, como mysql, pgsql, oracle.

Para indicarle al proyecto que debe usar uno u otro entorno de base de datos, será necesario modificar el archivo de configuración default/app/config/config.php. De forma predeterminada la configuración del entorno de base de datos es ‘default’, pero lo dejaremos inicialmente como ‘development’.

Archivo config.php de KumbiaPHP

Lista la configuración, sigamos con la acción.

De la teoría a la acción

Bueno, mucho texto y poca acción (o como versa el dicho “mucho ruido y pocas nueces”).

En nuestro primer ejemplo usaremos la clásica tabla de categorías, con la siguiente estructura:


CREATE TABLE categorias (
 id int(11) NOT NULL AUTO_INCREMENT,
 nombre varchar(200) NOT NULL UNIQUE,
 categorias_id int(11),
 creada_at timestamp,
 actualizada_in timestamp,
 PRIMARY KEY (`id`)
);

Ahora crearemos un modelo llamado Categorias.

Archivo: models/categorias.php


<?php
class Categorias extends ActiveRecord
{
}

Y finalmente (sí, finalmente) añadiremos el controlador CategoriasController.

Archivo: controllers/categoria_controller.php


<?php
class CategoriasController extends ScaffoldController
{
 public $model = 'Categorias';
}

Continue reading “Scaffolding para CRUD (ABM) sencillos (y no tanto) – primera parte”

Casi listos para las nuevas versiones

Estamos limpiando el código para la salida de las versiones oficiales de KumbiaPHP.

¡Si versiones en plural!

Versión 0.9 -> 100% compatible con la beta2 . En breve.
Versión 1.0 -> Quitaremos todas las libs y código obsoleto.

La 1.0 con muy pequeños cambios funcionaran las apps de beta2, saldrá unas semanas después de la 0.9

Hemos añadido una nueva carpeta a la beta2. En principio era para la 1.0, pero hemos decidido que también esté en la beta2(0.9). Carpeta vendor, dentro de esta carpeta se autocargaran todas las libs que usan PSR0: Symfony, Zend, Doctrine, Swiftmail, PHPExcel, etc.

Con PHP 5.2 se podrán usar todas las libs de PEAR,  zend framework 1 y compatibles.
Con PHP 5.3 todas las clases PSR0 con namespaces.

KumbiaPHP 1.0 no usará namespaces, pero si se pueden usar. Se podrá usar composer (PHP5.3) y todas las libs de packagist. Documentaremos su uso, que es muy fácil. (Esta en fase beta).

Nuevo ActiveRecord

ActiveRecord nuevo (PHP 5.3): Va a muy buen ritmo el desarrollo, ya es funcional, es rapidísimo y no usa memoria prácticamente. En principio tendrá 3 clases principales:

  • LiteRecord: Para los que prefieren usar SQL. Un ActiveRecord básico y sin generador de consultas. Mejor rendimiento. Ya es funcional
  • ActRecord: Nuevo ActiveRecord aun puliendo y añadiendo cosas.
  • ActiveRecord: Clase compatible con el actual ActiveRecord. Será lo más compatible posible, para facilitar la migración de apps.

Se han añadido tests unitarios y la calidad del código es excelente.

https://github.com/KumbiaPHP/ActiveRecord (Repositorio en github)

https://scrutinizer-ci.com/g/KumbiaPHP/ActiveRecord/?branch=master (Calidad de código)

Hemos estado trabajando mucho, tanto que según Ohlo.net, el mes pasado eramos el 4º proyecto libre con más movimiento (hot) de cualquier lenguaje. Y segundos en PHP. Esta como un proyecto con muy alto nivel de actividad, que dan sólo al 0,6% de los proyectos libres.

https://www.ohloh.net/explore/projects  (Listado de los proyectos más ‘hot’)

https://www.ohloh.net/p/KumbiaPHP_framework

Y vienen más cambios interesantes, que iremos comentando.

Después nos faltará crear la V2.0, que será prácticamente igual a la 1.0. Sólo que mínimo PHP5.3 y todo el core de kumbia pasará a vendor/kumbia/

La V2.0 será aun más rápida.

Nueva web en KumbiaPHP

Trabajamos para tener la nueva web lista, para la salida de las nuevas versiones.

proto.kumbiaphp.com

Como siempre se agradece ayuda de la comunidad en:

  • Crear código
  • Marcar bugs
  • Terminar la documentación
  • Dar a conocer KumbiaPHP

Gracias por el apoyo a KumbiaPHP

KumbiaPHP Framework 1.0 Beta 1 Liberada!

Después de unos meses de arduo trabajo el Nuevo Equipo de Desarrollo de KumbiaPHP Framework se enorgullece en anunciar el Beta 1 de la versión 1.0 codename Spirit, esta versión su enfoque principal estuvo en un refractor del core del framework, una reescritura completa de manera de tener un core muy consistente y mantenible, esto trae efectos directos en nuestros desarrollos de forma positiva, ya que se corrigieron conceptos que se vinieron arrastrando en versiones anteriores.

Continue reading “KumbiaPHP Framework 1.0 Beta 1 Liberada!”