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.

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">
<?php View::content()?>
<h1><?= ucwords("$model"), ": <span>$action_name</span>" ?></h1>
<div class="actions">
    <?= Html::linkAction("crear/", 'Crear registro', 'class="btn btn-primary"')?>
</div>

<?php 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>
    <?php 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>
    <?php endforeach?>
    </tbody>
</table>

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

<?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:

<?php
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

La entrada ScaffoldController: Modificando vistas se publicó primero en KumbiaPHP Framework PHP en español.

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.

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

<span class="token delimiter"><?php</span>

<span class="token keyword">class</span> <span class="token class-name">Categorias</span> <span class="token keyword">extends</span> <span class="token class-name">ActiveRecord</span> 
<span class="token punctuation">{</span>

    <span class="token keyword">function</span> <span class="token function">getCategorias</span><span class="token punctuation">(</span><span class="token variable">$page</span> <span class="token operator">=</span> <span class="token number">1</span><span class="token punctuation">)</span> 
    <span class="token punctuation">{</span>
        <span class="token keyword">return</span> <span class="token variable">$this</span><span class="token operator">-</span><span class="token operator">></span><span class="token function">paginate</span><span class="token punctuation">(</span>
            <span class="token string">'columns: categorias.id, categorias.nombre, cat.nombre as categorias_id, categorias.creada_at, categorias.actualizada_in'</span><span class="token punctuation">,</span> 
            <span class="token string">'join: left outer join categorias cat on categorias.categorias_id = cat.id'</span><span class="token punctuation">,</span>
            <span class="token string">"page: $page"</span><span class="token punctuation">,</span> <span class="token string">'order: categorias.id desc'</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
    <span class="token punctuation">}</span>

<span class="token punctuation">}</span>

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

<span class="token delimiter"><?php</span>
<span class="token keyword">class</span> <span class="token class-name">CategoriasController</span> <span class="token keyword">extends</span> <span class="token class-name">ScaffoldController</span>
<span class="token punctuation">{</span>
    <span class="token keyword">public</span> <span class="token variable">$model</span> <span class="token operator">=</span> <span class="token string">'Categorias'</span><span class="token punctuation">;</span>

    <span class="token keyword">public</span> <span class="token keyword">function</span> <span class="token function">index</span><span class="token punctuation">(</span><span class="token variable">$page</span><span class="token operator">=</span><span class="token number">1</span><span class="token punctuation">)</span>
    <span class="token punctuation">{</span>
        <span class="token variable">$this</span><span class="token operator">-</span><span class="token operator">></span><span class="token property">data</span> <span class="token operator">=</span> <span class="token punctuation">(</span><span class="token keyword">new</span> <span class="token class-name">Categorias</span><span class="token punctuation">)</span><span class="token operator">-</span><span class="token operator">></span><span class="token function">getCategorias</span><span class="token punctuation">(</span><span class="token variable">$page</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
    <span class="token punctuation">}</span>
 
<span class="token punctuation">}</span>

Ahora se ve así

Con esto lograremos que el listado cumpla que el requerimiento solicitado.

¿Por qué funciona?

Como puede verse, con cambios mínimos hemos logrado adecuar la presentación de la vista index sin actualizar su archivo. Lo que hemos hecho principalmente es un reemplazo dentro de la metadata de ActiveRecord. Scaffolding espera contar con todos los atributos de la tabla de categorías (id, nombre, categorias_id, creada_at, actualizada_in). Nosotros hemos modificado la salida cambiando categorias_id por nombre desde categorias (nombre as categorias_id). Así hemos logrado que el pintador de la vista index haga su tarea sin enterarse del reemplazo que hemos hecho a nivel de modelo.

Bueno, eso es todo por esta semana. En la siguiente entrega veremos cómo modificar una vista particular para hacerla parecer según nuestros requerimientos. (ver parte 3)

Últimas recomendaciones

Recuerden que pueden revisar el código desde: https://github.com/nelsonrojas/Scaffold-KumbiaPHP

No olvides visitarnos en http://slack.kumbiaphp.com/ para contarnos cómo te va usando KumbiaPHP. Si necesitas apoyo procuraremos estar atentos. Además, si te gusta lo que escribimos compártelo ya mismo con tus amigos y colegas.

Saludos y larga vida a KumbiaPHP!

Con cariño desde Talca, Chile: @nelsonrojas

Ps: Si te perdiste lo que escribimos la semana pasada, puedes leerlo aquí: https://www.kumbiaphp.com/blog/2017/04/03/scaffolding-para-crud-abm-sencillos-y-no-tanto-primera-parte/

Si quieres ver lo que sigue: ScaffoldController: Modificando vistas

La entrada ScaffoldController: Modificando comportamientos y contenidos se publicó primero en KumbiaPHP Framework PHP en español.

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)

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’.

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:

<span class="token keyword">CREATE</span> <span class="token keyword">TABLE</span> categorias <span class="token punctuation">(</span>
 id <span class="token keyword">int</span><span class="token punctuation">(</span><span class="token number">11</span><span class="token punctuation">)</span> <span class="token operator">NOT</span> <span class="token boolean">NULL</span> <span class="token keyword">AUTO_INCREMENT</span><span class="token punctuation">,</span>
 nombre <span class="token keyword">varchar</span><span class="token punctuation">(</span><span class="token number">200</span><span class="token punctuation">)</span> <span class="token operator">NOT</span> <span class="token boolean">NULL</span> <span class="token keyword">UNIQUE</span><span class="token punctuation">,</span>
 categorias_id <span class="token keyword">int</span><span class="token punctuation">(</span><span class="token number">11</span><span class="token punctuation">)</span><span class="token punctuation">,</span>
 creada_at <span class="token keyword">timestamp</span><span class="token punctuation">,</span>
 actualizada_in <span class="token keyword">timestamp</span><span class="token punctuation">,</span>
 <span class="token keyword">PRIMARY</span> <span class="token keyword">KEY</span> <span class="token punctuation">(</span><span class="token punctuation">`</span>id<span class="token punctuation">`</span><span class="token punctuation">)</span>
<span class="token punctuation">)</span><span class="token punctuation">;</span>

Ahora crearemos un modelo llamado Categorias.

Archivo: models/categorias.php

<span class="token delimiter"><?php</span>
<span class="token keyword">class</span> <span class="token class-name">Categorias</span> <span class="token keyword">extends</span> <span class="token class-name">ActiveRecord</span>
<span class="token punctuation">{</span>
<span class="token punctuation">}</span>

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

Archivo: controllers/categoria_controller.php

<span class="token delimiter"><?php</span>
<span class="token keyword">class</span> <span class="token class-name">CategoriasController</span> <span class="token keyword">extends</span> <span class="token class-name">ScaffoldController</span>
<span class="token punctuation">{</span>
 <span class="token keyword">public</span> <span class="token variable">$model</span> <span class="token operator">=</span> <span class="token string">'Categorias'</span><span class="token punctuation">;</span>
<span class="token punctuation">}</span>

¡Y hemos terminado!

Así de sencillo ya tenemos nuestro primer CRUD sin dolor.

Tendremos inicialmente las acciones para index, agregar, editar, ver y eliminar, y sólo hemos escrito 7 líneas.

Personalizando las vistas

Y ahora, ¿quién podrá defendernos de la hoja de estilo predeterminada? ¡Excelente pregunta!

Bueno, los muchachos del core ya tuvieron eso previsto para nosotros. Resulta que puedes crear tus propias vistas para usarlas con tus controladores de Scaffold. Basta copiar el contenido de app/views/_shared/scaffold/kumbia en una nueva versión de vistas para tus controladores.

Supongamos que nos piden usar skeleton. Por lo tanto ahora tendremos una carpeta llamada app/views/_shared/scaffolds/skeleton, con los mismos tres archivos de vistas: crear, index, ver.

Y ¿cómo le decimos a nuestros controladores que usen nuestro nuevo conjunto de vistas?
Sencillo:

<span class="token delimiter"><?php</span>
<span class="token keyword">class</span> <span class="token class-name">CategoriasController</span> <span class="token keyword">extends</span> <span class="token class-name">ScaffoldController</span>
<span class="token punctuation">{</span>
 <span class="token keyword">public</span> <span class="token variable">$model</span> <span class="token operator">=</span> <span class="token string">'Categorias'</span><span class="token punctuation">;</span>
 <span class="token keyword">public</span> <span class="token variable">$scaffold</span> <span class="token operator">=</span> <span class="token string">'skeleton'</span><span class="token punctuation">;</span>
<span class="token punctuation">}</span>

El resultado final

Si miramos el resultado tendremos algo como lo que se ve en las siguientes imágenes:

Así de fácil logramos crear nuestro primer CRUD con 8 líneas de código y con nuestro css preferido (o requerido).

Si quieres ver lo que sigue, mira en los enlaces que están a continuación:

Parte 2: ScaffoldController: Modificando comportamientos y contenidos

Parte 3:  ScaffoldController: Modificando vistas

Descarga el ejemplo completo

Pueden descargar el código del proyecto desde el siguiente repositorio de Github

Si buscan el script de la tabla de categorías pueden encontrarlo dentro de app/config/sql

¡Larga vida a KumbiaPHP!

La entrada Scaffolding para CRUD (ABM) sencillos (y no tanto) – primera parte se publicó primero en KumbiaPHP Framework PHP en español.

¡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

La entrada Casi listos para las nuevas versiones se publicó primero en KumbiaPHP Framework PHP en español.

KumbiaPHP 1.0 muestra múltiples mejoras que ofrecen al desarrollador mas posibilidades profesionales al momento de hacer las aplicaciones. Y el rendimiento en velocidad del nuevo core es extraordinario.

Que hemos hecho

• Una Estructura de Directorio totalmente desacoplada el core de nuestra aplicación, además de las múltiples ventajas que ofrece una estructura de directorio tan convencional.
• La clase Kumbia se eliminaron montones de líneas innecesarias que tenían como consecuencia lentitud. Una muestra de ello tenemos que la clase Kumbia en la versión 0.5 sobrepasa las 1000 líneas, mientras que en la versión 1.0 apenas llega a las 100 líneas y siguen haciendo el mismo trabajo solo que mas optimizado :).
• El Router y Dispatcher fueron optimizados y mejorados múltiples métodos. En el caso del Router ya esta 100% funcional el manejo de rutas estáticas.
• Nueva Pantalla de Bienvenida mas amigable y ofreciendo información de primera mano.
• El manejo de Vistas fue depurado en su totalidad, corrigiendo el uso de múltiples templates y mejoras de diseño para la escalabilidad de las aplicaciones.
• La clase Cache fue reescrita con soporte a varios drivers (file, sqlite, memsqlite) se irán agregando otros drivers.
• Nueva clase para la inyección de dependencia Load la cual permite cargar lo necesario donde se necesite. Al igual que la Carga Selectiva de Modelos, esto trae como beneficio que sólo se cargan los modelos necesarios, donde se necesiten. Cosa que no era posible en versiones anteriores a la 1.0 ya que KumbiaPHP cargaba todos los modelos al inicio de la aplicación esto traía como consecuencia lentitud.
• Se ha depurado los Modos de Ejecución de nuestra aplicación, ya sea producción o desarrollo. Esto hace que KumbiaPHP adopte cierto comportamiento de acuerdo al modo de ejecución, como lo puede ser el manejo de cache en modo de desarrollo no se hace necesario manejar cache.
• Pages Controller para el manejo de paginas estáticas, aunque este puede ser utilizado como cualquier otro controller.
• En ActiveRecord se han mejorado todos los validadores y se ha creado el manejo de la meta-data en cache esto hace que el proceso de acceso a datos sea sumamente rápido cuando la aplicación es llevada a producción.
• Mejora en la Persistencia de Datos en el controlador, ahora es el programador quien decide que datos serán persistentes en la ejecución de la aplicación. Esto se traduce en mayor rapidez, ya que anteriormente KumbiaPHP hacia todos los datos persistentes, aunque no se utilizaran.
• Nueva presentación de las excepciones donde se muestra información del error y como corregirlo de forma inmediata de manera que no se tenga que recurrir al manual y otros medios para la solución del mismo.
• Partials para Vistas de Paginadores ahora con una sola línea tenemos varios estilos de paginación (classic, digg, extended, punbb y simple) y podemos crear nuestros propios views de paginadores. También los partials ya no están atados a los controllers.
• Mejoras en la clase Session se han quitado métodos que estaban descontinuados (deprecated).
• Mejoras en la extensión Filter.
• Extensión Logger reescrita para que sea totalmente estática.
• …

Podemos colocar un gran etc. ya que son algunos de los cambios a mencionar, hay otros que no son visibles por todos los usuarios ya que están en el core, pero como se dijo antes se traduce directamente en mejores prestaciones sobre nuestras aplicaciones. Sin duda alguna que esta versión ha sido un salto hacia delante en el avance del proyecto, siendo una versión muy estable.

Que nos falta por hacer

Entre los aspectos mas importante que nos falta por hacer sobre la versión 1.0 y se irán entregando en los próximos betas están:

• Ell nuevo scaffold que tiene un concepción mas convencional, a la que se venia manejando con el componente StandardForm, el cual se convirtió inmantenible. Ya se tiene bastante trabajo adelantado para lo que será el nuevo scaffold el cual promete ser mas personalizable por los usuarios, cosa que es imposible de hacer con el actual StandarForm, donde el usuario podrá crear sus propios scaffold y ser compartidos con la comunidad de KumbiaPHP.
• Migración de los helpers de forma total para que los mismos sean mucho mas rápidos y a su vez la adopción total de jQuery como framework para el manejo de AJAX, pero con estos nuevos helpers sera muy fácil utilizar cualquier framework de javascript de nuestra preferencia.
• Seguir mejorando la velocidad del core, aunque actualmente es rapidísima.

Nueva web para KumbiaPHP

Por último, y no menos importante, estamos creando la nueva web que por supuesto usa KumbiaPHP 1.0 spirit. Dentro también habrá una sección para que la comunidad intercambie extensiones fácilmente.

Actualmente ya tenemos muchas extensiones, que se añaden con una simple línea de código para:

• Editores wysiwyg: tinymce, nicedit,….
• Google Maps
• Mostrar RSS, Atom,…
• Flickr
• Captchas
• etc etc

Bueno, podríamos seguir hablando, pero mejor descarga la beta 1 de KumbiaPHP y notarás la diferencia en seguida (el Spirit).

La documentación con los cambios está en el wiki: KumbiaPHP 1.0 Spirit,  hasta que terminemos el nuevo manual.

Descarga KumbiaPHP 1.0

P.D: Diseñadores de la comunidad estáis invitados para ayudarnos en el diseño de la nueva web. Contactar por el IRC.

La entrada KumbiaPHP Framework 1.0 Beta 1 Liberada! se publicó primero en KumbiaPHP Framework PHP en español.

Dejo la conversación:

<Deyabu> alguien tiene un minuto? tengo una dudilla en el 0.5 :P
<CaChi> di
<Deyabu> tengo ke hace runa consulta a dos tablas y mostrar el resultado..
<Deyabu> lo hago con un find_by_sql?
<CaChi> ok
<CaChi> find_by_all_sql
<CaChi> voten si aun falta alguno
<Deyabu> seria.. $this->consulta1 = $this->ejemplo->find_by_all_sql
<CaChi> seria mejor que lo hicieras en el modelo
<joanhey> depende
<CaChi> osea haz un método en el modelo
<joanhey> si eso sip
<CaChi> y los llamas en tu controller queda mas limpio
<joanhey> usad siempre el modelo
<Deyabu> peor, tengo 2 modelos, 1 por cada una de esas tablas :P
* lucasan (Lucas_Torr@CJ8QBM.BwIdCk.virtual) has left #kumbia
<CaChi> y?
<Deyabu> en cual de los dos modelos lo hago? :P
<CaChi> el que mas te guste
<CaChi> es un SQL
<CaChi> eso no importa
<Deyabu> ok ok
<CaChi> el modelo en este caso es solo un medio de transporte para ejecutar el sql
<CaChi> $this->consulta1 = $this->ejemplo->miMetodo()
<joanhey> segun la consulta
<joanhey> es mejor en uno o en otro
<joanhey> pero por lo demas da lo mismo
<Deyabu> aja…
<CaChi> pienso que iria bien en el modelo que tiene la FK del otro
<CaChi> el modelo padre por asi decirlo
<joanhey> es decir
<Deyabu> y en el modelo, como deberia estar ?
<joanhey> Articulos->conTags
<joanhey> Tags->articulos
<joanhey> eso depende de tu consulta
<joanhey> y como lo usaras
<joanhey> ahora te paso uno
* darghex1 (darghex@CZGfAu.DrI8H6.virtual) has joined #kumbia
<Deyabu> ok … grax
<joanhey> http://kumbia.pastebin.com/m259db340
<joanhey> alli tienes el buscar
<joanhey> y de paso lo puedes usar en otros controller
<joanhey> por ejemplo
<Deyabu> ahi lo estoy viendo..
<joanhey> http://www.copasapobla.com/club/rcd_mallorca/
<joanhey> en el controller club
<joanhey> lo uso para enseñar las noticias que hablan de ese club
<joanhey> al estar en el modelo es facil
<joanhey> en el controller club
<joanhey> hago 2 llamadas
<joanhey> una para que me de los datos del club
<joanhey> Clubs->find(id)
<joanhey> y despues
<joanhey> Articulos->buscar( $club->nombre=
<joanhey> )
<Deyabu> aja…
<joanhey> y no te repites
<joanhey> al estar en el modelo todo es mas facil
<joanhey> y mas reutilizable
<Deyabu> pero esta en el modelo del Club….
<joanhey> la logica debe estar en el modelo siempre
<joanhey> no
<joanhey> mira el modelo que te pase
<joanhey> es el de Articulos
<Deyabu> ahh ahhh ya entendo :P
<joanhey> el modelo
<joanhey> esta para que crees tus propios metodos
<joanhey> sobre esa tabla
<joanhey> y tu despues lo llamas de donde quieras
<Deyabu> y lo llamas $this->articulos=$buscar()
<Deyabu> ?:P
<joanhey> la logica debe estar en el modelo
<joanhey> no
<joanhey> no se llama asi
<CaChi> :S
<joanhey> $this->Articulos->buscar($busqueda);
<Deyabu> :S perdi mis apuntes :P
<Deyabu> ok.. ahi guado eso :P
<joanhey> el ActiveRecord de KumbiaPHP
<joanhey> tiene creados por defecto ya
<joanhey> para tener la vida mas facil
<joanhey> tienes el find, find_all, update, …..
<joanhey> pero lo suyo es que tu crees los tuyos propios
<joanhey> con mas logica
<joanhey> que es diferente para cada app
<joanhey> por ejemplo
<joanhey> ultimos
<joanhey> me muestra los ultimos articulos a partir de hoy
<joanhey> en orden descendente de fecha
<Deyabu> sip…
<joanhey> Articulos->ultimos()
<joanhey> y listo
<joanhey> y lo puedo usar donde quiera

La entrada Como usar los Modelos en KumbiaPHP se publicó primero en KumbiaPHP Framework PHP en español.