El problema de dejar PRODUCTION en false:

De manera predeterminada, KumbiaPHP expone la información detallada de cualquier tipo de excepción, a modo de permitirle al desarrollador revisar y entender dónde debe realizar mejoras. El problema es que si se olvida de cambiar el flag de PRODUCCION y lo deja en su valor inicial (false) cuando los usuarios finales realicen alguna operación indebida, o exista algún fallo no previsto en el servidor, por ejemplo con el acceso a la base de datos o al sistema de archivo, Kumbia no tendrá contexto de que se trata de una aplicación en producción y expondrá todos los detalles.

La nueva configuración Exception:

La nueva funcionalidad, de forma definitiva, evita exponer información de excepciones, lo cual es un alivio tanto para los desarrolladores como para los clientes. Para permitir la visualización de excepciones se ha agregado un nuevo archivo llamado exception.php. En su contenido se pueden definir las direcciones IP que tendrán permiso para recibir los detalles entregados por KumbiaPHP tanto en desarrollo como en entorno productivo.

Ventajas de la nueva funcionalidad

Dentro de las ventajas que se obtienen con esta nueva mejora podemos mencionar las siguientes:

• Seguridad: evita la exposición accidental de información sensible.
• Control: permite que sólo los desarrolladores o administradores puedan acceder a los detalles de los errores.
• Fácil configuración: los usuarios solo necesitan añadir las IPs de confianza.

Cómo implementar la nueva funcionalidad:

Para implementar la nueva funcionalida necesitamos seguir los siguientes pasos:

1. Configurar las direcciones IP en el archivo exception.php.
2. Comprobar que los errores solo son visibles desde las IPs configuradas.

Caché:

Desde esta nueva funcionalidad, el flag PRODUCTION asignado con el valor true, sólo será reponsable de habilitar el uso de la caché para el sitio web.

Recordatorio:

Nunca está demás dejar un recordatorio extra: aunque estés en modo desarrollo, si no se incluyen las direcciones IP dentro del archivo exception.php verán únicamente el error clásico, sin todos los detalles. Por lo tanto, no se olviden de agregar su propia dirección dentro de la nueva configuración.

Conclusión:

La nueva configuración de Exception en KumbiaPHP es un gran paso hacia la seguridad en entornos de producción, permitiendo que sólo quienes están autorizados puedan ver los detalles de los errores. Este tipo de mejoras no sólo protegen nuestras aplicaciones, sino que también promueven buenas prácticas en el desarrollo. De todos modos, el equipo está trabajando en agregar funcionalidades para esta nueva característica, así que no te pierdas las próximas mejoras que publicaremos también en nuestro blog.

Mucho ánimo a todos en nuestra comunidad, y como siempre les decimos… ¡larga vida a KumbiaPHP!

¡Un abrazo!

La entrada Mejora en la configuración de errores en KumbiaPHP: Nueva funcionalidad Exception para entornos de producción se publicó primero en KumbiaPHP Framework PHP en español.

Una parte importante del trabajo dentro de un Framework MVC es el buen uso de los Modelos. 

El modelo es responsable de mantener el estado de la aplicación. A veces este estado es transitorio, y dura sólo un par de interacciones con el usuario. Otras veces el estado es permanente y se almacena fuera de la aplicación, a menudo en una base de datos.

Un modelo es algo más que datos; impone todas las reglas de negocio que se aplican a esos datos. Por ejemplo, si un descuento no debe aplicarse a los pedidos de menos de de 20 euros, el modelo aplicará la restricción. Esto tiene sentido; al poner la implementación de estas reglas de negocio en el modelo, nos aseguramos de que nada más en la aplicación puede hacer que nuestros datos no sean válidos. El modelo actúa como tanto un guardián como un almacén de datos.

Otra definición para el modelo es la siguiente: es el componente central del patrón (MVC). Es la estructura de datos dinámica de la aplicación, independiente de la interfaz de usuario. Gestiona directamente los datos, la lógica y las reglas de la aplicación.

En muchos casos, especialmente cuando uno comienza a trabajar en MVC, se cree que los modelos son únicamente para la gestión de la persistencia y la consulta de los datos de una base de datos (o de un repositorio)

Fundamentos

Antes de ahondar en los ejemplos y en los errores clásicos, nos gustaría mostrarte una imagen que puede ser de ayuda respecto de la forma en la que deberíamos construir nuestras aplicaciones usando el patrón descrito por Trygve Reenskaug (MVC)

La imagen, que es gentileza del Framework CakePHP, nos indica que una aplicación mal diseñada (Bad cake) tiene mucho código en los controladores y poco en las vistas y modelos. En la práctica, los controladores deberían servirnos principalmente para gestionar el Routing (las urls), interactuar con los modelos y despachar las vistas. En contraposición, una buena implementación (Good cake), debería contener más código en los modelos y menos en las vistas y controladores.

Volvamos un poco a lo que se mencionaba sobre el problema de los recién iniciados en MVC. Si bien es común que un modelo gestione datos de una base de datos, también sirve para gestionar «cosas» que no tienen relación con ello. Un ejemplo puede ser un modelo para un carro de compras. Es completamente factible llevar a cabo esta tarea sin persistencia en el DBMS (Database Management System). Bastaría con hacerlo con el objeto de sesión. Por otro lado, un modelo también podría encargarse de los pagos electrónicos, y luego apoyarse de otro que persista datos. Un modelo podría estar dedicado a la realización de cálculos específicos, otro del envío de notificaciones (SMS, Whatsapp, e-mail, etc), otro de la ejecución de tareas por shell dentro del servidor, y así sucesivamente.

¿Qué es lo más común?

Que las personas definan un modelo heredando de la clase del ORM (Object Relational Mapping) y, por ejemplo, en el caso de las notificaciones o el carro de compras, bastaría con que se utilizara una clase simple.

Vale, que aún no hay ejemplos porque nos quedan algunos fundamentos que debemos considerar.

DRY

Para muchos desconocido por sus siglas, pero viene del inglés Don’t Repeat Yourself. En buen castellano sería «No te repitas». ¿Qué significa esto? Significa que debemos gestionar cada «trozo de código» a su labor respectiva, en un único lugar. ¿Y qué tiene de malo copiar y pegar código? Cuando uno tiene mucho código repetido se rompe el principio DRY.

La repetición puede ser principalmente por desconocimiento de las herramientas que provee el Framework, o la clase de la que uno hereda. Por lo tanto, haz tu tarea de estudiante: revisa los métodos, la documentación y luego ponte manos a la obra para que no repitas cosas que ya están implementadas (lo que comúnmente llamamos reinventar la rueda)

Una vez que no tengas ruedas repetidas, verás que realizar modificaciones será una tarea sencilla, evitando así la fragilidad del código.

OOP

En términos de Orientación a Objetos, muchas veces no tenemos tan clara la diferencia entre el uso de la herencia, métodos estáticos y métodos dinámicos. Este tipo de temas los veremos en los ejemplos.

El ORM

Debemos familiarizarnos con la librería que gestiona la persistencia y las consultas al motor de bases de datos, en especial sus métodos, propiedades y los callbacks. En esto último quisiera detenerme un momento. Los callbacks son la analogía a lo que en un motor de base de datos se conoce como triggers (disparadores). Existen diferentes tipos de triggers, pero en generar se clasifican en los que se ejecutan antes de una acción y los que lo hacen después (before y after respectivamente)

El nuevo LiteRecord implementa callbacks para las acciones de creación (_beforeCreate, _afterCreate), para actualización (_beforeUpdate, _afterUpdate) y para guardar (_beforeSave, _afterSave)

En palabras simples, si el modelo encuentra un método _beforeAlgo, ejecutará dicha función antes de que se ejecute el método «Algo» (asumiendo que «Algo» puede ser Create, Save, Update). Por otro lado un _afterAlgo, se ejecutará luego que la función «Algo» haya finalizado.

Estos temas también los iremos tratando con casos cotidianos. Puedes checar su documentación en este enlace.

Traits 

