Pesadilla en Laravel Street, capítulo 1

Voy a hablar un poco de mi trabajo, con permiso.
Casi llevo un año aquí, y hace pocas semanas heredé cierto proyecto gordo. Uno de los más importantes de la empresa. Un CRS que no para de crecer. Mi reacción fue agridulce, pues ya me habían hablado de este proyecto anteriormente, notablemente mal. Pero todavía no entendía por qué. Pronto empecé a sentirme así: http://www.commitstrip.com/en/2016/02/15/our-companys-greatest-project/

El proyecto en sí no es viejo. Por no decir que está basado en Laravel. El problema es que su primer programador (que ya no se encuentra entre nosotros) o no entendía Laravel, o no le gustaba nada. Era un veterano muy acostumbrado a una plantilla de back-ends en PHP nativo, propia de la empresa. Todavía se utiliza de vez en cuando en proyectos sencillos.

Esta plantilla tiene páginas y librerías comunes, listas para generar nuevas páginas fácilmente en base a los campos de cualquier tabla de la base de datos. Para que funcionase a la primera había que seguir una serie determinada de convenciones y reglas. Sino, tocaba apañar parches con Javascript, o muchos IFs en el núcleo.
Cuando el primer programador empezó, se empeñó en replicar esa funcionalidad, ignorando lo que Laravel podía hacer para simplificar el proceso y dejarlo limpito.

Para empezar, lo normal en un sistema CRUD de los de toda la vida es aprovechar el sistema de plantillas de Laravel, perfectamente anidables, y generar vistas para index, create, edit y show. Cada una tendría sus campos necesarios, sus validaciones, etc.
¿Para qué? Dejemos solo una vista para el index de cada sección, que recoga un par de parámetros, y el resto que venga de plantillas. Para cosas más complicadas pues sí, habrá que empezar de cero.

Pero vaya, no sé cómo leer automáticamente en Laravel qué campos tiene esta tabla en la base de datos, ni de qué tipo son, para utilizarlos en el create y en el edit. Podría de alguna manera añadir esta información en su respectivo modelo...
¿Para qué? Voy a inventarme una función en cada controlador, donde listar los campos para mostrar. En cuanto a los tipos... Me inventaré un helper, al cual le pido el tipo de campo, y me devolverá el input HTML necesario. Así es como lo hacíamos antes, más o menos. :-D

Seguiré en otro capítulo. Tengo para rato.