El preocupante futuro de los formularios Symfony
Antes de que leas este artículo, me gustaría aclarar que no es una rajada ni contra Bernhard Schussek ni contra su trabajo en el componente de formularios. De hecho, hace unos meses tuve la oportunidad de conocer en persona a Bernhard y le dije (casi) todo lo que vas a leer a continuación.
Mi única intención es hacer una crítica constructiva sobre los graves problemas que en mi opinión sufre el componente de formularios y que se resumen en los siguientes puntos:
- Siempre están cambiando.
- No cubren algunas necesidades básicas.
- No han definido su hoja de ruta.
- Sin apoyo de la comunidad.
Siempre están cambiando
El siguiente código muestra cómo procesar formularios y cómo mostrarlos en las plantillas Twig utilizando diferentes versiones de Symfony2:
// -- Symfony 2.0 -------------------------------------------
// acción
if ($request->getMethod() == 'POST') {
$form->bindRequest($request);
if ($form->isValid()) {
// ...
return $this->redirect($this->generateUrl('task_success'));
}
}
// plantilla
<form action="{{ path('task_new') }}" method="post" {{ form_enctype(form) }}>
{{ form_widget(form) }}
<input type="submit" />
</form>
// -- Symfony 2.1 -------------------------------------------
// acción
if ($request->isMethod('POST')) {
$form->bind($request);
if ($form->isValid()) {
// ...
return $this->redirect($this->generateUrl('task_success'));
}
}
// plantilla
<form action="{{ path('task_new') }}" method="post" {{ form_enctype(form) }}>
{{ form_widget(form) }}
<input type="submit" />
</form>
// -- Symfony 2.3 -------------------------------------------
// acción
$form->handleRequest($request);
if ($form->isValid()) {
// ...
return $this->redirect($this->generateUrl('task_success'));
}
// plantilla
{{ form(form) }}Resulta evidente que con cada nueva versión los formularios de Symfony son mejores y más fáciles de usar. El problema es que cambian completamente en cada versión. ¿quién nos garantiza que en Symfony 2.4 no tendremos que reescribir por cuarta vez la parte de los formularios de nuestras aplicaciones?
No cubren algunas necesidades básicas
En mi opinión, al componente de formularios le faltan al menos los siguientes cuatro elementos para crear formularios básicos:
- Campo para CAPTCHA (propio o usando el servicio reCAPTCHA).
- Listas
<select>dependientes. - Formularios divididos en varios pasos.
- Validación en el navegador (aplicando las restricciones de validación con JavaScript)
Se que puedes pensar que añadir un campo de CAPTCHA es poco glamouroso, pero como programador, cada segundo que dedicas a añadir un CAPTCHA a un formulario es una pérdida de tiempo y de dinero. Si un framework ofrece un componente de formularios serio, debería incluir un campo de tipo CAPTCHA. La solución actual para programadores Symfony consiste en perder el tiempo en buscar un bundle que esté documentado y cruzar los dedos para que funcione con la versión de Symfony que utilizas.
No han definido su hoja de ruta
Un proyecto sin objetivos claros no es un proyecto, es una pérdida de tiempo. Como el componente de formularios no ha definido su hoja de ruta, no sabemos ni a dónde quiere ir ni cuánto falta para llegar. ¿Cuándo estará terminado el componente? ¿Qué criterios utilizamos para decidir si algo debe estar o no en el componente?
Para explicarlo mejor, me gusta utilizar el formulario de registro de Gmail. Aunque no es un formulario tan complejo, actualmente es imposible hacerlo con Symfony: tiene un CAPTCHA, campos dependientes, el formulario está dividido en varios pasos y tiene validación con JavaScript.
El problema de que no exista una hoja de ruta es que no se si algún día será posible hacer ese formulario con Symfony2 o si alguno de sus elementos está fuera del objetivo del componente y por tanto, jamás será posible hacerlo.
Sin apoyo de la comunidad
El componente de los formularios es sobre todo un trabajo personal de Bernhard Schussek, aunque es cierto que ha contado con la ayuda puntual de decenas de programadores que reportan errores y aportan mejoras al código. Actualmente, en el repositorio hay 184 errores 184 issues reportados sobre el componente de formularios pendientes de corregir, y la cifra aumenta cada día.
Hace unos días, propuse a la comunidad Symfony ayudar a Bernhard a desarrollar el componente de formularios. La idea era que Bernhard se dedicase a la parte interna del componente y el resto de la comunidad echara una mano para completar algunas de esas cosas que le faltan (CAPTCHA, validación JavaScript, etc.) La respuesta ha sido tan tibia que demuestra el escaso interés de la comunidad para mejorar de forma activa los formularios de Symfony.
En resumen
Cuando se publicó Symfony 2.0, la excusa oficial para que no incluyera un admin generator como el de symfony 1.X era que los formularios todavía no estaban acabados. Dos años después, los formularios son mucho mejores, pero siguen sin estar acabados. Y su futuro no es nada prometedor, ya que a la falta de una hoja de ruta clara y a los cientos de errores issues pendientes de corregir, se une un escaso interés de la comunidad por echar una mano para solucionar esta situación.
Actualización 2 septiembre: tal y como nos recuerda el propio Bernhard en los comentarios, los "errores" reportados en el repositorio de Symfony en realidad son issues, ya que la mayoría no son errores sino propuestas para mejorar el componente y pull requests. Así que se ha reemplazado la palabra error por issue.
Comentarios
-
#1
En mi experiencia creo que hay dos partes que no acaban de cuajar a la gente para pasarse Symfony, y a mi personalmente son las que me 'limitan' en el sentido de desarrollar de forma cómoda y ágil. Una son los formularios, y otra es Doctrine, ambos son bestias pardas complejas que hacen cosas sencillas de forma díficil muchas veces, como un simple paginador.
-
#2
Nosotros, con nuestra pésima experiencia con los forms de Symfony 1.x, y viéndolas venir, decidimos no usar el componente de formularios en Symfony2. Mandamos todos los datos en un JSON en el body de una petición AJAX, y hacemos las validaciones en un sitio único (ya vengan los datos desde la api o la web). En el frontend montamos los formularios con Backbone, que también se encarga de validaciones en cliente.
-
#3
Hi Javier,
Thank you for the constructive criticism :) I'm going to answer in English, since my written Spanish too poor for a sound reply.
First off, I think you are right in many of your points. Nevertheless, I would like to correct some facts.
The goal of the component is to build forms in a simple, modular and reusable fashion. This goal is in fact already reached. Simplifying and adding missing behavior is not part of that goal, it's part of the long-term process of polishing and improving the component.
Second, you are wrong in mentioning that "184 errors" are currently reported for the component. We are speaking about "issues" here, most of which are feature or improvement requests and only some of which are real "errors". A missing feature is not an error.
You also mention that you don't know about the roadmap of the componant, but this is simple: The roadmap is the GitHub issue tracker. The issues are the todo list. Everything that is currently planned is included there.
You listed four missing features that you consider critical. Let me comment on them:
- CAPTCHA fields: Nobody ever requested CAPTCHA fields to be included in core. If you think this is a critical feature, please open a ticket or - better - a PR.
- Dependent fields are very complex to implement (in fact I don't know about any other form framework that solves this). We are slowly getting there though (see https://github.com/symfony/symfony/issues/5807).
- Form wizards: Again, nobody ever requested this feature for core. Feel free to open a ticket/PR.
- Browser validation: This is very complex to implement too. I don't plan to dedicate time to this topic soon, since there are more important things to work on first.
You are right that these features are important, but so are others. Just check the issue tracker, there are many small but important improvements (not necessarily errors) to work on. I prefer to work on many small improvements over one single huge, new feature such as JS validation. Otherwise we end up with a long list of features that are implemented poorly.
I think that most complaints about the Form component are very valid, but also some kind of first world problems. The component does a lot of things already. Most people forget about that. They notice the missing features only and conclude that they would have been faster had they coded everything by hand. I think this is far from reality.
Cheers, Bernhard
-
#4
i think the call to action was not strong enough or clear. Maybe organizing a roadmap written down somewhere (so not just issues), and maybe a hacking day. If say you already outlined 3 things that are not easy, then i think there should at least be work done one by one on these issues.
-
#5
@Bernhard, thanks for your comments :)
First, you are absolutely right about "issue != error" and therefore I've reworded the original article.
Second, it really surprises me that nobody has ever requested the CAPTCHA form field. A quick search on knpbundles.com reports 9 different CAPTCHA bundles for Symfony2 (combined they have several hundreds of watchers on GitHub). Maybe developers thought that this kind of field doesn't really belong to the Form Component (and indeed, maybe it doesn't belong to it). Again, a written roadmap about the goals of the component and the list of "will have / will never have" items would be useful. (There are also a few bundles about wizards and multi-step forms, although some of them are more complex than a multi-step form).
Lastly, the only thing where I don't agree with you is about "our roadmap = issues opened by users". I agree that listening to the user feedback is very important, and you and the rest of the Symfony community are doing a terrific job about this. But I'm sure that you have a vision about what the Form component should and should not be. Publishing this vision as a roadmap, would allow us to help you better.
-
#6
Javier F. Escribano me parece muy interesante tu solución, puedes escribir algún articulo al respecto.
En cuanto al articulo es verdad que esos cambios constantes demoran en el desarrollo, me parece excelente la propuesta de Javier para aportar como comunidad. Basta con seguir el proyecto en github y participar o que mas se puede hacer?
Saludos.
-
#7
No se ni como tomar esta noticia. Yo he sido un desarrollador que he usado symfony desde la versión 1 y he visto la evolución del proyecto como tal; pero si la realidad del mismo es como la describe Javier, se me vienen varias preguntas a las cabeza. ¿mejor no seguimos desarrollando en Symfony? ¿Siempre seremos beta testers de un proyecto que no acaba de aterrizar? ¿No sigo difundiendo Symfony como una de las mejores soluciones para desarrollar en PHP por no decir que vivo diciendo que es la mejor? ¿Cómo seguir justificando cambios drásticos en el desarrollo, que pro cada nueva versión de Symfony hay que devolver una cantidad de código? Todo este tipo de cosas son tiempo y dinero para una empresa, y si el proyecto no esta lo suficientemente maduro como para ser utilizado en entornos de producción, no deberían haber salido con una versión "estable".
El proceso de adopción de esta tecnologia dentro de mi empresa no ha sido sencillo y por que no decirlo, todavia estamos desarrollando en Sf 1.4 por la misma razón que plantean y si es asi y si el proyecto luego de 2 años todavia presenta este tipo de problemas eso quiere decir que me deberia replantear el uso de este framework como solución para PHP...
No es nada motivante leer que el lider del Blog en español tenga este concepto y él no lo esta dando de mala fé sino por propia experiencia.
Tocando algo muy particular, es muy cierto... Admin Generator en Sf 1 es una herramienta muy importante para agilizar muchos procesos de creación de interfaces de mantenimiento y si esta parte todavia no esta dentro de la hoja de ruta de Sf 2, y toca seguir peleando con Blundes complejos, es mejor solo dejar Sf2 como generador de clases y core de proyectos orientados a Objetos y utilizar herramientas como EmberJS para la construcción de las interfaces.
No me deja un buen sabor este articulo... ojala que en dias posteriores veamos una pronunciación clara y puntual por parte del lider del proyecto y pautas claras para las nueva versiones. El proyecto también vive por la comunidad que lo usa y si no se escucha a la comunidad el proyecto corre el riesgo de comenzar a perder adeptos y nada mas terrible que eso.
Saludos desde Colombia
-
#8
@Carlos, tranquilo que no es para tanto :) En primer lugar, lo que he descrito no es "la realidad", sino "la realidad tal y como yo la veo", que es muy distinto. El propio Bernhard ya me ha corregido varias cosas en su comentario.
Lo segundo: el componente de formularios tal y como está ahora mismo se puede usar en aplicaciones de verdad y es muy potente. Lo único malo es que, hasta ahora, ha cambiado mucho y en mi opinión, le faltan algunas cosas básicas.
Lo tercero: si hablamos de PHP, me temo que no hay rival para Symfony2. Pregunta a cualquier programador serio y con experiencia y te dirá que aunque a veces con Symfony2 cuesta un poco más hacer algunas cosas, una vez desarrolladas no hay comparación posible por la calidad conseguida, la flexibilidad, etc.
Por último, Symfony2 no tiene admin generator de verdad, el componente de formularios es mejorable, Doctrine2 trae de cabeza a más de un programador, etc. Pero el resto de piezas de Symfony2 son absolutamente increíbles: Twig, Monolog, el enrutamiento, los servicios, la gestión de peticiones y respuestas, la caché HTTP, etc.
-
#9
@Carlos Coincido con los 2 últimos párrafos de @Javier 100%, Twig cuanto más lo conoces más te enamoras (ahora entiendo la charla del DeSymfony Vigo), Monolog te quita mucho trabajo, el enrutamiento es muy versátil y no hace falta tener un mega array inmanejable como en zend que a poco que te crezca la app lloras sangre, se habla poco del soporte de idiomas nativo pero es que tener eso de serie con gestión precisamente de rutas integrada es la vida, y podemos seguir ...
Ahora bien, emho creo que SF2 tiene dos cosas potentes y a la vez duras de lidiar con ellas: Doctrine y formularios. Además curiosamente coincidimos la mayoría de desarrolladores en ello. Rara vez verás a alguien echar pestes de Twig, pero de Doctrine ...
También debemos ser conscientes de todo lo que hace Doctrine, es muy grande y soporta tanto base de datos relacionales como no relacionales (MongoDB). Es un software 'dinosaurio'. Los formularios dependen bastante de este y por eso esta dupla es tan crítica.
También hay que tener claro que Symfony, al igual que Zend Framework, no está diseñados para aplicaciones pequeñas/medias, aunque se puedan desarrollar perfectamente. Son sistemas de sentarse y tener claro que el 80% de la app es valorar y pensar que funcionalidades de SF te van a ayudar en el desarrollo. Si te pones a tirar código probablemente antes de un mes estarás en una esquina de la oficina maldiciendo tu suerte ;)
Recuerda que puedes no usar ni forms ni Doctrine, pero perderías mucha de la 'gracia' de symfony.
-
#10
I have to correct one more point: Yes, the Form component kept (and keeps) changing, but since the LTS we guarantee BC. So you can use
$form->handleRequest($request), but you can also keep on using$form->bind($request->request->get($form->getName()))(or any of its alternatives) up until Symfony 3.0. -
#11
Desde un inicio en componente de formularios ha sido complejo, grande, incluso llamado por algunos como "monstruoso", pero sigue siendo un "componente mas"... Si no lo deseas/puedes usar esta bien... no lo uses, pero quienes lo conocen y lo usan en realidad lo aman/amamos... Tiene sus pequenos detalles, pero no podemos hacer feliz a todo el mundo, es la gracia del FLOSS... necesitas algo mas? pidelo! puedes hacerlo tu mismo? colabora! asi todo salimos adelante :) Ya en detalle, por ejemplo en apps mucho mas desacopladas con un Backbone/Angular etc en el frontend y Symfony2 en el backend la vida sigue siendo bella con o sin el componente de formularios.
Saludos!
-
#12
Existe el componente de ZF2 de formularios, seria algo optimo vincularlo al proyecto y utilizarlo en vez del actual de Symfony2, ven un cambio o beneficio interesante en realizar esto?
Saludos
-
#13
Symfony por ser Symfony y sus componentes por ser parte de Symfony no pueden echar todo a lo difícil, es cierto y nadie lo niega, Symfony es tal vez el mejor Framework para PHP, pero no deben dejar de lado cosas que por sencillas que sean, en una aplicación web real son necesarias.
Si alguien como Javier Eguiluz dice esto pues es porque realmente estan haciendo falta, otros frameworks como Yii, incluyen un Captcha, validacion de formularios con JavaScript, etc, y como es posible que esto no lo haga Symfony.
Claro esta, no todo es malo, y como dice Javier esto es algo que él cree que falta, y si que falta.
-
#14
A mi de las carencias que comenta Javier si me parece interesante los multiforms o formularios en pasos, de hecho en este nuevo proyecto tenemos esa necesidad y es requisito.
Para los selects dependientes tienes el autocomplete de jquery ui o de bootstrap con lo que además ganas autocompletado valga la redundancia
La validación javascript no me gusta por estar de lado del cliente además hay varios plugins para frameworks js varios.
Los captcha si podría ser interesantes pero directamente integrar algún sistema medio fiable como extensión de los forms.
-
#15
Yo estoy totalmente de acuerdo con la falta de un Roadmap para el componente de Forms, esto facilitaría mucho, no solo la posibilidad de ayudar y colaborar a la comunidad, sino también la posibilidad de conocer el futuro de un componente que se me antoja indispensable hoy en día en mis aplicaciones Symfony2.
En cuanto al CAPTCHA, creo que si se integra, debería ser algo totalmente independiente, que no sea necesario acceso a otros servicios como reCaptcha, ya que en muchos proyectos internos no se tiene acceso a esos servicios.
Por otra parte, al principio me parecía que perder el "AdminGenerator" era una de las peores cosas de Symfony2, pero hoy en día con el CrudGenerator de Doctrine está totalmente solventado y mucho más potente.
Para finalizar, hay que dar las gracias a toda la gente que ayuda en los proyectos que al fin y al cabo nos quejemos o no, nos dan de comer.
Thanks @Bernhard and @Javier!
-
#16
Bastante interesante lo que comentan todos, es un tema que es importante para el Framework y para los desarrollos basados en el mismo.
Al final comparto la idea de Javier, por lo menos hace falta mas ayuda de la comunidad, si volteamos hacia la comunidad de México esta muy dispersa y es muy poca y obviamente esta puede aumentar considerablemente.
Hay que recordar que un proyecto tiene un inicio y un fin bien definido, lo que considero que esta causando confusión y falta de claridad es el no tener un final bien establecido (en este ejemplo, los Forms).
Saludos
-
#17
Symfony 2 está planteado emho como 'rolling software', es decir, que si se ve algo que mejora o salen versiones nuevas por ejemplo de Doctrine se implementan.
Creo que nació precisamente LTS porque ellos mismos se habrán dado cuenta que para cosas 'grandes o serias' es inmanejable cambiar cada 6 meses aparte del coste.
-
#18
Lo único que extraño es el entity como campo text, que aunque existe un bundle que lo hace muy bien, estaría genial que lo incorporará en los formularios.
Por lo de la validación del lado del cliente, no estoy de acuerdo que sea muy importante, ya que eso se puede realizar con cualquier framework js, ademas todos tenemos nuestro preferido. Y como dicen, ya tenemos la version LTS.
-
#19
For @Bernhard Schussek and @Javier F. Escribano
En el Comentario #2, de @Javier F. Escribano La idea es genial, pero me parece que mezcla los tantos. La validación no es parte del Form Framework, si en SF1.4 pero no en SF2, donde todo se "hookea" a la entity, si la entity es valida, $form->isValid() pasa, pero se puede validar la entity por separado.
Con respecto a la falta de comunidad @Bernhard Schussek I think it's entirely because of lack of documenatation :). La buena documentación es la principal razón por la que la comunidad de sf creció tan rápido (ademas de que el FW esta bien pensado).
Yo trate de usar el Forms Component, Standalone, (lo conseguí) pero tuve varios problemas, de standalone tiene poco, tuve que arrastrar, TemplatingEngine, Doctrine Extenssion (thats ok since I needed EntityType), ValidatorExtension, medio(half) Sf2 FW... Lo que me parece bien, porque cada extension obedece a una necesidad puntual. Pero la documentación es muy pobre. Fuera del CoockBook|Book de sf2 no hay (o no encontré) mucho sobre como implementar Forms Component en un proyecto legacy.
Gracias! Estoy completamente de acuerdo con tu conclusión: "... The component does a lot of things already. Most people forget about that. They notice the missing features only and conclude that they would have been faster had they coded everything by hand. I think this is far from reality."
The good part is that more often than not, it's more difficult to see what's missing than to see what's already there... So despite of people's lack gratitude, you should be happy they are telling you whats missing.
-
#20
Les dejo un muy buen video, que encontre en el blog de @ircmaxell "... I think that everybody that's even remotely involved in internals needs to stop and go watch How Open Source Projects Survive Poisonous People." http://www.youtube.com/watch?v=ZSFDm3UYkeE
-
#21
Spending time on JS validation would not really be a good fit. First off third-party JS libs do that for you, secondly html5 which is supported is slowly taking over this tasks.
So if you have requirements for JS validation, just pick a third-party html5 forms "shim" which falls back to JS in older browsers for you. This way From component can focus on improving the existing html5 validation for all future browsers and "shim" users at the same time.
-
#22
Muy acertada esta frase de Javier "a veces con Symfony2 cuesta un poco más hacer algunas cosas, una vez desarrolladas no hay comparación posible por la calidad conseguida, la flexibilidad, etc."
-
#23
Hace unos meses me puse en el poco tiempo que tenía a aprender symfony2. Me pareció bastante interesante y apasionante, hasta que me choqué con un alta de una entidad en la que requería dos combos (select) dependientes.
Aunque hay mucha documentación de cómo hacerla, unos usan una versión que no es la misma que usaba yo, otros no especifican bien algunas cosas en ajax, o dan por hecho algunas cosas que no todos sabemos aún. Eso hizo que dejara mi aprendizaje de Symfony2 hace bastante tiempo. Ayer me puse con él, y aunque conseguí algo, sigo enredado (supongo) con ajax, o a saber, porque tampoco es que en ese aspecto sea muy fácil seguir una traza.
En fin, es algo en lo que me sigue pareciendo muy superior Microsoft al resto de compañías en ese aspecto. El entorno de Visual Studio y el nuevo MVC 4 o 5 de ASP.NET desde luego no tienen rival a la hora de desarrollar, tanto por documentación como facilidad al desarrollo o "trazabilidad" de la aplicación.
No entro a valorar tema de software libre o no, de licencias ni costes, pero me sigue pareciendo que el software libre en este aspecto tiene mucho que aprender.
Este artículo ya no permite añadir más comentarios.
¿Por qué? Los artículos cierran sus comentarios automáticamente
unos meses después de su publicación para asegurar que estos sigan
siendo relevantes.
Proyectos Symfony destacados
La plataforma de eCommerce 100% Symfony que rivaliza con Magento y PrestaShop. Ver más
Síguenos en @symfony_es para acceder a las últimas noticias.