Desde la versión de PHP 5.4 se implementan los Traits (rasgos, características) Es una buena estrategia para continuar con el principio DRY. De pronto tienes propiedades o métodos que son compartidos entre diferentes clases. Puedes extraer esos métodos en un trait y luego indicar que la clase implementa dichos «rasgos». Así tendrás un único lugar para ellos y finalmente, si hay menos código «innecesario o repetitivo», habrá menos errores y será más fácil de hacer mantención/corrección del mismo.

La entrada Cómo crear modelos de forma correcta se publicó primero en KumbiaPHP Framework PHP en español.

Tendremos un servidor local de PHP perfecto para desarrollo, sin usar WAMP o XAMPP server.

Antes de comenzar, te dejamos un enlace donde se explican las implicancias del WSL (Windows Subsystem for Linux) https://es.wikipedia.org/wiki/Windows_Subsystem_for_Linux

Vamos con los requisitos. Lo primero que necesitamos es habilitar la caracterísca de Subsistema Linux desde Windows.

Instalar WSL en Windows 10

Para ello hacemos clic en inicio y escribimos <em>Características de Windows</em> (en mi caso se verá diferente porque llevo una versión de Windows en inglés)

Luego buscaremos al final de la lista el Subsistema Linux para Windows (ver imagen siguiente)

Lo seleccionamos haciendo clic en la casilla de la izquierda, y finalizamos picando en el botón OK para que los cambios sean aplicados.

Tendremos que reiniciar para que la configuración se vea actualizada.

Seleccionar la distribución de Linux en la Tienda de Microsoft

Una vez hecho eso, iniciaremos a la aplicación Tienda de Microsoft (Microsoft Store) y usando su buscador, escribiremos la palabra linux.

La lista de opciones es variada pues se cuenta con Ubuntu, Kali, Debian, OpenSuse, entre otros. Para cuestiones de demostración he seleccionado la opción Debian (aunque en otra máquina lo he probado con Ubuntu 18.04).

Bastará con seleccionar la opción de vuestro gusto, y luego presionar el botón Obtener (Get en mi caso)

Puede que el instalador te pregunte, si quieres mantener sincronizadas tus máquinas de acuerdo a tu cuenta. En mi caso, prefiero que sólo sea instalado en esta máquina, sin importar la sincronización posterior (para ello te requerirá iniciar sesión con una cuenta de Windows Live – Hotmail, Outlook u otra)

En este diálogo he seleccionado «No, gracias». Luego de la respuesta, ha comenzado el proceso de instalación.

Crear usuario y contraseña de la consola de linux

Cuando la configuración de la consola linux haya finalizado, nos pedirá crear un usuario con nombre y contraseña.

Noten que el nombre de usuario de la consola, no tiene por qué coincidir con el nombre de usuario de la máquina de Windows. Una vez creado el usuario habremos finalizado la instalación de la consola de Linux!

Entonces ya tenemos nuestra estación Linux completamente funcional. 

Actualizar paquetes de Linux

En los derivados de Debian (como Ubuntu y Kali) les recomiendo comenzar ejecutando el comando:

<span class="token function">sudo</span> <span class="token function">apt-get</span> update

Con ello cargarás los repositorios de paquetes que podrás usar posteriormente.

Instalar PHP y MariaDB (MySql) en la consola Linux de Windows

Para usar Debian y derivados, con los requerimientos mínimos de desarrollo kumbiero necesitamos hacer la siguiente instalación

<span class="token function">sudo</span> <span class="token function">apt-get</span> <span class="token function">install</span> php php-cli php-mysql mariadb-server php-mbstring <span class="token function">git</span> <span class="token function">wget</span> unzip

Instalar KumbiaPHP framework

Una vez que hemos finalizado la instalación, podemos hacer una prueba descargando la versión de KumbiaPHP desde la página principal del proyecto

Lo hacemos desde el icono de descarga para el formato tar. Hacemos clic con el botón secundario (normalmente el derecho) y copiamos el link desde el botón Copiar enlace (Copy link)

Luego desde la consola escribimos wget y pegamos lo que tenemos en el portapaleles. Deberíamos lograr una línea de ejecución como la siguiente:

<span class="token function">wget</span> https://github.com/KumbiaPHP/KumbiaPHP/archive/v1.0.0.tar.gz

Descomprimimos la descarga:

<span class="token function">tar</span> xvfz v1.0.0.tar.gz

Y renombramos la carpeta resultante con un nombre que tenga relación con el trabajo que llevaremos a cabo (usando el comando mv)

Finalizamos la prueba de instalación entrando en la carpeta que hemos creado hasta llegar a <strong>default/app</strong>

Servidor PHP local

Sin instalar Apache o Nginx,  escribiendo el comando:

bin/phpserver

Windows nos preguntará, si acaso queremos permitir conexiones desde redes internas o desde fuera de la red. Para efectos de prueba he seleccionado ambas opciones y he presionado el botón «Permitir acceso» (Allow access)

Entonces, nuestra aplicación recién instalada de KumbiaPHP estará disponible desde la dirección http://0.0.0.0:8001. En caso que no resulte también puedes invocarla usando la url de http://localhost:8001, o usando http://127.0.0.1:8001, o incluso la dirección ip interna de tu máquina como por ejemplo http://192.168.1.101:8001. Esta última opción nos servirá para hacer pruebas desde otros dispositivos conectados a la misma red (por ejemplo desde un tablet, o un móvil)

Permisos de la base de datos (Mysql, MariaDB, Postresql, otros)

Un dato final, es si usamos MySQL o MariaDB o Postgresql, Windows nos preguntará si queremos dar acceso a dichos servicios, tal como ha hecho cuando hemos lanzado <strong>bin/phpserver</strong>. En dicho caso sólo les recomiendo habilitar el uso en el equipo y la red local. No para el exterior. Aunque esta es una decisión que debe tomar cada uno.

¿Y qué hemos ganado con lanzar KumbiaPHP con el comando bin/phpserver?

Pues la ventana en la que lo hemos lanzado, se ha convertido en una ventana de log de utilización, por la que veremos cada una de las acciones que realice el framework mientras estamos trabajando con él

Y lo más importante, también veremos los errores al instante, para depurar más rápidamente nuestas aplicaciones.

Y hasta aquí nuestra publicación :-)

Esperamos que les sea de utilidad y que con ello tengan nuevas opciones de disfrutar programando con el framework más rápido del oeste!

Saludos a todos nuestros colegas kumbieros!

Post data: si eres nuevo por aquí te recomendamos ver algunos de nuestros posts para los recién llegados:

KumbiaPHP essentials

Scaffolding con KumbiaPHP

Dicho esto,

Larga vida a KumbiaPHP!

La entrada Servidor PHP desde la consola Linux de Windows se publicó primero en KumbiaPHP Framework PHP en español.

Va especialmente dedicado a nuestros colegas que alguna vez han llegado al chat grupal con la frase:

Es que no funciona en producción

La primera pregunta que debemos resolver es:

¿Por qué no funciona?

A continuación presentamos una lista de los temas más comunes que deberíamos tener en cuenta para resolver la pregunta que impulsa este artículo.

1. ¿El servidor apache está ejecutándose?
2. ¿El mod rewrite está activo?
3. ¿El mod rewrite está configurado para nuestra ruta en el servidor?
4. ¿PHP está instalado y configurado?
5. ¿El servidor de bases de datos está activo?
6. ¿La cuenta en el servidor de bases de datos es la que corresponde en la configuración de nuestra aplicación?
7. ¿Hemos trasladado todos los cambios desde el servidor de bases de datos de desarrollo hacia el servidor de producción?
8. ¿Nuestra aplicación tiene los permisos bien configurados?
9. ¿Hemos copiado completamente la aplicación desde el servidor de desarrollo (incluidos todos los archivos .htaccess)?
10. ¿Hemos configurado correctamente la constante PUBLIC_PATH?
11. ¿Podemos usar PATH_INFO o necesitamos cambiar la estrategia de generación de URL?
12. Si estamos completamente a ciegas, ¿hemos activado la visualización de errores?
13. El sitio presenta un error ERR_TOO_MANY_REDIRECTS al cargarlo.

NOTA: Si es la primera vez que haces un paso a producción (deployment) a un servidor dedicado o en un hosting compartido, te recomendamos leer los siguientes artículos que hemos alojado en nuestra wiki.

• Pasar a producción: http://wiki.kumbiaphp.com/Pasar_a_produccion
• Kumbia en servidor con CPanel: http://wiki.kumbiaphp.com/KumbiaPHP_en_servidor_con_CPanel

Continuemos entonces con el checklist:

¿El servidor Apache está ejecutándose?

Nuestra primera tarea será revisar que el servicio de Apache se encuentre activo y en el puerto necesario. Asumiendo que la tarea de despliegue (deployment) se realiza en un servidor linux, podemos revisar si el servicio está activo y si acaso el puerto está escuchando.

Revisemos el servicio web con los siguientes comandos:

ps -fea | grep -i http
ps -fea | grep -i apache

Si encontramos resultados, es decir, al menos 2 líneas se visualizan como salida a nuestro comando*, es que el servicio está activo.

*el comando ps es “process status” o estado del proceso. Las opciones -fea son para indicar que nos liste los procesos de nuestro usuario como del resto, así como algo de información relacionada con el proceso. Para realizar el filtro entre todos los procesos hemos usado un pipe | o tubería para enviar el resultado del comando ps al comando grep que buscará en la lista si acaso existe algo que contenga el texto “http”, o algo que contenga “apache”. Se usa con -i para que no discrimine entre mayúsculas y minúsculas o alguna combinación de ellas. Para más ayuda sobre estos comando les recomendamos usar el comando man ps o también pueden usar man grep.

NOTA: si usan el comando man (manual) para ps o para grep lo más seguro es que se encuentren con el editor vi. Para salir de él bastará con presionar Esc (escape), luego : (dos puntos) y luego q (la letra q para quit).

Revisemos ahora que el servicio está activo y escuchando peticiones.

Para eso nos bastará en primera instancia abrir un navegador y apuntarlo a la dirección de nuestro servidor. Si tenemos respuesta de la página de bienvenida del servicio (apache) ya tendremos este tema resuelto.

Ahora, si tenemos acceso por consola, podemos probar usando el comando

netstat -av | grep http

En mi caso, uso apache y su nombre de servicio es http. En otros Sistemas Operativos o paquetes de software que incluyen Apache, el servicio web puede encontrarse como apache o apache2.

¿El mod rewrite está activado?

Esta pregunta no es difícil de responder si usamos un pequeño archivo PHP al que llamaremos info.php. En él escribiremos <?php phpinfo(); ?> y luego lo abriremos desde el navegador (normalmente http://localhost/info.php)

Así aprovecharemos para revisar que PHP está activo y en la versión del mismo.

Una vez cargue la página de información de php buscaremos (en general con Ctrl + F o Cmd + F) la palabra rewrite. Deberíamos encontrarla en la sección apache2handlers, en la fila Loaded Modules.

Como se aprecia en la imagen anterior también está activo mod_php7 :-)

En caso que no lo encontremos, o que el archivo info.php no nos dé información, bastará con hacer la activación desde la consola (en el caso de tener servidor con shell activa). Vamos a asumir que usamos un servidor con un sistema operativo derivado de debian (ubuntu o similar). Entonces escribiremos en la consola como root

a2enmod rewrite

Y luego reiniciamos el servicio de apache (también como root)

service apache2 restart

Con esto ya deberíamos tener activado el módulo de sobrescritura de url.

¿El mod rewrite está configurado para nuestra ruta en el servidor?

Bueno, no basta con activar el mod rewrite, hay que configurarlo también.

Nota del autor: esto es lo que normalmente hago en mi configuración de apache. 
No sé si es lo más recomendado. Los comentarios son bienvenidos :)

Para realizar este cambio iremos al archivo de configuración de apache (generalmente alojado en /etc/apache2/apache2.conf)

Lo editaremos y buscaremos una sección llamada Directory.

Buscaremos aquella cuya línea sea Directory /var/www y cambiaremos la opción AllowOverride None por AllowOverride All. Guardaremos la configuración y procederemos a reiniciar el servicio apache.

En las imágenes siguientes se ve el antes y el después de la configuración.

Con estos pasos el mod rewrite estará activo y configurado.

¿PHP está instalado y configurado?

Si hemos llevado a cabo los pasos anteriores para saber si el mod rewrite estaba activo, y lo hemos encontrado en el archivo info.php, entonces es que tenemos PHP bien instalado.

En caso que no hayamos logrado entonces deberemos instalar el módulo PHP en nuestro servidor.

Para hacer esta tarea usaremos nuevamente la consola (shell) para hacer la instalación.

La instalación varía un poco entre distribuciones de servidor, pero haremos la instalación pensando en algún derivado de debian (como si fuéramos root)

apt-get install libapache2-mod-php php

Una vez que la instalación haya finalizado necesitaremos reiniciar el servicio web (como root)

service apache2 restart

Si tenemos aún el archivo info.php, pues lo abriremos desde el navegador (normalmente http://localhost/info.php)

Si logramos ver el resultado de nuestro archivo, entonces ya tendremos claro que PHP está activo en nuestro servidor.

¿El servidor de bases de datos está activo?

Si usamos MySQL o MariaDB bastará con intentar hacer login con la cuenta que tenemos en la configuración de nuestra aplicación desde la consola.

mysql nombredelabasededatos -u miusuario -p

Digitamos la contraseña y presionamos enter para lograr acceso.

Si nos da un error como el que se ve en la imagen siguiente es porque el servicio no está activo.

Para activarlo deberemos ejecutar un comando como el que sigue desde la consola (como si fuéramos root):

service mysqld start

Si ahora logramos acceso y todo va bien, es decir, logramos conectarnos al servidor mysql, sería bueno saber si tenemos acceso a la base de datos que usará la aplicación.

Para eso, estando en la consola interactiva de mysql, escribimos el comando use mibasededatos; (donde mibasededatos es el nombre de la base de datos que está configurado en el archivo database.ini) seguido de punto y coma. Y presionamos enter.

Nos debe aparecer un mensaje como “database changed”.

Seleccionamos alguna de las tablas del sistema (podemos listarlas usando el comando show tables;), y escribimos alguna instrucción y le ejecutamos, por ejemplo;

<span class="token keyword">SELECT</span> <span class="token operator">*</span> <span class="token keyword">FROM</span> tablaseleccionada<span class="token punctuation">;</span>

Si todo ha ido bien, ya podemos pasar al siguiente punto.

¿La cuenta en el servidor de bases de datos es la que corresponde en la configuración de nuestra aplicación?

Bueno, en el punto anterior ya hemos realizado esta prueba usando el comando:

mysql nombrebasedatos -u usuario -p

Si esto no resulta, será necesario crear un usuario de mysql con los permisos necesarios sobre la base de datos correcta. Para eso te recomendamos leer el siguiente artículo que ya explica muy bien cómo lograr esta labor.

https://www.digitalocean.com/community/tutorials/crear-un-nuevo-usuario-y-otorgarle-permisos-en-mysql-es

¿Hemos trasladado todos los cambios desde el servidor de bases de datos de desarrollo hacia el servidor de producción?

A veces el error se produce porque tenemos tablas en el servidor de desarrollo que no hemos pasado al servidor de producción o porque alguna de las tablas de producción no tiene atributos (campos) nuevos que sí hemos estado usando en desarrollo. Hacer una revisión de las estructuras de las tablas será de gran ayuda si comparas cómo es el estado en ambos servidores.

¿Nuestra aplicación tiene los permisos bien configurados?

Si hemos leído los artículos de la wiki, y hemos comprobado que los permisos son los correctos, sólo nos quedará pasar al siguiente punto.

¿Hemos copiado completamente la aplicación desde el servidor de desarrollo (incluidos todos los archivos ocultos)?

Por obvia que parezca la pregunta, resulta que en ocasiones el cliente que usamos para copiar los archivos, omite los archivos ocultos que comienzan en punto (los dot files). En KumbiaPHP se usan varios archivos que comienzan en punto, y aunque todos se llaman igual, cada uno cumple una misión diferente dependiendo del lugar en el que esté alojado. Este archivo es el .htaccess.

Personalmente la forma que más me resulta para lidiar con este problema es comprimir el sitio, copiarlo comprimido al servidor de producción y luego descomprimirlo en él. Si esto no fuera posible (porque por ejemplo no tienes acceso a la shell o si el panel web de administración no provee de gestión de archivos), toma en cuenta que el cliente de ftp que uses lleve todo lo que necesitas al servidor de producción.

¿Hemos configurado correctamente la constante PUBLIC_PATH?

Aunque también es parte de lo que se habla en los artículos escritos y mencionados de la wiki, uno de nuestros colegas ha escrito un artículo interesante sobre este tema y el siguiente en el blog de KumbiaPHP https://www.kumbiaphp.com/blog/2018/07/31/no-input-file-specified-arreglar-el-error/

¿Podemos usar PATH_INFO o necesitamos cambiar la estrategia de generación de URL?

Al igual que el punto anterior, nuestra recomendación es leer el artículo que ya se mencionó en él.

Si estamos completamente a ciegas, ¿hemos activado la visualización de errores?

Si el servidor no nos da información alguna sobre el error, podemos aprovechar una configuración especial que está alojada dentro del archivo default/public/index.php para activar el registro de los errores y permitir visualizarlos directamente en el navegador web.

Para eso iremos archivo mencionado (default/public/index.php) y buscaremos la línea:

//error_reporting(E_ALL ^ E_STRICT);ini_set('display_errors', 'On');

Y le quitaremos los comentarios iniciales, es decir, los dos primeros caracteres iniciales //

Adicionalmente debemos asegurarnos que KumbiaPHP no esté en modo producción, así que en el mismo archivo default/public/index.php verificamos que la constante PRODUCTION sea igual a false:

const PRODUCTION = false;

Esto hará que las excepciones que ocurran sean mostradas en pantalla evitando la redirección a la página de error 404, que es comportamiento por defecto de KumbiaPHP cuando está en producción.

Con eso ya tendremos alguna idea a partir de la presentación de los errores en pantalla.

Existe una forma extra de visualizar errores, pero para ello hay que tener acceso al servidor en modo consola (shell) y tener acceso al log de errores del servidor web (apache generalmente). Normalmente este archivo se aloja en /var/log/apache2/error.log

Si se tiene acceso a él, usar el comando tail -f error.log será de gran utilidad pues cada vez que recargues tu navegador, los errores se verán reflejados en tu terminal. Los mensajes que recibas serán de gran utilidad al momento de buscar posibles soluciones, o para pedir apoyo a algún colega.

El sitio presenta un error ERR_TOO_MANY_REDIRECTS al cargarlo

Si a pesar de haber eliminado los archivos de la caché este error persiste es momento de revisar nuestra rutina de autenticación. En ocasiones la implementación de la gestión de la sesión del usuario nos puede causar algunos dolores de cabeza, y el consejo aquí es verificar la forma en la cual se lleva a cabo las redirecciones cuando un usuario no tiene los privilegios necesarios y requiere de autenticación. Hay diferentes formas de llevar a cabo la autenticación, pero siempre vale la pena consultar alguna forma que ya haya sido probada. Para tales efectos les recomendamos leer http://wiki.kumbiaphp.com/Beta2_Sistema_de_Login o también https://soyprogramador.liz.mx/implementando-logueo-en-kumbiaphp/ como elementos formativos. Te dejamos como tarea extra mirar código de otras personas. Puedes hacer una búsqueda en github con la palabra clave kumbiaphp.

Una recomendación final

Si hemos pasado de PRODUCCION = true a false y viceversa, es necesario recordar eliminar el contenido de la carpeta de cache que genera KumbiaPHP cuando estamos en modo producción. Para ello iremos a la carpeta default/app/temp/cache y borraremos su contenido para evitar que no logremos visualizar los errores porque el framework está presentando los contenidos “cacheados” en vez de las vistas reales.

Con todo esto, te deseamos lo mejor y mucho ánimo cuando te encuentres con un problema, pues recuerda que resolverlos es parte de nuestro aprendizaje y nuestra labor como desarrolladores.

Un abrazo cordial,

El equipo de KumbiaPHP

La entrada Errores comunes al subir web o aplicación php a producción se publicó primero en KumbiaPHP Framework PHP en español.

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.

En esta ocasión vamos a hablar de un tema  bastante sencillo, y que tiene que ver con ayudar un poco a la decisión qué herramienta es la más efectiva, eficiente y se acomoda más a las necesidades del desarrollador.

Todos sabemos lo rápido que resultan las aplicaciones hechas con KumbiaPHP, pero cuando empiezas cuesta un poco sacarle el provecho necesario a las horas de trabajo, y te pierdes en búsquedas de documentación, paseos por los foros, consultas en el grupo de google, etc.

¿Hay algún tipo de secreto o algo que nos pueda ser de utilidad?

En este sentido tenemos dos opciones: la primera es usar un IDE para PHP, o usar un editor de texto sobrecargado (con extensiones)

Bueno, ¿qué IDE y editor de texto puedes usar?

Por el lado de los IDE están los gratuitos como Netbeans, Eclipse, Aptana. También los hay de pago como PHP Storm, Zend Studio, Komodo IDE.
En la vereda de los editores de texto, la lista comienza con Komodo Edit, Atom, Visual Studio Code, Notepad++, Brackets, Sublime Text, Vim, Gedit, TextMate, Text Wranger, etc.

¿Y entonces, cómo me decido por uno u otro?

El mayor beneficio de un IDE es que con el sólo hecho de cargar tu proyecto tendrás acceso a autocompletado de código;  ayuda con clases, métodos, propiedades; herramientas como formateadores, snippets (trozos de código); resaltado de errores y ayuda para corregirlos. Ahora, no todo es beneficio con un IDE pues tendrás que sacrificar algo – como dice la ley del intercambio equivalente – tendrás que ceder en memoria RAM y procesador. Los IDE normalmente están basados en Java, y, por lo tanto no corren en código nativo (la mayoría)

¿Y los editores de texto?

Un editor de texto tiene la particularidad de ser en extremo liviano en cuanto a memoria RAM, pero sólo es eso, un editor de texto. Tendrás que agregar extensiones especiales para darles algo de funcionalidad extra y mejorar así tu tiempo de desarrollo y tu curva de aprendizaje.Recuerdo bien que alguna vez usé Atom, y haber creado “recortes de código php” para labores como crear CRUD, Controladores, Modelos, e incluso lanzar los Helpers de la clase Form con autocompletado. No es complejo construir tus propios recortes de código.

Y entonces, ¿qué sigue en este post?

Lo cierto es que vamos a crear entre todos diferentes post para ir mostrándoles cómo usar IDE o editores de texto recargados. Ya tenemos el de NetBeans IDE. Nuestro colega Raúl (@demonio69) seguirá con la serie con el uso de Komodo Edit. Y espero acompañarlo luego con Eclipse para la próxima entrega.

Para cerrar, así se ve Netbeans en acción y Komodo Edit configurado con las librerías del core de KumbiaPHP.

Serie de artículos:

NetBeans IDE

La entrada Programar código PHP ¿IDE o editor de Texto? se publicó primero en KumbiaPHP Framework PHP en español.

Esta semana tenemos un vídeo dedicado a los conceptos básicos de KumbiaPHP. Los vídeos son parte de una serie para compartir conocimiento y algunas prácticas que tenemos los desarrolladores que usamos este fabuloso framework.

Pueden descargarse los slides aquí: KumbiaPHP Essentials

Próximas semanas:

• • Scaffolding, CRUD fácil y en pocas líneas.
  • CRUD con KumbiaPHP (Create, Read, Update, Delete)
  • ActiveRecord Essentials
  • Templates (Bootstrap, Picnic, Foundation)
  • Autenticación
  • Uploads
  • Control de Acceso con ACL

La entrada Vídeo KumbiaPHP Essentials se publicó primero en KumbiaPHP Framework PHP en español.