Meetup «Ventajas y desventajas de Sylius como solución e-commerce PHP»

Meetup «Ventajas y desventajas de Sylius como solución e-commerce PHP»

A english version of «Advantages and disadvantages of using Sylius as PHP e-commerce solution» is available at the end of the post.

Introducción

La semana pasada organizamos nuestro primer evento dentro del grupo de Meetup de Sylius. Antes de nada, agradecer la presencia de todas las personas que nos brindaron de su tiempo, vinieron a nuestras oficinas y aportaron sus puntos de vista enriqueciendo el evento, esperamos que pasaran un buen rato y se fueran con nuevos conocimientos y ganas de volver.

A modo de introducción, Sylius es, y cito la definición que aparece en su página web, «el primer framework adaptado a soluciones e-commerce». Desarrollado sobre Symfony y siguiendo los mejores estándares de calidad, contiene una serie de bundles que trabajan conjuntamente para facilitar el desarrollo de aplicaciones de comercio electrónico para programadores que estemos familiarizados con Symfony.

Sylius lanzó recientemente su primera versión (aunque ya lleva un tiempo entre nosotros en forma de beta), y nosotros decidimos realizar el primer proyecto con él para ver cómo es la experiencia, y aunque puede ser tema de otro post, adelantaré que ha sido un desarrollo muy interesante donde hemos aprendido y mejorado, y aunque aún es un MVP, os invitamos a que visitéis nuestro proyecto de cursos y formación: gravita.academy.

El evento

Volviendo al evento del grupo de Meetup, una vez más adoptamos el formato de mecánica Lean Coffee, que se adaptó bien en nuestro anterior evento, así que tras la ronda de presentaciones, dispusimos unos minutos para saber qué temas trataríamos durante la hora/hora y media que duró el debate, siguiendo un timebox marcado de 5 minutos con votación silenciosa de si seguíamos con el tema o pasábamos al siguiente.

 

Resultado del Lean Coffe

Temas que todos quisimos tratar

Temas

Temas priorizados

Temas tras la votación priorizados

Tras realizar la votación y priorización, hablamos sobre los siguientes temas:

¿Cómo va la generación de temas?

Una de las grandes ventajas que tienen otras soluciones de e-commerce son sus tiendas de temas, la facilidad de implantación y las ventajas que aportan con el consecuente ahorro de tiempo por la funcionalidad que tiene. Sylius tiene su propia página de temas y es interesante saber cómo desarrollar nuestro propio tema. Explicamos entonces nuestra experiencia desarrollando nuestro primer tema para nuestra tienda.

¿Disponemos de API para aplicaciones?

Con la división que estamos viviendo entre la parte frontoffice y backoffice de nuestras aplicaciones, surgió la duda de si el framework estaba preparado para que existiera una forma fácil de entablar comunicación si desarrollamos aplicaciones cliente con frameworks javascript como React, Angular, etc. La respuesta es que Sylius nos provee de las operaciones CRUD de nuestras entidades a través de una API si seguimos su forma de trabajar, además de permitirnos el uso de OAUTH ante operaciones que queremos blindar.

¿Qué ventajas tenemos con respecto otros frameworks?

Entramos en la comparación directa con soluciones que ya están más que consolidadas en el desarrollo de plataformas e-commerce. Aquí hablamos sobre nuestra experiencia, qué echamos de menos (YOAST SEO…), y las ventajas comparadas con los demás (disponemos de una base de código de muy buena calidad).

¿Cómo se integra con otros bundles (FOSUserBundle, SonataAdminBundle, …)?

Una de las grandes dudas es si el conjunto de la aplicación que desarrollemos dejará de funcionar en caso de sustituir o integrar otro Bundle externo. Una de las grandes ventajas de Sylius es la modularidad de la que dispone. Nos permiten trabajar con cualquiera de los bundles de los que se forma de manera individual para soluciones que no tienen por qué ser una tienda, además de poder sustituir uno de sus bundles por otro que deseemos, pero como siempre, con posterior trabajo de adaptación y seguramente pérdida de automatización por el camino.

