Skip to content

[RFC] Let's fix the Form Component #8888

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
javiereguiluz opened this issue Aug 30, 2013 · 17 comments
Closed

[RFC] Let's fix the Form Component #8888

javiereguiluz opened this issue Aug 30, 2013 · 17 comments
Labels

Comments

@javiereguiluz
Copy link
Member

This is not a rant about Bernhard Schussek's work on the Form/Validation components. I do really appreciate that he has spent thousands of hours making Symfony better, and as a community we must be really proud to have such a brilliant guy on our side.

The problem

Two years ago Symfony2 launched with a good but unfinished Form component. Today Symfony2 has a better, but still unfinished, Form component. The foundations of the component are solid but, in my opinion, it lacks the following features needed for real-world applications:

  • CAPTCHA (custom-made or integrating the reCAPTCHA service).
  • Dependent <select> lists (it doesn't have to be generic, supporting two dependent lists is enough).
  • Multi-step forms.
  • Client validation (automatically applying the validation constraints with JavaScript)

Just look for example at the Gmail registration form. Although it's a not so complex form, it's not easy to do it with Symfony, because it's multi-step, it uses fancy JavaScript client validation, it includes a CAPTCHA and it has some dependent fields (not <select> lists).

My proposal

Let Bernhard keep working on the foundations on the component and let's organize a community effort to add the previous features to the Symfony 2.X Form Component.

@daFish
Copy link

daFish commented Aug 30, 2013

For multi-step forms I recommend using CraueFormFlowBundle.

Clientside validation can be done using Parsley.js.

@inoryy
Copy link
Contributor

inoryy commented Aug 30, 2013

I know I saw a bundle for reCAPTCHA and dependent selects...

I think it comes down to what should be in the core and what should be left for community to manage as 3-rd party package.

@Burgov
Copy link
Contributor

Burgov commented Aug 30, 2013

dependent selects aren't too difficult to implement, especially since #8828 was merged

@stof
Copy link
Member

stof commented Aug 30, 2013

For ReCaptcha, there is https://github.com/simplethings/SimpleThingsFormExtraBundle/ for instance (it is not the only one)

@zender
Copy link

zender commented Aug 30, 2013

Take a look at https://github.com/thrace-project/form-bundle.

@javiereguiluz
Copy link
Member Author

Yes, I know that "There is a bundle for that!", but that wasn't my point. Let me ask you something: which of the following form fields/validations is more frequently used in real-world web apps?

  • Birthday form field.
  • ISSN validator.
  • CAPTCHA form field.

In my experience, the CAPTCHA field is used like a million times more than the other two combined. Unfortunately, the Form component supports the first two fields/validators but not the last one.

Do you remember the sfFormExtra plugin for symfony 1.X? It included a CAPTCHA, dependent <select> lists, and many other useful widgets, it was properly documented, its development was synced with symfony, etc.

@inoryy
Copy link
Contributor

inoryy commented Aug 30, 2013

I'd rather vote for moving birthday/issn out of the core than adding these into.
Think: user management, admin generation, pagination. All used in majority of projects, all supported by 3-rd parties

@guillaumepotier
Copy link

IMO this is not a need for Symfony core. This is too tightly coupled with user and business logic. I'm even unsure that Symfony should take care of any javascript (there are too many good js libs and frameworks out there).

This work should rather be a useful bundle.

And +1 for using my Parsley lib :)

@hhamon
Copy link
Contributor

hhamon commented Aug 30, 2013

Hi Javier,

I partially do agree with you for multi steps forms and dependent selects. They might be provided as core features as long as they don't rely on Javascript. This is impossible to achieve for double drop down lists without refreshing the page when a value is picked from the first list.

I would rather suggest to have a single SymfonyFormExtraBundle in which we could gather all these features as it was done with the symfony 1 plugin.

@javiereguiluz
Copy link
Member Author

I guess that one of the main problems is that the Form Component doesn't have
a roadmap of the features that will be implemented in the future. Take for
example this form. Today it's impossible to implement it with the Form
Component, but we don't know if one day it will be possible to do it or if
the Form Component aims to implement easier forms and therefore, it will
never be possible to do it.

Anyway, I'm closing this issue because there is not enough interest in it :)

@cordoval
Copy link
Contributor

cordoval commented Sep 2, 2013

I tried the captcha bundle and it is a collander :)

http://phpperu.org/blog/upgrade-in-phpperu

before i had thousands of spam, now i have around tenths

i am with @hhamon in doing a FormExtra and have that bundle either on sensio :) or on FOS bundle of bundles

@inoryy
Copy link
Contributor

inoryy commented Sep 2, 2013

quick search for FormExtra shows this bundle https://github.com/simplethings/SimpleThingsFormExtraBundle which includes captcha

@fabpot fabpot reopened this Sep 2, 2013
@webmozart
Copy link
Contributor

A copy of my reply to the corresponding blog post on symfony.es:

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 [Form] Support dependent fields #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

@webmozart
Copy link
Contributor

Pressed the "close" button by accident.

@webmozart webmozart reopened this Sep 2, 2013
@cordoval
Copy link
Contributor

cordoval commented Dec 1, 2013

I think is better if we break this issue into specific ones rather than being a monolithic discussion

@cordoval
Copy link
Contributor

cordoval commented Dec 4, 2013

guys regarding what i think @bschussek and @javiereguiluz said. I believe we need to provide some work contributing to Form component. Is the one that has the highest number of issues ~200. If you guys report problems please send a test case with it, not just dump your stuff.

Also let's get to work on the issues, filter by Form component and let's help ourselves with this

See the list for Form issues here and help me prioritize them
https://docs.google.com/spreadsheet/ccc?key=0Ao1MtzhUynSNdE1HMVlpZV9DdHhxdGp0ZHc5Y0hpdEE&usp=drive_web#gid=3

I see a lot of people requesting things but not many people stepping up and sending PRs.

With this coming hacking day http://doodle.com/vycrabazihq926yq i hope to see a big large group fixing form issues.

👶

@javiereguiluz
Copy link
Member Author

Closing because there is no interest in this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests