8000 form field type option disabled should not ignore submitted value · Issue #12946 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

form field type option disabled should not ignore submitted value #12946

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.

Sign up for GitHub

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

Jump to bottom
Closed
webdevilopers opened this issue Dec 11, 2014 · 12 comments
Closed

form field type option disabled should not ignore submitted value #12946

webdevilopers opened this issue Dec 11, 2014 · 12 comments

Comments

@webdevilopers
Copy link

The description added by @Sgoettschkes in symfony/symfony-docs#2114 states:

If you don't want a user to modify the value of a field, you can set the disabled option to true. Any submitted value will be ignored.

I only found this short discussion about readonly and disabled:
symfony/symfony-docs#2096

Personally I always regarded readonly as being what is now described in the docs as disabled.
The disabled option in HTML was designed to be enabled again.

In my simple use case I have a radio button addFoo that was checked with the value 1 resp. true.
The Client then enables a dependent choice via JS.
The form now expects the user to select a value from a choice widget selectFoo that was disabled by default.
After submitting the form should be invalid because a constraint is used to check if a selection has been made since addFoo was checked. Of course now selectFoo should no longer be disabled.
This can be handled by the SUBMIT event where I re-add the element being enabled.
So far so good!

But if I check addFoo and DO select a choice in selectFoo and submitting the form then fails because of a different error the selectFoo is not being populated because the original choice field type - before enabling it in the SUBMIT event - had the disabled option.

The code:
https://gist.github.com/webdevilopers/5306ee3417791227abf3

Should we re-consider the functionality of the disabled option when setting data on the form?
Or how should this use case (Disabled field gets enabled on client side and needs to be populated afterwards) be handled?

Will dependent form fields solve this "issue"?
#5807

Possibly related issues:
This was referenced Dec 11, 2014
Closed
Closed
@ioleo
Copy link
ioleo commented Dec 11, 2014

Actually, I think what you're looking for is readonly option.

IF addFoo is checked and selectFoo is disabled
THEN invalidate the form, and make addFoo readonly (checked) and remove the disabled from selectFoo

@peterrehm
Copy link
Contributor

You need the readonly attribute on the field.

use Symfony\Component\Form\AbstractType;

class FooBarType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder->add('addFoo', 'choice', array(
                        'choices' => array(
                            '0' => 'No',
                            '1' => 'Yes'
                        ),
                        'expanded' => true,
                        'required' => true
                    ))
                    ->add('selectFoo', 'entity', array(
                        'class' => 'Acme\AppBundle\Entity\Foo',
                        'attr' => array('readonly' => true)
                    ))
            ;

                $builder->addEventListener(
                    FormEvents::SUBMIT, // `selectFoo` does not get populated
                    function(FormEvent $event) use ($options) {
                        $data = $event->getData();
                        $form = $event->getForm();
                        $disabled = $data->getFoo() == '1' ? false : true;

                        $form->add('selectFoo', 'entity', array(
                            'class' => 'Acme\AppBundle\Entity\Foo',
                            'disabled' => $disabled
                        ));
                    }
                );
    }
}

Disabled means by specification that there is no data submitted and considered in the form, readonly means that the data can be sent and will be bound to the entity.

Please use the readonly attribute hence the readonly option might get deprecated. (#10658)

@peterrehm
Copy link
Contributor

And as you found #12799 this explains a bit more about the issue.

@webdevilopers
Copy link
Author

Thanks guys, it really looks like I was totally mixing up the behaviours of those options.

Looking at:
http://www.w3schools.com/tags/att_input_readonly.asp
this pretty much describes it:
The readonly attribute can be set to keep a user from changing the value until some other conditions have been met (like selecting a checkbox, etc.). Then, a JavaScript can remove the readonly value, and make the input field editable.

Maybe these lines would make sense in the docs too?

@webdevilopers webdevilopers mentioned this issue Dec 11, 2014
Closed
@webdevilopers
Copy link
Author

BTW:
The tricky part in HTML are selects which can have a readonly attribute but still you can use the select.
Only the disabled attribute will prevent using it.
http://stackoverflow.com/questions/368813/html-form-readonly-select-tag-input

@ioleo
Copy link
ioleo commented Dec 11, 2014

Then add

  ->add('selectFoo', 'choice', array(
    'attr' => array('disabled' => 'disabled')
  )

It should add the "disabled" attribute to the select tag, without useing the "disabled" option (which disables the server-side too).

@peterrehm
Copy link
Contributor

But you need to be careful. If you do not remove the disabled attribute it will send no data and on binding the form data the value gets lost.

8000
@webdevilopers
Copy link
Author

Sure abd thanks @loostro & @peterrehm ! My use case now works fine setting the disabled attribute - not option - on the field type. Then enabling it on client side. Works like a charm.

Maybe we can improve the docs by adding an example like this to the cookbook?

@peterrehm
Copy link
Contributor

But usually for your case the disabled attribute is not really recommended, only needed for the select field I guess. You can draft a PR to the docs repository.

@webdevilopers
Copy link
Author

Agree @peterrehm . Maybe I will add it to my blog first and have a look at the reactions if it is worth a cookbook entry.

@webdevilopers webdevilopers mentioned this issue May 6, 2015
Closed
@nursultanturdaliev
Copy link

As of 11 December 2014 adding form elements on FormEvents::SUBMIT seems to work. But now it is not allowed (Symfony 2.7.2) to add form elements on FormEvents::SUBMIT.

I have form fields whose validity depends on other fields value. As I can only access submitted form data object on FormEvents::SUBMIT, I decided to to make those fields disabled here. But no luck.

P.S: I can not use form validation group in my case.

@ilisepe1
Copy link

Hello,

I know it's long time, but could you check this out?
https://github.com/ilisepe1/submitanyway
If you find this useful, now we have a chance to update the HTML standard and have a readonly attribute for all form elements: whatwg/html#2311
To do that we need to make a buzz.

Let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@nursultanturdaliev @ioleo @peterrehm @webdevilopers @ilisepe1
0