¿Cómo configuramos despliegues automáticos?

La automatización del pase a los distintos entornos de nuestras aplicaciones siempre es un tema que suele ser interesante. Aquí describimos un poco nuestra experiencia al integrar, configurar dentro del proyecto el EasyDeployBundle, que es la alternativa que estamos usando tras pasar por Capifony y Deployer. Surgió también la necesidad de disponer de un modo de puesta en mantenimiento de Sylius.

¿Es fácil editar el proceso de compra?

Es algo muy común que desde el cliente nos soliciten que todo el proceso de compra se realice en un paso, o tener que adaptar nuestras aplicaciones a las distintas formas de pago y/o configuración de distintos TPV de bancos. El proceso de configuración básica para la puesta en marcha de una tienda es fácil gracias a que Sylius integra el PayumBundle.

 

¿Qué tal la comunidad? ¿Tendrá versiones LTS garantizadas?

Lamentablemente, no dio tiempo a tratar este tema, pero consideramos que es algo muy interesante que estaría bien discutir. Invitamos en cualquier caso a quien quiera que comente en este post.

 

Próximos pasos: Talleres

A modo de conclusión del evento, solicitamos a los presentes que decidieran el formato del siguiente evento (charla, debate, taller…), y el tema del que le gustarían que tratase, así que cada uno escribió en un post-it su apuesta para no influir en la opinión de los demás, y más tarde, entre todos, realizamos una votación para acordar el tema:

Claramente, existía una alineación en el formato, y tras la votación, acordamos que el siguiente evento será un taller sobre cómo desarrollar nuestro primer tema en Sylius.

Si quieres estar al tanto de próximos eventos y quieres formar parte del grupo, aquí tenéis el enlace del Meetup para poder registraros.

 


Meetup «Advantages and disadvantages of using Sylius as PHP e-commerce solution»

Introduction

Last week we had our first Sylius’s Meetup event. In order to introduce Sylius, is, and I only copy and paste the definition from his web, «The first framework for tailored e-commerce solutions». Developed over Symfony and following the best quality coding standards, Sylius contains bundles that works together to make easy the development of e-commerce applications for developers that are familiar with Symfony.

Sylius’s guys just launched his 1.0.0 version (although Sylius have been a long time between us as beta), so we decided to develop our first project using it, and, even though it is material for another post, the first impressions are very good. The development process was very interesting and we’ve learned and improved our skills, and, though is an MVP yet, we invite you to visit our learning and courses platform project: gravita.academy.

 

The event

Returning to the Meetup’s event, another time we use the Lean Coffee format that fits very well in our last event, so, after the presenting round, we let a bit of minutes to know what topics people want to talk about the hour / hour and half that remains of the event, so following a 5 minutes timebox with simple vote about if we discuss about the next topic or continuing with the current topic.

Lean Coffee topics

Lean Coffee topics that people wanted to discuss

 

Topics

Temas priorizados

Prioritized topics after the vote

After voting and prioritization, we talked about the next topics:

How about theme management?

One of the advantages of other e-commerce solutions are his themes shops, the ease of implantation and the shortion of cost for functional development. Sylius has his own theme page and is interesting to know how to develop a custom theme. We talked about our experience developing our first theme for our shop.

Is there an API for client applications?

Some of we are used to develop client side applications with JS Frameworks like React, Angular, etc., and they wonder about if Sylius manages this communication. The answer is that Sylius allows to use CRUD operations of our entities if we work following the Sylius’s way. In addition, we have OAUTH for secure API functions.

What advantages has Sylius against other frameworks?

We put Sylius in front of other e-commerce solutions. Talked about our experience, what we would like to have in Sylius (YOAST SEO…), and the advantages compared with the others (we will have a great quality base code using Sylius).

 

How works other bundles integration (FOSUserBundle, SonataAdminBundle, …)?

One of greatest doubts is about the functionally lost in case we change or integrate third party Bundles in Sylius. One of the greatest advantages of Sylius is the modularity. We can use individually each Sylius bundle in our projects even if it’s not a shop. Also, we can change one of them with other of our preference, but like always, we need to adapt it a bit, losing part of its automatization.

How we automatize the deploy?

The deploy’s process automatization to each environment always is an interesting topic. Here we described a bit our experience installing and configuring the EasyDeployBundle inside our Sylius’s project, the tool we’re using after try Capifony and Deployer. We talked about the needs of a «maintenance mode» in Sylius too.

 

Is easy to edit the checkout?

Is ordinary that our clients needs to change the default checkout process, for example, using one step checkout, or to make our applications capable of using a variety of payment methods and / or setup any bank payment gateway. The basic configuration process for a standard shop is easy thanks to Sylius’s PayumBundle integration.

 

How about the community? Will exists an LTS version?

Although this is a great topic to discuss, we finished the meetup time without talk about it. But we invite to comment on the post to anyone.

 

Next steps: Workshop

At the end of the event, we asked everyone to decide the next event format (talk, discuss, workshop…), and the topic they would like to learn, so everyone wrote in a post-it his bet to not change the thoughts of the others, and later, between all, voted his preferences:

We can see everyone was interested in a workshop, and the votes made the topic will be about how to develop our first theme in Sylius.

If you are interested in next events and want to be part of the group, here is the link to Meetup.

Meetup «Los retos de la comunidad Symfony»

Introducción

Antes de nada, sería pertinente comenzar por el por qué del grupo. Recientemente nos planteamos la certificación de Symfony para los desarrolladores de nuestra empresa, y en la documentación de los pasos a seguir, vimos que desde la página de academia de Sensiolabs tenían con frecuencia cursos y talleres de preparación, en Francia, Londres y Alemania. Cuando les preguntamos sobre la posibilidad de realizar la formación aquí en España al igual que en otros países, la respuesta que obtuvimos es que no hay tanta gente que lo solicite, por lo que no se lo plantean.

Queremos conseguir que todos los desarrolladores de Symfony que lo deseemos tengamos la posibilidad de tener un espacio en el que discutir inquietudes, apoyarnos y mejorar, sin tener que esperar a grandes eventos anuales como el deSymfony o Codemotion para ello, y por esas razones, creamos el grupo de Symfony.

Un poco de contexto

El pasado jueves tuvimos la suerte de poder organizar nuestro primer meetup, «Los retos de la comunidad Symfony«, y desde aquí quiero agradecerles a todos los asistentes que nos brindaron su tiempo. Desde el principio queríamos desmarcarnos de la clásica master class, que aunque no tiene nada de malo, no se ajustaba tanto a nuestra idea de generar comunidad en torno a Symfony, queríamos romper el hielo entre los participantes (que no oyentes), y queríamos debate.

 

Los retos de la comunidad Symfony

Como adelantaba antes, queríamos que el meetup fuera algo más comunicativo, que todos los presentes aportasen su visión, mostrasen sus inquietudes y pudieran ser ayudados. Pensamos usar Lean Coffee como método para obtener, priorizar y tratar temas de conversación que todos deseáramos discutir.

Para el que desconozca cómo funciona lean coffee, está dividido en tres grandes bloques de los que hicimos uso de la siguiente manera:

  • Obtención de temas: el primer paso era saber los temas sobre los que querían hablar los participantes. Para ello, planteamos las preguntas «¿Qué quiero aprender?», «¿Qué puedo aportar?», «Dudas existenciales». Repartimos una serie de post-its sobre los que escribir los temas que quisieran tratar y que posteriormente se colocaron bajo cada pregunta en un muro. Para tener mejor visibilidad de todo, dedicamos unos instantes en agrupar los temas similares o los que directamente eran iguales.
  • Priorización: una vez teníamos todos los temas, los priorizamos para hablar sobre los que pudiéramos dentro del tiempo que teníamos disponible, repartimos entre cada uno 5 puntos que usarían para votar los temas que les resultaran más interesantes, y de esa manera, ordenarlos y detectar los prioritarios.
  • Discusión: establecimos un timebox de 5 minutos para hablar por tema, llegando a la posibilidad de prorrogarlos con una votación hasta que todos pensásemos que el tema no daba más de sí.

Temas tratados

Tras realizar los primeros dos pasos del Lean Coffee, se nos quedó el siguiente muro con los temas que trataríamos en la siguiente hora:

Muro de temas a tratar sacados en el Lean Coffee

Muro del Lean Coffee

Como podéis ver, uno de las grandes preocupaciones que asaltaban a los participantes es la gestión de los assets del frontal de nuestras aplicaciones, cómo hacemos uso de Gulp y/o Webpack Encore. Este tema se llevo gran parte del tiempo asignado del meetup.

Otro tema que tratamos fueron sobre la forma en la que cada uno realizaba la subida a producción de los assets, el debate estaba en generarlos en local y copiarlos arriba, o generarlos directamente arriba. Cada uno defendió sus ventajas e inconvenientes dependiendo de lo que acostumbra a hacer.

Siguiendo con los frontales de nuestras aplicación, surgió la visión de cómo Symfony estaba alejándose de la alimentación del frontal para centrarse en el lado back de las aplicaciones, dando paso así a los clientes desarrollados con frameworks javascripts como React, Angular o Vue. Dedicamos un rato a discutir nuestras experiencias con cada uno, cómo realizamos las comunicaciones entre cada parte, y el manejo de datos sensibles de usuarios.

El último tema que nos dio tiempo a tratar fue el de la gestión de formularios en Symfony, la validación, creación de Constrains. Cada uno expusimos cómo trabajamos con los formularios.

Se quedaron fuera temas interesantes como Certificación, los cambios que se acercan con Symfony 4 o testing, uso de servicios para la lógica de la aplicación frente a custom events.

Cierre

Una vez más, me gustaría desde aquí mandar un saludo a todas las personas que quisieron y pudieron venir, esperamos que les resultase una experiencia enriquecedora y quieran repetir en el próximo. Por otro lado, a todos los que os interese apuntaros al grupo y estar al tanto de los próximos eventos que organicemos, dejo el enlace al registro en el grupo de Meetup.

(5) days of Vue

Esta es la narración de una historia de amor. Breve, intensa y que terminó de forma brusca, contra un muro.

Todo empezó con un encuentro tan casual como inevitable.

Por un lado un estudio digital buscando una herramienta que hiciese el desarrollo de aplicaciones web más eficaz, fiable y escalabale, y que abriese la puerta a exportar ese conocimiento para generar aplicaciones móviles.

Por otro, con uno de tantos frameworks de JavaScript ofreciéndose cual sandía abierta en la red de redes (saludos a los señores periodistas digitales de los mass media).

 

Qué inocente parece, tan sencillo, pulcro y fácil de instalar.

Dentro de las opciones disponibles, estaban los nombres habituales: Angular, React, Ember, Backbone

Pero uno llevaba desde hacía un tiempo llamando poderosamente la atención de todo aquel que se adentraba en este mundo: Vue.

Sus virtudes eran obvias: ligereza, rapidez, versatilidad y sobre todo una curva de aprendizaje de lo más agradable, en la que con un conocimiento previo de HTML/CSS/JavaScript podías obtener resultados muy vistosos de forma casi inmediata.

Para un estudio modesto, en el que la inversión en I+D no puede competir con la de grandes corporaciones al estilo Weyland-Yutani, era una verdadera tentación, imposible de resistir.

El tiempo es dinero, y si un 89% de los desarrolladores decían en 2016 estar tan satisfechos con él como para volver a usarlo, no había más que pensar.

Así, la relación nació llena de ilusión, con un primer acercamiento a la reescritura del Rand-o-matic muy rápida y vistosa.

Versión 0.1 del Rand-o-matic Vueizado. Jusqu’ici tout va bien.

El Tocstrap, como buen amigo, echó una mano en ello, y todo parecía ir sobre ruedas, pero ya sabemos que al principio la pasión lo tapa todo.

El problema vino, como tantas otras veces, con una tercera persona.

