-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[RFC][Form] Improve form theming #29651
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
Labels
Form
RFC
RFC = Request For Comments (proposals about features that you want to be discussed)
TwigBridge
Comments
Makes sense. 👍 for me |
Makes sense to me too 👍 |
Nice idea 👍 |
Great idea!!!👍 |
fabpot
added a commit
that referenced
this issue
Jan 3, 2019
…eming (yceruto) This PR was merged into the 4.3-dev branch. Discussion ---------- [Form] Add new block_prefix option for an easy form theming | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #29651 | License | MIT | Doc PR | symfony/symfony-docs#10835 Commits ------- bd50ac4 Add block_prefix option for an easy form theming
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Form
RFC
RFC = Request For Comments (proposals about features that you want to be discussed)
TwigBridge
Suppose you've several form fields (let's say "color") in different place around the app that require a JS component for better UX. For simplicity, this component will not require any additional option, just the value (the hex color
#AEA1FF
) that coming from the underlying data. And of course, it must be reusable.How to put custom code easily together with the color input? What's the shortest path to achieve it? Yeah "Form Theming" so let's move forward.
(Step 1) Create a new form type (let's name it
ColorPickerType
) which will extend fromTextType
and nothing more, almost empty! Why this step? -> because we need a global/reusable block name in our form themes template to render the JS component code under<input />
tag -> for each color form field regardless what form it belongs to, and it's what precisely I want improve here: "I want to remove this step":(Step 2) Create the form themes template
form/fields.html.twig
with the customized block:Great! we already have a new block prefix called
color_picker
allowing easy customization. Now, I need to configure my color fields with my newColorPickerType
.BUT what if you want to configure this block prefix without adding a new form type? Yes, you can currently through the
block_name
option, but most of the time it'll work only for individual fields as each one is prefixed at the same time with the parent block prefix, that's always happening in my case (using EasyAdminBundle or SonataAdminBundle) where the root form always has a name. (see related source code)And here is where my proposal comes from:
What about add an exclusive block prefix that don't depend of the parent form?
I'm thinking in a new option, maybe
block_prefix
or better (defaultnull
) if set add this prefix to the list, just before the unique prefix:symfony/src/Symfony/Component/Form/Extension/Core/Type/BaseType.php
Line 82 in 33f3400
Example (After):
(Step 1) Instead of create a new form type, configure the
block_prefix
option e.g.color_picker
.(Step 2) Same as before.
What do you think?
Cheers!
The text was updated successfully, but these errors were encountered: