-
-
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 2 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 |
---|---|---|
|
@@ -12,18 +12,10 @@ But sometimes, you don't really need to add new field types - you want | |
to add features on top of existing types. This is where form type | ||
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). | ||
|
||
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 +311,15 @@ 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) |
||
|
||
Although it is not possible to have a form type extension applying to all form | ||
types, **most** form types natively available in Symfony | ||
(:doc:`/reference/forms/types`) inherit from the ``form`` form type. Thus, a | ||
form type extension applying to ``form`` would apply to all of these. | ||
|
||
A notable exception are the ``button`` from types. Plus, keep in mind that a custom | ||
form type which doesn't inherit neither ``form`` nor ``button`` could always be | ||
created. | ||
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. Unless I'm missing some other spot, I think this is actually our opportunity to introduce the "feature" where you can apply extensions to most field types, instead of telling them what they can't do (that would make sense if the rest of the article had been an example using the So, I'd like to see this paragraph introduce the feature first, and then the warning, something like:
... then the "A notable exception..." What do you think? 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. Indeed, having a positively worded documention would be much better. I also tried to reference back the example provided in the bullet point list to provide consistence. |
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.