Llegó la hora del cambio, de dar el siguiente paso y comprometerse a ser capaces de hacer aplicaciones móviles.

Deberíamos haber empezado a sospechar cuando la elección del framework que debía ayudarnos a conseguirlo no se mostraba con claridad ¿Weex? ¿Cordova? ¿Phonegap? ¿Quasar? ¿Framework7? ¿Ionic? Cada uno tenías sus ventajas e inconvenientes, algunos ya los conocíamos y no nos convencían, otros estaban en un estado de desarrollo demasiado temprano, otros no estaban pensados para funcionar con Vue sino con Angular, otros eran de Adobe…

Con las dudas propias de quien da un like en Tinder a alguien que solo tiene una foto, optamos por Weex. Parecía la opción menos mala dentro de las posibles.

Weex.

Recordad ese nombre. Anotadlo junto al de Summer.

Los problemas empezaron a manifestarse desde el principio, una vez metido entre medias de la relación.

El hecho de tratar de hacerlo funcionar en un entorno Windows no hizo sino agravarlos ¿Pero qué clase de futuro podía esperarnos si no era capaz de resistir una prueba tan dura? Variables de entorno, actualización de Node, instalación de Android Studio, JDK y drivers del dispositivo, añadido de la plataforma de Android… todo lo que en el ecosistema Web App había sido fluidez y avance, aquí se volvía barricadas, retrocesos y desesperación.

Cuando creíamos haber logrado por fin deshacer el nudo, se volvía a enmarañar y había que volver a empezar.

Y para colmo, al ser un proyecto de Alibaba y estar poco extendido aún, gran parte de las dudas había que resolverlas en chino ¿Os imagináis Stack Overflow en chino en vuestro día a día? Intentadlo.

Gracias chicos, pruebo lo que decís y os cuento

El golpe definitivo vino cuando tuvimos que añadir estilos: instalación de paquetes de node (style-loader, css-loader), intentos de importación de ficheros externos, como si de un componente se tratase, intentos de carga asociados a <style>, intentos de carga de todo nuestro Tocstrap incrustado inline. Nada, que no había forma de que aquello cogiese los estilos. Estábamos intentando forzar algo que había nacido fracasado.

Y la culpa fue nuestra, por fiarnos. Por no leer la documentación y ver esto:

The CSS standard may support a lot of selectors, but now weex only support single-class selector.

The CSS standard can support many types of length units, but now weex only support pixel, and the px unit could be ignored, you can write number directly.

The styles of Weex cannot be inherited to children elements, this is different to the CSS standard, such as color and font-size.

The CSS standard contains a lot of styles, but weex only sopport few styles which include layouts such as box model, flexbox, positions.

¿En serio?

¿Y nos dices ahora que estás casado y tienes hijos?

¿De verdad no crees que es algo que deberías poner en tu página home para que, si empiezo algo contigo, sepa a que atenerme?

No sé, algo así como en letras mayúsculas, a tamaño 70 y en #f00. Está bien, no podíamos echarle la culpar, la información estaba ahí, algo escondida, pero estaba. Y nuestra obligación era habernos informado antes de tirarnos a la piscina del I+D.

No era momento de buscar culpables, sino soluciones.

Bien, bien… lo que se dice bien… ahora mismo no me caes mucho

Así que hicimos lo que hemos aprendido en tantas películas: cortar.

Asumir que aquello no iba a ningún lado, que no estábamos hechos el uno para el otro. Ta vez en dos años hubiese tenido más sentido, pero no ahora, nos habíamos equivocado con el momento.

Hicimos limpieza, nos quedamos con la parte de Vue que aún podía salvarse para hacer Web Apps de forma rápida y ligera, y nos pusimos a buscar otra pareja con la que seguir recorriendo al camino.

¿Cuál fue nuestra elección? Solo adelantaremos que, como decía Hitchcock, «en caso de duda lo mejor es refugiarse en lo conocido«.

 

 

 

 

 

DeSymfony 2017

RUMBO A DESYMFONY

Justo hace una semana nos preparábamos y emprendíamos viaje a Castellón con la intención de estar presentes un año más en el evento de deSymfony. Conferencias que cubren problemas, necesidades y metodologías del presente, y que nos ayudan a estar en la actualidad del desarrollo de software con este framework.

LAS CHARLAS

Horario y título de las charlas de DeSymfony

Programa de DeSymfony

Todas las charlas mantuvieron un nivel alto, y fueron muy interesantes y variadas, pero por no desarrollar un post eterno, haremos hincapié en un par de ellas: Symfony 4 y Sylius. Aunque tenemos intención de realizar otro post (o varios) entrando más en detalle.

SYMFONY 4 Y FLEX

Comenzamos el evento con una charla que nos sitúa en la evolución del framework en el futuro inmediato, y se aproximan curvas. El encargado, nada más y nada menos que Javier Eguiluz.

Vimos como Symfony sigue siendo una tendencia en el mundo del desarrollo web, y sus intenciones de serlo durante otros 5 años más. Para ello, se modificará la estructura para ajustarse a micro aplicaciones (no fuertemente ligadas a aplicaciones WEB) y se facilitará la instalación y configuración de bundles gracias a Symfony Flex. Ah! Será requisito PHP 7.1 y saldrá en Noviembre.

El paso a micro framework conlleva a la reducción del código en un 70%, y en igual cantidad, el número de ficheros en vendor. ¿Y Silex? El hueco que llenaba Silex será ocupado por Symfony, capaz de realizar la misma labor. ¿Significa el fin de Silex? Así nos lo confirmó Javier con un rotundo: «Silex está muerto».

Os recomendamos echar un vistazo por las diapositivas de esta primera charla, pues es muy interesante todos los puntos que aborda.

A lo largo de los dos días vimos metodologías, uso de bundles para realizar APIs seguras, o para serializar datos. Nos mostraron que las aplicaciones de consola también pueden ser atractivas y el proceso para empaquetar nuestros propios comandos. Las batallas que han librado para convertir código legacy y aplicaciones monolito a micro servicios más mantenibles. Vimos cómo podemos disminuir el tiempo de carga de nuestras aplicaciones para servir el contenido lo más rápidamente al usuario.

SYLIUS

eCommerce framework for tailored solutions

Asier Marqués nos mostró las bondades de un conjunto de bundles que facilitan el desarrollo de aplicaciones de comercio electrónico con Symfony: Sylius. Y también nos mostró lo preparados que estaban esos bundles para ser usados de manera independiente al resto.

Nos pueden ser de gran utilidad para los siguientes aspectos:

Gestión de pagos (PayumBundle).

Gestión de estados (WinzouStateMachineBundle).

Gestión de entidades de nuestra aplicación y facilidad de crear una API sencilla (SyliusResourceBundle).

Para la gestión del front y temas de Sylius (GridBundle y SyliusThemingBundle).

Por último, trató cómo se mantiene la calidad y testing de Sylius, a través de Behat.

TERMINANDO…

Para finalizar, queremos agradecer otro año más su esfuerzo a los organizadores, que han realizado una labor titánica para juntar a una comunidad que se muestra viva y creciente.

Agradecer también a los ponentes, pues es de respetar el valor que muestran al subirse delante de todos nosotros y por compartir sus conocimientos para que los demás podamos mejorar.

Y cómo no, una mención especial a los patrocinadores, que gracias a su granito de arena eventos así son posibles.

Nos vemos el año que viene.

Cargar configuración del CKEDITOR en Symfony

La semana pasada, durante la fase de test de un proyecto que estamos desarrollando, un cliente nos dijo que estaba teniendo problemas para introducir contenidos porque estaba fallando el editor WYSIWYG que estábamos usando, el CKEDITOR integrado en Symfony. Como siempre, los desarrolladores dijimos que «a nosotros nos funcionaba«, y es que era cierto… hasta que dejó de serlo. De forma aparentemente aleatoria, a veces se permitía la introducción de contenidos con normalidad y otras el proceso no se llegaba a realizar por completo: desaparecía el TEXTAREA asociado pero el editor no llegaba a aparecer en su lugar.

El ordenador del desarrollador como centro del universo

En este punto hay que decir que nuestras necesidades iban un poco más allá de las de por defecto, ya que teníamos que limitar la cantidad de encabezados que podía introducir el usuario y al código HTML al que equivalían unas vez renderizados. Además, en la carga inicial de Symfony no conseguíamos que apareciese la configuración deseada (botones de la barra de herramientas y skin), así que terminamos llegando a este código:


var WYSIWYG = {
	init : function() {
		CKEDITOR.config.format_tags = 'p;h1;h2;h3';
		CKEDITOR.config.format_h1 = { element: 'h3' };
		CKEDITOR.config.format_h2 = { element: 'h4' };
		CKEDITOR.config.format_h3 = { element: 'h5' };
		editors = CKEDITOR.instances;
		if (editors) {
			for (var editor in editors) {
				config = editors[editor].config;
				editors[editor].destroy(true);
				if ($('#' + editor).length > 0) {
					CKEDITOR.inline(editor, config);
				}
			}
		}
	}
};

En donde lo que hacíamos era:

  • Modificábamos los parámetros de la configuración general del CKEDITOR que necesitábamos (format_tags, format_h1, format_h2 y format_h3).
  • Recogíamos todas las instancias del CKEDITOR
  • Para cada una de ellas, almacenábamos su configuración, destruíamos la instancia y la volvíamos a generar, esta vez invocando nosotros al constructor inline.

Este método, según vimos en las sagradas escrituras de Stackoverflow, es muy común cuando se quiere modificar de forma dinámica la configuración del CKEDITOR. Provocaba un efecto de parpadeo algo extraño, ya que primero se invocaba desde el Symfony, y una vez creado se volvía a hacer lo mismo desde el JavaScript, por lo que había unos breves instantes en que el el TEXTAREA se quedaba sin CKEDITOR asociado, pero nos pareció una consecuencia aceptable si lográbamos hacerlo funcionar como queríamos.

Pero entonces ocurrió que esos breves instantes se convirtieron en eternidades, y por más que esperásemos, había veces en que esa segunda creación del CKEDITOR nunca llegaba, y resultaba imposible por tanto introducir contenidos en ese campo. Intuíamos que, al carecer de patrón de aparición aparente, se debía a desajustes en los procesos de carga del JavaScript de Symfony y el nuestro, así que nos pusimos a indagar hasta que finalmente dimos con la solución:

Al añadir el campo en el formulario de Symfony, hacerlo añadiendo un auto_inline a false:


->add('text', CKEditorType::class,
    array(
        'required' => false,
        'auto_inline' => false,
        'inline' => true,
    )
)

Y en el config.yml, cargar la configuración que antes metíamos por JavaScript


page_manual:
            entities: false
            allowedContent: true
            format_tags: "p;h1;h2;h3"
            format_h1: { element: 'h3' }
            format_h2: { element: 'h4' }
            format_h3: { element: 'h5' }
            toolbar: [ ['WidgetTemplateMenu', 'BootstrapTabs'],['Bold', 'Italic', 'Underline', 'Strike'],['Format'],['JustifyLeft','JustifyCenter','JustifyRight','JustifyBlock'],['NumberedList', 'BulletedList'],['Link', 'Unlink', 'Anchor'],['Image', 'PageBreak'],['PasteText', 'PasteFromWord', '-', 'Undo', 'Redo'],['Find', 'Replace', '-', 'SelectAll'],['ShowBlocks'] ]
            uiColor: "#ffffff"

El resultado es que ahora la configuración correcta se carga inicialmente desde el componente de Symfony, y el JavaScript se utiliza… para nada, ya no nos hace falta: un código más simple, eficaz y fiable.

Esperamos que esta solución le pueda servir a alguien y le ahorre un rato del camino que tuvimos que recorrer hasta llegar a esta concusión 🙂

¿Por qué hacer tu propio framework front-end?

He aquí la gran pregunta.

Respuesta corta: porque tenemos un Transtorno Obsesivo Compulsivo. De ahí el nombre del framework. Tocstrap. Ríete tú de Sterling Cooper.

