Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[FrameworkBundle] improve AbstractController::renderForm() #41190

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

Merged
merged 1 commit into from
May 12, 2021

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented May 12, 2021

Q A
Branch? 5.x
Bug fix? no
New feature? no
Deprecations? no
Tickets -
License MIT
Doc PR -

Even better than #41178, this requires a simple change on apps, and is compatible with multiple forms.

Usage:

-        return $this->render('thing/new.html.twig', [
+        return $this->renderForm('thing/new.html.twig', [
             'thing' => $thing,
-            'form' => $form->createView(),
+            'form' => $form,
         ]);

In 5.4, we could even deprecate passing a FormView to render() so that we can always set the 422.

@tgalopin
Copy link
Contributor

tgalopin commented May 12, 2021

Shouldn't this be opt-in, as it's technically a BC break for apps already passing a form as a variable?

@lyrixx
Copy link
Member

lyrixx commented May 12, 2021

I was thinking the same thing 👍

@nicolas-grekas
Copy link
Member Author

From the HTTP pov, this is a bug fix.

@tgalopin
Copy link
Contributor

tgalopin commented May 12, 2021

If I understand correctly, I'm not not able to pass a Form to my view (a FormView will always be passed instead). This is weird, I agree, I'm not sure anyone would have the usage of passing a Form instead of a FormView.

@Warxcell
Copy link
Contributor

Warxcell commented May 12, 2021

One possible issue: if exception is handled inside controller and status code is set to 500, this could overwrite it to 422. Not really sure which one should be correct in that case. (probably the 500)
Probably 422 status code can be set only if status === 200 (default one).

$response = new Response();
try {
  // do something
} catch(\Exception $ex) {
   $response->setStatus(500);
   $error = 'xxx';
}

return $this->render('template', ['form' => $form, 'error' => $error], $response);

@nicolas-grekas
Copy link
Member Author

And yes, I'm assuming no app is going to pass a FormInterface to twig, at least not as a root variable. I think this is safe.

@nicolas-grekas nicolas-grekas changed the title [FrameworkBundle] remove AbstractController::renderForm(), use render() instead [FrameworkBundle] improve AbstractController::renderForm() May 12, 2021
@nicolas-grekas
Copy link
Member Author

Let's be on the safe side, the renderForm() method is back. PR and description updated.

@nicolas-grekas
Copy link
Member Author

One possible issue: if exception is handled inside controller and status code is set to 500, this could overwrite it to 422.

fixed

Copy link
Member

@chalasr chalasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with minor comment

$response = new Response();
}

foreach ($parameters as $k => $v) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it could be better to pass explicitly the form object since it can save us from cycling all the parameters.

<?php
    protected function renderForm(string $view, FormInterface $form, array $parameters = [], Response $response = null): Response

Moreover, it improves simplest cases: instead of calling $this->renderForm('view.html.twig', ['form' => $form) you can use this->renderForm('view.html.twig', $form)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@garak this was discussed on other PR.
There are 2 problems with this approach:

  1. It makes less obvious what is variable name of form in view.
  2. Doesn't work when have more than 1 form. (Typical use-case: Profile editing: 1 form for simple fields (name), second for for phone change, 3rd form for email change.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's exactly what this PR iterates over, see patch. Iterating makes the helper compatible with controllers that have multiple forms as parameters, and saves from creating any convention to name that $form parameter inside the list of $parameters (see removed $formVar)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants