-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
[Cookbook] Fix doc on Generic Form Type Extensions #5227
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
Changes from all commits
f321253
a309be8
855301d
0159e68
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,16 +14,15 @@ extensions come in. | |
|
||
Form type extensions have 2 main use-cases: | ||
|
||
#. You want to add a **generic feature to several types** (such as | ||
adding a "help" text to every field type); | ||
#. You want to add a **specific feature to a single type** (such | ||
as adding a "download" feature to the "file" field type). | ||
as adding a "download" feature to the "file" field type); | ||
#. You want to add a **generic feature to several types** (such as | ||
adding a "help" text to every "input text"-like type). | ||
|
||
In both those cases, it might be possible to achieve your goal with custom | ||
form rendering, or custom form field types. But using form type extensions | ||
can be cleaner (by limiting the amount of business logic in templates) | ||
and more flexible (you can add several type extensions to a single form | ||
type). | ||
It might be possible to achieve your goal with custom form rendering, or custom | ||
form field types. But using form type extensions can be cleaner (by limiting the | ||
amount of business logic in templates) and more flexible (you can add several | ||
type extensions to a single form type). | ||
|
||
Form type extensions can achieve most of what custom field types can do, | ||
but instead of being field types of their own, **they plug into existing types**. | ||
|
@@ -319,3 +318,19 @@ next to the file field. For example:: | |
|
||
When displaying the form, if the underlying model has already been associated | ||
with an image, you will see it displayed next to the file input. | ||
|
||
Generic Form Type Extensions | ||
---------------------------- | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I liked the "Generic" wording because it's very easy to search and provides a nice keyword. Plus it matches the text in the bullet points at the top of the article. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's fine with me :). In the paragraph below, we should mention the 'getExtendedType' function specifically so they know where they'd exactly put 'text' or 'form' (maybe even show a small code block) |
||
|
||
You can modify several form types at once by specifying their common parent | ||
(:doc:`/reference/forms/types`). For example, several form types natively | ||
available in Symfony inherit from the ``text`` form type (such as ``email``, | ||
``search``, ``url``, etc.). A form type extension applying to ``text`` | ||
(i.e. whose ``getExtendedType`` method returns ``text``) would apply to all of | ||
these form types. | ||
|
||
In the same way, since **most** form types natively available in Symfony inherit | ||
from the ``form`` form type, a form type extension applying to ``form`` would | ||
apply to all of these. A notable exception are the ``button`` form types. Plus, | ||
keep in mind that a custom form type which inherit neither ``form`` nor | ||
``button`` could always be created. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like these 2 bullet points - they quickly answer the question "what can I do with this form type extension thing?". I think you removed them because it says "every field type", but that's effectively true (the button being the exception). I'd like to have these back, and let the last paragraph explain the edge case.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this was a great way to explain Foem Type Extensions.
I restored them but changed the example. I now use ""adding a "help" text to every "input text"-like type"". This seem to be closer to an actual use case but also more truthful regarding what can be done.