Respuesta larga: porque nos hacía falta una herramienta front con la que afrontar nuestros proyectos, que nos hiciese más rápidos, autónomos y eficaces, y evitase malgastar tiempo en tareas repetitivas de un proyecto a otro. Y todo ello sin generar dependencias de terceras partes, o las mínimas posibles, manteniendo el máximo control sobre el código.

Es decir, un TOC de manual.

Home de Tocstrap

Sí, sí, van en serio, le hemos puesto ese nombre

Así que, con las suficientes referencias a nuestras espaldas que dan el ya maduro recorrido de Elemento115, y que nos permiten saber qué necesitamos como equipo y qué nos haría mejores, nos decidimos a comenzar nuestro propio framework de CSS y JavaScript.

La forma de abordarlo es sencilla: siguiendo las ideas del Atomic Design hemos creado una conjunto de componentes aislados entre sí que nos permiten afrontar de forma automática la creación de cualquier elemento que nos podamos encontrar en un proyecto, así como dotarle de comportamiento. Y todo ello documentado en unas guías de estilo dinámicas, accesibles a través de una URL propia, y que cargan los mismos ficheros que el resto del proyecto. De esta forma nos aseguramos de la autoactualización de la guía de estilo, ya que al modificar el componente del proyecto se modifica automáticamente su homólogo en la guía de estilo.

A todo ello hay que añadir un sistema de grid, basado en el de Bootstrap, que permite a los desarrolladores una buena dosis de autonomía al crear plantillas, sin tener que depender del departamento de Front-end. No nos hemos atrevido aún con el CSS Grid, pero sí con Flexbox, y en lugar de las 12 columnas habituales nos hemos ido hasta las 20, que da más margen para afinar y da divisiones enteras del 100%, y no números periódicos puros en los que uno no puede confiar. Otra vez el TOC.

Columnas del sistema de grid de Tocstrap

Nuestro grid en todo su esplendor

También hemos aportado las ventajas que da usar SASS y Gulp. Tenemos un fichero de settings que configuramos al inicio del proyecto y que nos permite establecer de forma cómoda y rápìda aspectos tan dispares como:

  • Colores corporativos
  • Anchos de los contenedores principales
  • Espacio de los gutters del grid
  • Tamaños y tipografías de los textos
  • Puntos de corte de las media queries
  • Velocidad de las transiciones CSS

De este fichero beben todos los componentes del framework, así que si a mitad del proyecto el cliente quiere cambiar un rojo por un verde, tardamos unos 10″ en hacerlo (y 9″ son de abrir el fichero y arrancar el Gulp).

Aspecto del fichero de settings de SASS

Todas estas cosas podemos modificar fácilemente

El resto de elementos CSS del framework se reparten en módulos de SASS que agrupan aspectos similares, tales como layout, texts, forms… Desde la hoja de estilos principal cargamos dichos módulos, que junto al reset CSS y a los mixins de SASS, nos dejan en una posición de inicio estupenda para arrancar el proyecto con mucho tyrabajo ya hecho.

En cuanto al JavaScript, reunidas todas las funcionalidades en un único fichero y encapsuladas en objetos aislados entre sí, nos permite una inicialización muy sencilla basada en unas convenciones de sintaxis HTML para cada componente y una llamada al método init() correspondiente. No hay, por tanto, que preocuparse por el comportamiento: el framework hace el trabajo por ti.

Aspecto del fichero principal de JavaScript

El init() es nuestro amigo

Esto que hemos hecho no es más que el arranque del camino. Nos queda muchísimo por recorrer, muchas cosas que añadir, unas cuantas que modificar y más de una que eliminar. Tal vez cambiemos Gulp por Webpack o usemos ambos, puede que dejemos de lado jQuery por ES6, incorporaremos Grid CSS en cuanto podamos, y una lista interminable de cambios que ahora ni podemos intuir. Pero la idea básica, el esqueleto sobre el que construir, seguirá siendo el mismo: un único framework para gestionarlos a todos.