If you are using the Symfony forms system, which I assume you are if you are here, then this post is for you. Otherwise you figure it out. LOL

There is more than one way to do this. However, I am going to show the way I prefer and that is right in the form type definition class.
When you build a form by way of creating a form type class, then it is easy to set all of the options and values you need in one location..
By looking at the documentation one would think the following would work for the HTML placeholder attribute
->add('userAlias', TextType::class, [
'mapped' => false,
'constraints' => new Length([
'min' => 2,
// max length allowed by Symfony for security reasons
'max' => $userAliasObj->getColumnLength(UserAliasTable::ALIAS)
]),
'row_attr' => ['placeholder' => $this->aliasPlaceholder]
])
BUT …. SURPRISE IT DOESN’T WORK. Why? Who knows? Docs need updating, something changed? We might never know.
It even says the following in the docs for row_attr
An associative array of the HTML attributes added to the element which is used to render the form type row:

I am guessing all of the other HTML attributes will work with row_attr? Maybe they do not consider the placeholder attribute as an attribute?
However, I did discover that plain “attr” works with the placeholder attribute like so.
->add('userAlias', TextType::class, [
'mapped' => false,
'constraints' => new Length([
'min' => 2,
// max length allowed by Symfony for security reasons
'max' => $userAliasObj->getColumnLength(UserAliasTable::ALIAS)
]),
'attr' => ['placeholder' => $this->aliasPlaceholder]
])
The docs say the following about attr
If you want to add extra attributes to an HTML field representation you can use the
attr
option. It’s an associative array with HTML attributes as keys. This can be useful when you need to set a custom class for some widget:
Dear Symfony, placeholder is not an extra attribute it is a valid html attribute.

Keeping things together

Keeping all of the form related stuff in one location makes it easier to find and make changes. Some people may argue that you should do this in the template so that non programmers can make changes. I argue if you can learn HTML you can learn to read the docs and articles like this and figure it out. LOL
The interesting thing is the field definitions in your FormType class do not have to be in the order you want them displayed in the browser. This is actually done in the template. This makes it easy to move the small pieces around by copy and paste and it means you get much fewer html bugs. That is another reason I argue if you hire someone who knows only html they should learn this simple system.
My FormType definition for the registration form, for my app contains quite a few fields. However, I can quickly redesign it with confidence by moving a line or two of code instead of hundreds of lines.
{{ form_row(registrationForm.userAlias) }}
{{ form_start(registrationForm) }}
{{ form_errors(registrationForm) }}
{{ form_row(registrationForm.email) }}
{{ form_row(registrationForm.emailMatch) }}
{{ form_row(registrationForm.plainPassword) }}
{{ form_row(registrationForm.passwordMatch) }}
{{ form_row(registrationForm.agreeTerms) }}
See how making changes to the forms layout is super easy this way.

Comments
You must log in to post a comment.