¿Te has preguntado alguna vez cuáles son los pases para desarrollar un módulo en PrestaShop? ¿Te encantaría saber programar pero no sabes por donde empezar? Hoy, te cuento mis primeras experiencia con PrestaShop. No te lo pierdas.
Soy informático y programador web. Desde pequeño siempre me ha gustado ya no resolver problemas sino encontrar soluciones sencillas y prácticas a problemáticas resueltas anteriormente... Se puede decir que me gusta mi trabajo y le dedico bastantes horas de mi vida aún después de acabar la jornada (uno nunca podrá decir que lo sabe todo).
He estado 10 años trabajando en el mundo web que rodea a java y ponerse de cero con php y Prestashop no me resultó complicado, pero hay que dedicarle tiempo para lograr familiarizarte y llegar a dominar y conocer todas las clases, controladores, etc... Es como tirarte 10 años tocando un sólo coche y, de repente coger otro. Sabes para qué sirve cada pedal y aunque consigues que el coche haga lo que quieres, eres consciente de que te cuesta dominar un poco su funcionamiento (el embrague está más duro, o más blando, o las marchas son más cortas o más largas...) y no te sientes tan seguro como estarías en tu viejo coche.
Recuerdo que antes de hacer mi primer módulo serio para Prestashop (que por cierto fue para Alabaz , se llama megacanones y me siento muy orgulloso :)), tuve que hacer varios módulos sencillos para realizar pruebas en base a lo que iba aprendiendo (instalación, traducciones, hooks, clases, controladores, overrides...). Me basaba sobre todo en los manuales de Prestashop y en el código que iba encontrando en los otros módulos según el tema que iba investigando (por cierto, viva el código abierto, es la mejor manera de aprender y creo que es por la principal razón por la que se creó).
Una vez ya ves que el “coche” parece que funciona, entonces ya te dedicas al planteamiento real del módulo que de verdad se desea hacer.
Previamente, tiene que haber una toma de requerimientos y estar plasmada sobre papel, lo típico que se realiza cuando se entrevista a un famoso (qué, cómo, cuándo...) sólo que en este caso para nuestro módulo. Sería algo así como los planos donde mirar en caso de ver que la torre se tuerce. Sobre todo, hay que tener bien claro cuál es la finalidad del módulo, qué procesos debe de realizar para llegar a ello, qué datos recibe y cuáles y cómo son sus resultados (base de datos, pantalla...).
Posteriormente, es posible que se vayan añadiendo más requerimientos o se vayan corrigiendo ciertas puntualizaciones de ellos, pero ya hay una base sobre la que ponerse a trabajar y siempre sern modificaciones pequeñas.
Siguiendo con el módulo de megacánones , un ejemplo de esta toma de requerimientos sería la siguiente (un poco resumida):
1.- Un canon es un incremento en el precio del producto. Este incremento, puede estar incluido en el precio que se visualiza o incluirse después. Además debe de poder tener la opción de añadirle un impuesto. El canon además debe de contener un texto que lo defina. (este punto es el más claro para saber qué datos de entrada necesitamos)
2.- El canon debe de estar visible en el momento de la compra y debe de añadirse junto al producto al realizar la compra, visualizándose que se ha añadido junto con el producto tanto en el carrito como en el checkout para que el cliente sea consciente en todo momento de lo que está pagando (en este punto se reflejan los procesos que realizan los datos introducidos).
3.- Además debe de salir en la factura, en el email y en el pedido (este último punto refleja bastante bien el tema que comentaba del qué y el cómo de los resultados, pues hay tres formas diferentes de plasmarlo).
Aún no hemos empezado a tocar código para hacer nuestro módulo y ya hay en el deber de nuestra planificación varias horas empleadas... Y las que faltan, pues antes es conveniente realizar un estudio exhaustivo (plasmándolo en papel también) de:
Una vez hemos aclarado estos puntos, simplemente hay que añadir al documento que estamos realizando nuestro propio estudio de lo que vamos a realizar. En esta fase, ya estamos analizando los puntos críticos desde nuestra perspectiva y conocimientos y, por tanto, definiremos la solución más factible para realizar cada una de las funcionalidades; ya sea enganchar a un hook, realizar un override... o simplemente definir nuestras propias clases y los datos contenidos en ellas (sin desarrollarlas claro).
Por ejemplo (sin llegar a aspectos muy técnicos), en el módulo de megacanon que os comentaba se podría identificar lo siguiente:
Este último estudio siempre será muy personal, pues cada desarrollador tiene sus preferencias y sus metodologías (aunque algunas no sean lo más correctas), y siempre habrá alguien que lo vea y diga - “yo lo haría así” . Por supuesto, debemos estar abiertos a opiniones, gustos e incluso a cualquier comentario, pues es posible que todo esto nos ayude a mejorar o ver una problemática con la que no habíamos contado. Por ejemplo, yo no soy partidario de sobreescribir plantillas smarty (tpl) ya definidas por prestashop; aunque en parte, es la forma más fácil y en tiempo no nos costaría apenas, pero estamos un poco pillados y limitados ante cualquier modificación de esta plantilla de manera externa.
Un ejemplo claro de lo que comento es la visualización del canon en el carrito, en el cual la forma más sencilla, era sobreescribiendo la plantilla relacionada y añadirle dos o tres simples líneas en las que salía el canon y su importe. Al final, y como he dicho, debido a mi forma de pensar (seguro que alguien hubiese optado por la otra opción), aproveché un hook que tenía ya definido para hacerlo todo por javascript, cosa que me hizo escribir más código e incluso dobló considerablemente mi esfuerzo y mi tiempo; pero mi objetivo no era acabar antes, sino independizar esta parte un poco de prestashop.
Todo esto que a priori parece una pérdida de tiempo, nos facilitará mucho a posteriori la programación del módulo pues estamos plasmando sobre el papel aquello que vamos a tocar/crear posteriormente. Evidentemente, es posible que en el momento del desarrollo en sí, nos encontremos con alguna problemática o duda que no nos habíamos planteado, y nos veamos obligados a variar parte de los requerimientos y/o del planteamiento para poder solucionar esta problemática. Pero os garantizo que siempre será una problemática pequeña en comparación con cualquier otra forma de programar (la de ensayo-prueba-error está bien cuando se está aprendiendo pero después su uso pierde efectividad cuando ya se domina un poco el sistema).
He intentado no llegar a tecnicismos pues quiero que este post sea leído ya no por informáticos, sino por personas que les gusta este mundo de Prestashop y les pica el interés y la curiosidad de poder dar un paso más.
Espero vuestros comentarios.
Un saludo,
Este módulo nos permite la asignación de cánones u opciones extras a nuestros productos de Prestashop, configurándolos por completo en función de nuestras necesidades y las de nuestros productos.
Ver pantallas
Escribe un comentario