He escrito muy poco sobre este proyecto. ¿Acaso ya me libré de él? ¡JA JA JA JA JA! No.
Aunque afortunadamente sí que me han ido asignando otros proyectos más emocionantes y de mi gusto, y la balanza se está equilibrando a mi favor. Después de una agradable pausa, con alguna incidencia leve por el camino, el compañero que más sabía de este proyecto se marcha de la empresa. ¿A quién le toca ahora cuidar de él? ¡JA JA JA JA JA! A mí.
Sin embargo el project manager sabe lo caótico que es este proyecto. Así que, no solo no me deja solo ante el peligro, sino que me ha asignado a dos "ayudantes", que llevan algo más de tiempo que yo.
Muy pronto empezaremos otra fase, bastante revolucionaria (para bien de todos), y me ha encargado que vaya instruyendo y dirigiendo a estos ayudantes mientras trato de poner orden en el núcleo. De alguna manera, he subido de categoría. (Y de sueldo, afortunadamente, aunque no tuviera ninguna relación)
El presupuesto no permite cambiar radicalmente todo el código para que, al menos, sea inteligible. Pero haré lo que pueda allá por donde paso, para evitar que las futuras generaciones sufran tanto como yo.
Pero no se preocupen; en algún momento volveré para seguirme desahogando. ¡JA JA JA JA JA! O eso creo.
lunes, 12 de febrero de 2018
martes, 6 de febrero de 2018
Pesadilla en Laravel Street, capítulo 2
Seguimos con mis pequeños y potencialmente terroríficos desahogos.
Terminé el capítulo anterior contando sobre la "autogeneración" de campos en create y edit. Utilizando algo así de relativamente genérico, ¿qué se hace con los datos recibidos a la hora de guardarlos?
Las funciones store y update siguen ahí, por supuesto. En muchos casos debería bastar con llamar al modelo, y usar Eloquent para un create o un update de los de toda la vida. Como mucho, meter un práctico validate() nada más empezar.
¿Para qué? Eso no es lo bastante genérico. Para cada controlar vamos a inventar dos tipos propios de Request. La mayoría de estos Requests no van a contener nada, pero vamos a crearlos, por si acaso
Cada uno de estos Requests contendrá al menos una mención a las reglas de validación. Estas se encuentran como una propiedad estática del modelo correspondiente.
Pero bueno, así tenemos no estamos repitiendo la validaciones en varias funciones. Algo es algo. Ahora vamos a guardar usando las funciones de Eloquent.
¿Para qué? Eloquent es muy mainstream. Me voy a inventar un Repositorio para cada modelo. Este contendrá, entre otras cosas, una función de búsqueda. Esta coge la tabla, cuyo nombre se especifica manualmente (???), y genera un listado de todas sus columnas (???). También controlamos excepciones en caso de que no encuentre tal registro, devolviendo la conocida excepción HTTP nº 1001 (???).
Suficiente por hoy. No quiero que me venga otra jaqueca hoy.
Terminé el capítulo anterior contando sobre la "autogeneración" de campos en create y edit. Utilizando algo así de relativamente genérico, ¿qué se hace con los datos recibidos a la hora de guardarlos?
Las funciones store y update siguen ahí, por supuesto. En muchos casos debería bastar con llamar al modelo, y usar Eloquent para un create o un update de los de toda la vida. Como mucho, meter un práctico validate() nada más empezar.
¿Para qué? Eso no es lo bastante genérico. Para cada controlar vamos a inventar dos tipos propios de Request. La mayoría de estos Requests no van a contener nada, pero vamos a crearlos, por si acaso
Cada uno de estos Requests contendrá al menos una mención a las reglas de validación. Estas se encuentran como una propiedad estática del modelo correspondiente.
Pero bueno, así tenemos no estamos repitiendo la validaciones en varias funciones. Algo es algo. Ahora vamos a guardar usando las funciones de Eloquent.
¿Para qué? Eloquent es muy mainstream. Me voy a inventar un Repositorio para cada modelo. Este contendrá, entre otras cosas, una función de búsqueda. Esta coge la tabla, cuyo nombre se especifica manualmente (???), y genera un listado de todas sus columnas (???). También controlamos excepciones en caso de que no encuentre tal registro, devolviendo la conocida excepción HTTP nº 1001 (???).
Suficiente por hoy. No quiero que me venga otra jaqueca hoy.
Laravel DataTables 5
Hablemos de filtros y buscadores, características estrella en DataTables.
Como ya habremos observado nada más aplicar DataTables por primera vez en jQuery, en la esquina superior derecha de la tabla se puede ver un campo de búsqueda. Al escribir en él, inmediatamente filtra la tabla, mostrando solo las filas que contengan esos caracteres en cualquier columna.
En el modo server-side la búsqueda también la realiza mediante llamadas al servidor. El propio Laravel DataTables se encarga de recoger esos parámetros y aplicar los WHEREs necesarios. En estos WHEREs, como ya expliqué en el capítulo anterior, utilizará el campo indicado en Javascript como name.
Todo esto va bien para la mayoría de casos. Pero la programación sería muy aburrida si no hubieran casos especiales, ¿verdad?
Para estos casos especiales, en los que la información visible en la tabla no es exactamente igual a cómo está guardada en la base de datos, en Laravel DataTables tenemos el método filterColumn.
El ejemplo más típico serían las fechas. En la web mostramos 30/01/2018, pero en la base de datos puede estar guardado como 2018-01-30, o como 1517310949. Para esto... la verdad es que es complicado. De momento he conseguido con un plugin para jQuery DataTables, pero ha requerido unos cuantos trucos en ambos lados para buscar por rango de fechas. Esto me lo reservo para otro capítulo.
Otro ejemplo habitual serían las columnas de Nombre y de Apellidos. Es muy normal guardar estos datos por separado, pero mostrarlos como si fueran una columna. Puede ser uniéndolos directamente en la query (CONCAT(`nombre`, " ", `apellidos`) AS `nombre_completo`) y metiendo el nombre de este alias como name en Javascript. En tal caso filterColumn deja de ser necesario.
Otra manera, la que vemos en la documentación oficial, es inventando el mismo alias dentro de filterColumn.
Es posible que me haya explicado fatal. Lo siento; es la primera vez que escribo documentación sobre algo así. ^_^u
En el próximo capítulo voy a improvisar un ejemplo, y exponerlo todo de manera más práctica.
Como ya habremos observado nada más aplicar DataTables por primera vez en jQuery, en la esquina superior derecha de la tabla se puede ver un campo de búsqueda. Al escribir en él, inmediatamente filtra la tabla, mostrando solo las filas que contengan esos caracteres en cualquier columna.
En el modo server-side la búsqueda también la realiza mediante llamadas al servidor. El propio Laravel DataTables se encarga de recoger esos parámetros y aplicar los WHEREs necesarios. En estos WHEREs, como ya expliqué en el capítulo anterior, utilizará el campo indicado en Javascript como name.
Todo esto va bien para la mayoría de casos. Pero la programación sería muy aburrida si no hubieran casos especiales, ¿verdad?
Para estos casos especiales, en los que la información visible en la tabla no es exactamente igual a cómo está guardada en la base de datos, en Laravel DataTables tenemos el método filterColumn.
El ejemplo más típico serían las fechas. En la web mostramos 30/01/2018, pero en la base de datos puede estar guardado como 2018-01-30, o como 1517310949. Para esto... la verdad es que es complicado. De momento he conseguido con un plugin para jQuery DataTables, pero ha requerido unos cuantos trucos en ambos lados para buscar por rango de fechas. Esto me lo reservo para otro capítulo.
Otro ejemplo habitual serían las columnas de Nombre y de Apellidos. Es muy normal guardar estos datos por separado, pero mostrarlos como si fueran una columna. Puede ser uniéndolos directamente en la query (CONCAT(`nombre`, " ", `apellidos`) AS `nombre_completo`) y metiendo el nombre de este alias como name en Javascript. En tal caso filterColumn deja de ser necesario.
Otra manera, la que vemos en la documentación oficial, es inventando el mismo alias dentro de filterColumn.
->filterColumn('nombre_completo', function($query, $clave) {
$sql = "CONCAT(`nombre`, " ", apellidos) LIKE ?";
$query->whereRaw($sql, ["%{$clave}%"]);
})
Es posible que me haya explicado fatal. Lo siento; es la primera vez que escribo documentación sobre algo así. ^_^u
En el próximo capítulo voy a improvisar un ejemplo, y exponerlo todo de manera más práctica.
Suscribirse a:
Entradas (Atom)