It would be better if we could use$form->getConfig()->getForceSubmit() but changingFormConfigInterface would break BC.

Thanks for working on this@HeahDude! :)

@webmozart alright, comments addressed!

Looks good, thanks@HeahDude! :) 👍

Is anybody taking care of the failed tests?

@webmozart thanks!

I think appveyor was fixed by@nicolas-grekas in#18054 and for travis on php 7@xabbuh should have fixed it in#18037.

Yes, failures are unrelated.

Imo this needs to be added to the changelog (to document the new feature) and to the upgrade file as (as people will have to update their own request handler if they built one).

Ok.

Status: Needs Work

Status: Needs Review

Status: Reviewed

👍

I know I'm very late to this PR ... but I have some concerns about theforce_submit name. Without reading the code or the docs,force_submit can be understood as"send the form even if it contains errors","send the form even if some field is missing","send the form even if the CSRF token doesn't match","keep retrying form submission until there is no error", etc.

But this option in fact just removes the form name from the submitted values. Instead ofuser[name] you can usename.

@javiereguiluz Hopefully one would read the docs before using a new option :) If you think otherwise, do you have a suggestion ?

@javiereguiluz That's a very good point, thanks for pointing it out. So in effect what we are controlling is:

// When$form->handleRequest($request);// force_submit=true: only submit if $form->getName() present in request$form->submit($request->request->get($form->getName()));// force_submit=true: submit even if $form->getName() not present in request$form->submit($request->request->all());

What aboutsubmit_every_request?

As seen in this snippet, another difference is that - with the option set - we do not submit the data of the form, but the complete request. Does this make sense? Shouldn't we rather submitnull here?

ping@guilhermeblanco

Furthermore, do wereally need this? So far,@guilhermeblanco was the only one who ever needed this feature, and it can easily be fixed by implementing the functionality of the request handler yourself in the controller (or as anotherRequestHandlerInterface implementation, if it needs to be reused).

@webmozart Afaics#12528 would (at least partly) be solvable with this change too.

Yes I agree it's more accurate to usesubmit_every_request.

What aboutforce_submit_request ?

@webmozart I think the namesubmit_every_request is better than originally proposed one.
Also, the motivation is mainly about having a GET request with an un-named form, where every regular request should submit the form.
Now taking the GET call together with the form with fields that have default values (empty_data), let's say page=1, perPage=50. Hitting the controller without submitting anything should still submit the form, even though it doesn't have any form data. Also, $form->isValid() must be true (which is not right now because $form->isSubmitted() is false). No matter what we discuss, this is a valid situation where I could force submission.

There's an alternative, implementing my own RequestHandlerInterface, but still, it takes a couple time to digest what you did wrong when working on a day by day basis and experiencing this issue.

What about addingFormConfig::getSubmitEveryRequest() then pushing the method to theFormConfigInterface in 3.4 ? It looks more like a "hack" actually.

I agree it can be useful for API in general and API with GET in particular.

What's the final call on this ? Changing the name is easy to get done for tomorrow :)

@HeahDude Bernhard commented the following:

As seen in this snippet, another difference is that - with the option set - we do not submit the data of
the form, but the complete request. Does this make sense? Shouldn't we rather submit null here?

So, if this option is about submitting the request, why not calling itsubmit_request ?

I agree with all the reasoning here, I would just say I'm not against your proposal, but I don't find it explicit since all form get submitted through request then I go in circle again:

• force_submit_request (because data keys mismatch) orforce_submit_data
• submit_all_request orsubmit_every_request
• submit_as_root
• submit_unmapped
• submit_no_name
• submit_anonymous
• anonymous_form
• 'force_submit_anonymous`

??

I think we're overengineering. This use case can be solved as simply as:

$form =$this->createForm(/* ... */);$form->submit($request->query->all());if ($form->isValid()) {// ...}

Just replacehandleRequest() bysubmit(). There's nothing we need to change as far as I can tell. :)

I may be wrong but the point of this PR is that we cannot do it if the form name is not the key holding the data to submit, because the request handler will not map it, right ?

@webmozart What do you think about having in 4.0 some clear equivalence:

// Does not work$dataToSubmit = $form->getViewData();$form->submit($dataToSubmit); // would submit pre set data// Works$emptyData = $form->getConfig()->getEmptyData();$form->submit($emptyData); // <=> $form->submit(null);

Don't get me wrong, I'm not talking about modifying the way APIs work but about compatibility of dataset and data mapping and the way view data is handled throw the global form lifecycle.

The request handler is simply a more user friendly interface to submit(). If you have more elaborate use cases, using submit() directly is simple enough.

compatibility of dataset and data mapping and the way view data is handled throw the global form lifecycle.

What do you mean? What do you see that should be improved?

Thanks for your response :)

I mean currently$viewData unless using transformers is equal to model data.

My guess is that it should match the real view value:compound ? array : string

On second thought to be able to do that, the data mapping should be done with normalized data, shouldn't it ?