ScaffoldController: Modificando vistas

Nelson Rojas — Tue, 16 May 2017 12:54:16 +0000

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

Modificaremos la vista particular de la acción index.
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.

Modificaremos el comportamiento de crear, y editar en nuestro controlador.

Podemos mirar el método crear desde ScaffoldController (app/libs/scaffold_controller.php) y mejorarlo para nuestro controlador de categorias (app/controllers/categorias_controller.php)

Una propuesta podría ser como la que se presenta a continuación:

    public function crear()
    {
        if ( Input::hasPost('Categorias') ) {
            $categoria = new Categorias(Input::post('Categorias'));
          
            //comprobar si se puede realizar la creacion del elemento
            if ( !$categoria->save() ) {
                Flash::error('Falló Operación');
                //hacer persistente el objeto con los datos enviados
                $this->Categorias = $categoria;
                Input::delete('Categorias');
            }
        }
        $this->Categorias = new Categorias;
    }

Esta propuesta elimina la redirección a index, y limpiar el contenido de Input::post(‘modelo’) para que el formulario permanezca en blanco y así nos permita agregar un nuevo elemento de forma inmediata.

Repetiremos el procedimiento en el método editar. Iremos al controlador ScaffoldController, y desde él mejoraremos el método editar, pegándolo bajo el método crear del controlador de categorías. La propuesta para editar debería ser algo como la siguiente figura:

    public function editar($id)
    {
        View::select('crear'); //usamos la misma vista que crear

        if ( Input::hasPost('Categorias') ) {
            $categoria = new Categorias;          
            //comprobar si se puede realizar la actualización del elemento
            if ( !$categoria->update(Input::post('Categorias')) ) {
                Flash::error('Falló Operación');
                //hacer persistente el objeto con los datos del formulario
                $this->Categorias = $categoria;

                Input::delete('Categorias');
            }
        }
        //aplicar autocarga del objeto para comenzar/continuar la edición
        $this->Categorias = (new Categorias)->find((int)$id);
    }

Modificando vistas

Modificaremos la vista index estándar. Para ello crearemos una nueva vista index dentro de app/views/categorias. El archivo debe ser llamado como index.phtml.

La estructura de archivos del proyecto debería verse así:

Copiaremos el contenido de la vista index del scaffolding, la que está en app/views/_shared/scaffolds/kumbia/index.phtml

Quitaremos los atributos de fecha y renombraremos las columnas de nombre y de categoría padre. La vista nos debería quedar más o menos así:

<div id="scaffold">
 View::content()?>
<h1>= ucwords("$model"), ": $action_name" ?></h1>
<div class="actions">
    = Html::linkAction("crear/", 'Crear registro', 'class="btn btn-primary"')?>
</div>

 if (isset($data->items) && (count($data->items) > 0)) : ?>
<table class="t">
    <thead><tr>
    <th>Id</id>
    <th>Nombre</id>
    <th>Categoria Padre</id>
    <th>Acciones</th>
    </tr></thead>
    <tbody>
     foreach ($data->items as $item) : ?>
        <tr>
            <td>= h($item->id)?></td>
            <td>= h($item->nombre)?></td>
            <td>= h($item->categorias_id)?></td>
            <td>= Html::linkAction("ver/$item->id", 'Ver')?> |
            = Html::linkAction("editar/$item->id", 'Editar')?> |
            = Html::linkAction("borrar/$item->id", 'Borrar', 'onclick="return confirm(\'¿Está seguro?\')"') ?>
            </td>
        </tr>
     endforeach?>
    </tbody>
</table>

 View::partial('paginators/digg', false, array('page' => $data ,'url' => Router::get('controller_path').'/index')) ?>
 else : // Si no hay items?>
<h2>No hay ningún registro</h2>
 endif ?>
</div>

Al ejecutar el acceso a la vista deberíamos lograr algo similar a la siguiente figura:

Pero nuestro cliente necesita que la categoría padre quede expresada con el nombre, no con su código de referencia.

Entonces, lo que haremos finalmente es modificar el método index y el modelo que enlaza la tabla categorías de la siguiente forma, comenzando por el modelo (app/models/categorias.php):


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

Modificamos la consulta para dotar a la paginación de la referencia al nombre de la categoría padre usando los parámetros columns y join.

En nuestro controlador de categorías modificaremos el método index para que pueda usar esta nueva paginación, quedando el resultado como se ve a continuación:


class CategoriasController extends ScaffoldController
{
    public $model = 'Categorias';
    public $scaffold = 'skeleton';   

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

Finalmente el resultado de la vista index se verá como lo presenta la siguiente figura:

Hasta aquí llega la publicación dedicada al tema del scaffolding, pero antes de terminar haremos un resumen hasta aquí.

Resumen

En este episodio hemos modificado el comportamiento del método crear sobrescribiendo el método base del controlador Scaffold, también hemos modificado el comportamiento para editar, y para index.

Hemos agregado una vista personalizada para la acción index, y aún así seguimos usando ScaffoldController.

Sólo nos restará por tarea crear nuestro propio Scaffold para poder mantener el principio DRY usando los comportamientos sin redirección para el método crear y editar.

Si te perdiste los otros post de esta serie, puedes leerlos en los siguientes enlaces:

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

ScaffoldController: Modificando comportamientos y contenidos

Un abrazo cordial a nuestros colegas y a los que han de venir,

@nelsonrojas