Skip to content

Added info on doctrine metadata implications on validation #6649

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
wants to merge 1 commit into from

Conversation

ThomasLandauer
Copy link
Contributor

It took me a while to figure this out. So I think it should be explained somewhere. I'm not sure if this is the right place, and I'm also not sure if the information is comprehensive.
Just wanted to get somehing going about 'Doctrine and validation' somewhere in the docs.

It took me a while to figure this out. So I think it should be explained *somewhere*. I'm not sure if this is the right place, and I'm also not sure if the information is comprehensive.
Just wanted to get somehing going about 'Doctrine and validation' somewhere in the docs.
@ogizanagi
Copy link
Contributor

ogizanagi commented Jun 13, 2016

This feature is actually provided by type guessers (especially the Doctrine ORM one). It does not only work for the length attribute, but for many other usages. So I don't think this particular note should be added.
However, it only works when not specifying any type for the given field in the form, but let the symfony registered type guessers do the work for you.

It's more or less explained in Creating a custom Type Guesser.

@ThomasLandauer
Copy link
Contributor Author

I'm not sure that we're talking about the same thing.

When I create a form like here: http://symfony.com/doc/current/book/forms.html#creating-form-classes
...and in the Entity I set the length to 10, I get the maxlength attribute in HTML. However, when I do submit more than 10 characters, I don't get any error message from the validator. This is only the case when I add a rule in validation.yml too.

The DoctrineOrmTypeGuesser, is this enabled by default? If no, where do I have to enable it?

@ogizanagi
Copy link
Contributor

@ThomasLandauer : I confirm we're talking about the same thing. Types guessers are not about validation, they guess the form type to use and some attributes like required or other html attributes.
Type guessers shipped with Symfony are based on Symfony's Validator & Doctrine metadata.

See:

Input type, required, max length & pattern html attributes are guessed thanks to them.

The DoctrineOrmTypeGuesser is enabled by default.
But as I said, type guessers are only active for fields for which you didn't specified explicitely a type when creating the form.

@ThomasLandauer
Copy link
Contributor Author

ThomasLandauer commented Jun 13, 2016

OK, my point is: Being a smart framework, I (personally) would have expected that Symfony automatically uses my Doctrine metadata for validation (i.e. true server-side validation). Since this is not the case, I think it should be explained somewhere that the user is expected to repeat the ORM rules in validation.yml.

I think the entire Forms chapter should be reorganised, prioritizing more on real use-cases (like this one, namely binding a form to a database entity) and less on exotic features like forms with multiple submit buttons. In other words: Before you can tell people about validation groups, you should tell them how validation works at all :-)

I don't insist on my particular wording, neither on this very location. But, again, since binding a form to a database entity is a standard use-case, it should be explained somewhere how validation works in this case.

@weaverryan
Copy link
Member

Hey guys!

Catching up on some old PR's :). I definitely agree with you @ThomasLandauer, and when I went through the current docs (which have been restructured already in many of the ways you suggested), I found out that I think we now have this covered: the forms chapter talks about field option guessing, what it does, and how it works: http://symfony.com/doc/current/forms.html#field-type-options-guessing. And, this conversation comes after talking about real, server-side validation.

So, I'm going to close this PR as finished - please feel free to open a PR if you think we could clarify further.

Thanks!

@weaverryan weaverryan closed this Sep 18, 2016
weaverryan added a commit that referenced this pull request Sep 18, 2016
* 2.7:
  [#6925] Removing more instances of the deprecated getMock()
  Minor language tweaks
  removing cookbook entries
  updating links
  Moving files into the new structure
  [#6649] Changing a note to a caution - this *is* a gotcha
  fix typo
  Typo in the class name.
  Fixed indentation issues in alias_private article
  [Serializer] Document the encoders
weaverryan added a commit that referenced this pull request Sep 18, 2016
* 2.8: (32 commits)
  [#6925] Removing more instances of the deprecated getMock()
  Method "$this->getMock()" is depreciated
  Minor language tweaks
  removing cookbook entries
  updating links
  Moving files into the new structure
  [#6649] Changing a note to a caution - this *is* a gotcha
  fix typo
  Typo in the class name.
  Update tags.rst
  Fixed indentation issues in alias_private article
  Fix the error in code example
  [Controller Description] Remove backticks
  [Controller] Fix nested inline markup
  [Controller Description] Fix typos and class link
  Fix var_dumper advanced usage link
  [#6908] Add deprecations on some other places as well
  Add deprecation warnings to relevant profiler options
  Update access_control.rst
  DumpFile() third argument is deprecated and doesn't exists anymore in 3.x
  ...
weaverryan added a commit that referenced this pull request Sep 18, 2016
* 3.0:
  [#6925] Removing more instances of the deprecated getMock()
  Method "$this->getMock()" is depreciated
  Minor language tweaks
  removing cookbook entries
  updating links
  Moving files into the new structure
  [#6649] Changing a note to a caution - this *is* a gotcha
  fix typo
  Typo in the class name.
  Update tags.rst
  Fixed indentation issues in alias_private article
  [Serializer] Document the encoders
@ThomasLandauer
Copy link
Contributor Author

Um, now the entire "Forms and Doctrine" subsection (https://github.com/ThomasLandauer/symfony-docs/blob/dbe120598ca6fd38b38adff456a2247d3849645b/book/forms.rst#forms-and-doctrine) of the forms chapter is gone!
Was this moved to a separate article?? Can't find it anywhere.....

So while being better in general, the new version of the chapter is even worse than the old one, regarding the interplay with Doctrine. Which is the most widely used use-case of a form, after all.

@ThomasLandauer ThomasLandauer deleted the patch-9 branch August 17, 2018 09:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants