[Form] Deprecate `searchAndRenderBlock` returning empty string #27247

ostrolucky · 2018-05-12T23:37:53Z

Q	A
Branch?	master
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	yes
Tests pass?	yes
Fixed tickets	#26531
License	MIT
Doc PR	-

I would like to remove this silent behavior, because it's confusing

nicolas-grekas · 2018-05-13T11:38:21Z

That'd be for 4.2 now.

ostrolucky · 2018-05-13T12:45:23Z

This isn't new feature so shouldn't be affected by feature freeze. But understood.

nicolas-grekas · 2018-05-13T15:38:46Z

Semver defines that deprecations should follow the same process as features.

ostrolucky · 2018-05-15T09:06:31Z

Changed the base. Should I create UPGRADE-4.2.md in root now?

nicolas-grekas · 2018-05-15T09:07:46Z

Changed the base. Should I create UPGRADE-4.2.md in root now?

yes please

ogizanagi · 2018-05-15T09:27:47Z

UPGRADE-4.1.md

+ After:
+ ```twig
+ {% for field in fields %}
+   {% if not field.rendered %}


This example is a bit misleading to me. Quickly reading it, you might think this check is always necessary when iterating form fields to render them.
I'd rather show an example where you need to render the same field twice and thus store the result in a variable which would be rendered twice in the "after" code.

It's a bit misleading yes. But your suggested example is misleading too. Current code does not allow to render same field twice and neither this patch allows that. We shouldn't present a solution for rendering same field multiple times, as this has nothing to do with that.

Maybe example should just rename fields into fieldsWithPossibleDuplicates

ogizanagi · 2018-05-15T09:29:20Z

src/Symfony/Bridge/Twig/Resources/views/Form/form_div_layout.html.twig

@@ -398,7 +398,7 @@
 {# Support #}

 {%- block form_rows -%}
-    {% for child in form %}
+    {% for child in form if not child.rendered %}


Should we really do this change? Better get the deprecation and then the exception if you're trying to render the same row twice?

isn't this required to support partial form auto-rendering?

It's already supposed to be handled in form_rest:

symfony/src/Symfony/Bridge/Twig/Resources/views/Form/form_div_layout.html.twig

Lines 376 to 381 in 4a7e6fa

{%- block form_rest -%}

{% for child in form -%}

{% if not child.rendered %}

{{- form_row(child) -}}

{% endif %}

{%- endfor -%}

This change is necessary for tests to pass, which means not doing this would be BC break

Which test? If the test is failing by triggering the deprecation, that's expected and should by marked as legacy, right?

Ok yes, it's just deprecation. It was triggered by FormExtensionDivLayoutTest, inherited testcase testRestWithChildrenForms.

Negative of just marking tests as legacy is that it triggers unresolvable deprecation notices in user land. There should be some effort in avoiding it, not just mark test as legacy as first thing IMHO.

~~I might have found another way though~~

edit: here is a chain of calls which trigger deprecation:

form_rest -> form_row -> form_widget_compound -> form_rows

fabpot · 2018-05-18T02:08:12Z

src/Symfony/Component/Form/FormRenderer.php

@@ -132,6 +132,9 @@ public function searchAndRenderBlock(FormView $view, $blockNameSuffix, array $va
        $renderOnlyOnce = 'row' === $blockNameSuffix || 'widget' === $blockNameSuffix;

        if ($renderOnlyOnce && $view->isRendered()) {
+            // This is not allowed, because it would result in rendering same IDs multiple times, which is not valid.
+            @trigger_error(sprintf('Calling the "%s()" method for fields which were already rendered is deprecated since Symfony 4.1 and will throw an exception in 5.0.', __METHOD__), E_USER_DEPRECATED);


should be 4.2 here.

Can we add the field name here as well to help figuring out where that comes from in an app?

people don't call searchAndRenderBlock directly, so this deprecation is confusing as they probably don't know about it.

@stof What do you suggest? I agree people don't call this directly, but formRenderer is responsible for this confusing behavior so deprecation needs to be triggered from within.

well, $blockNameSuffix allows you to know whether form_row or form_widget was called originally, so you can use it to report it.

and I agree about the field name

fabpot · 2018-05-18T02:09:32Z

UPGRADE-4.2.md

+----
+
+ * Deprecated calling `FormRenderer::searchAndRenderBlock` for fields which were already rendered. 
+ Instead of expecting such calls return empty string, check if field has already been rendered.


The whole block must be indented properly under the * to fix rendering.

[...] calls to return [...] if the field [...]

xabbuh · 2018-05-18T07:18:11Z

src/Symfony/Component/Form/CHANGELOG.md

+4.2.0
+-----
+
+ * deprecated calling `FormRenderer::searchAndRenderBlock` for fields which were already rendered.


the dot should be removed

stof · 2018-05-18T07:59:19Z

src/Symfony/Bridge/Twig/Resources/views/Form/form_div_layout.html.twig

@@ -22,7 +22,6 @@
        {%- if form is rootform -%}
            {{ form_errors(form) }}
        {%- endif -%}
-        {{- block('form_rows') -}}


this is a BC break in case someone overwrites the block

For this reason I liked #27247 (diff) solution more. That would be BC break too in case someone overrides FormRenderer (and expect it to be called for already rendered field too), but that is much less likely imho. What do you think?

stof · 2018-05-18T08:00:44Z

src/Symfony/Bundle/FrameworkBundle/Resources/views/Form/form_widget_compound.html.php

@@ -2,6 +2,5 @@
    <?php if (!$form->parent && $errors): ?>
    <?php echo $view['form']->errors($form) ?>
    <?php endif ?>
-    <?php echo $view['form']->block($form, 'form_rows') ?>


same issue here about the BC break

stof · 2018-05-18T08:01:45Z

src/Symfony/Component/Form/FormRenderer.php

@@ -132,6 +132,9 @@ public function searchAndRenderBlock(FormView $view, $blockNameSuffix, array $va
        $renderOnlyOnce = 'row' === $blockNameSuffix || 'widget' === $blockNameSuffix;

        if ($renderOnlyOnce && $view->isRendered()) {
+            // This is not allowed, because it would result in rendering same IDs multiple times, which is not valid.
+            @trigger_error(sprintf('Calling the "%s()" method for fields which were already rendered is deprecated since Symfony 4.1 and will throw an exception in 5.0.', __METHOD__), E_USER_DEPRECATED);


people don't call searchAndRenderBlock directly, so this deprecation is confusing as they probably don't know about it.

ostrolucky · 2018-05-21T23:57:26Z

status: needs review

fabpot

minor CS

fabpot · 2018-05-22T10:23:01Z

UPGRADE-4.2.md

+      {{ form_widget(field) }}
+     {% endif %}
+   {% endfor %}
+   ```


missing empty line after the end of this block

fabpot · 2018-05-22T10:24:38Z

src/Symfony/Component/Form/FormRenderer.php

@@ -132,6 +132,9 @@ public function searchAndRenderBlock(FormView $view, $blockNameSuffix, array $va
        $renderOnlyOnce = 'row' === $blockNameSuffix || 'widget' === $blockNameSuffix;

        if ($renderOnlyOnce && $view->isRendered()) {
+            // This is not allowed, because it would result in rendering same IDs multiple times, which is not valid.
+            @trigger_error(sprintf('You are calling "form_%s" for field "%s" which has already been rendered before. Trying to render fields which were already rendered is deprecated since Symfony 4.2 and will throw an exception in 5.0.', $blockNameSuffix, $view->vars['name']), E_USER_DEPRECATED);


We're trying to have only one sentence for deprecations. Might be changed to [...] rendered before, try [...]

This?

You are calling "form_%s" for field "%s" which has already been rendered before, trying to render fields which were already rendered is deprecated since Symfony 4.2 and will throw an exception in 5.0.

I think there is too much information in there for one sentence. I don't know how to fit all of it in a way sentence seems natural 🤔

stof · 2018-05-22T10:36:39Z

UPGRADE-4.2.md

+   After:
+   ```twig
+   {% for field in fieldsWithPotentialDuplicates %}
+     {% if not field.rendered %}


can be simplified: {% for field in fieldsWithPotentialDuplicates if not field.rendered %}

IIRC this kind of filtering has limitations, depending on what's inside the for block, so I went with safer approach here. But I don't remember what was the issue then, so will change.

the limitation is that any loop.* variables depending on the number of items in the loop won't work anymore (because it won't know in advance).
But if you skip the rendering entirely for some items with an inner filtering, these would not work well anyway, as some code using loop.last would probably expect it to be the last rendered item, not the last checked one.

So do you think we should still go with short way? Another limitation is when you don't want to skip whole loop cycle, but only rendering

{% for field in fieldsWithPotentialDuplicates %} {# ...some code which works with field... #} {% if not field.rendered %} {{ form_row(field) }} {% endif %} {% endif %}

then it is not the same original code (and then, you would have to evaluate whether the additional code should run when the field does not get rendered), and so requires a case-by-case decision.

nicolas-grekas

(after rebase)

ostrolucky · 2018-06-20T23:21:18Z

Rebased. Failures unrelated

fabpot · 2018-06-22T06:09:24Z

UPGRADE-4.2.md

+----
+
+ * Deprecated calling `FormRenderer::searchAndRenderBlock` for fields which were already rendered. 
+   Instead of expecting such calls to return empty string, check if the field has already been rendered.


ostrolucky · 2018-06-22T12:27:27Z

status: needs review

fabpot · 2018-06-25T06:48:35Z

Thank you @ostrolucky.

…y string (ostrolucky) This PR was squashed before being merged into the 4.2-dev branch (closes #27247). Discussion ---------- [Form] Deprecate `searchAndRenderBlock` returning empty string | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | #26531 | License | MIT | Doc PR | - I would like to remove this silent behavior, because it's confusing Commits ------- 02f2f0e [Form] Deprecate `searchAndRenderBlock` returning empty string

…eady rendered (yceruto) This PR was merged into the 5.0-dev branch. Discussion ---------- [Form] Throw exception when render a field which was already rendered | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - See #27247 Commits ------- d1bbad0 Throw exception when render a field which was already rendered

carsonbot added Status: Needs Review Form Deprecation labels May 12, 2018

ostrolucky force-pushed the searchAndRenderBlock-deprecate-empty-return branch from c214eb1 to ad04302 Compare May 12, 2018 23:52

nicolas-grekas added this to the next milestone May 13, 2018

ostrolucky changed the base branch from 4.1 to master May 15, 2018 09:04

ogizanagi reviewed May 15, 2018

View reviewed changes

ostrolucky force-pushed the searchAndRenderBlock-deprecate-empty-return branch from ad04302 to 259ef8b Compare May 15, 2018 19:24

carsonbot removed the Status: Needs Review label May 18, 2018

fabpot requested changes May 18, 2018

View reviewed changes

carsonbot added the Status: Needs Work label May 18, 2018

xabbuh reviewed May 18, 2018

View reviewed changes

stof reviewed May 18, 2018

View reviewed changes

ostrolucky force-pushed the searchAndRenderBlock-deprecate-empty-return branch 2 times, most recently from 70840ed to 3e54c12 Compare May 21, 2018 23:50

carsonbot added Status: Needs Review and removed Status: Needs Work labels May 21, 2018

fabpot reviewed May 22, 2018

View reviewed changes

stof reviewed May 22, 2018

View reviewed changes

nicolas-grekas approved these changes Jun 19, 2018

View reviewed changes

carsonbot added Status: Reviewed and removed Status: Needs Review labels Jun 19, 2018

ostrolucky force-pushed the searchAndRenderBlock-deprecate-empty-return branch 2 times, most recently from 041e9d2 to 5b47226 Compare June 20, 2018 21:38

carsonbot added Status: Needs Work and removed Status: Reviewed labels Jun 22, 2018

fabpot requested changes Jun 22, 2018

View reviewed changes

ostrolucky force-pushed the searchAndRenderBlock-deprecate-empty-return branch from 5b47226 to c7e01f4 Compare June 22, 2018 12:26

carsonbot added Status: Needs Review and removed Status: Needs Work labels Jun 22, 2018

fabpot approved these changes Jun 23, 2018

View reviewed changes

carsonbot added Status: Reviewed and removed Status: Needs Review labels Jun 23, 2018

[Form] Deprecate searchAndRenderBlock returning empty string

02f2f0e

fabpot force-pushed the searchAndRenderBlock-deprecate-empty-return branch from c7e01f4 to 02f2f0e Compare June 25, 2018 06:48

fabpot merged commit 02f2f0e into symfony:master Jun 25, 2018

javiereguiluz mentioned this pull request Sep 13, 2018

[Form] Deprecate searchAndRenderBlock returning empty string symfony/symfony-docs#10340

Closed

nicolas-grekas modified the milestones: next, 4.2 Nov 1, 2018

This was referenced Nov 3, 2018

Release v4.2.0-BETA1 #29072

Closed

Release v4.2.0-BETA1 #29073

Merged

yceruto mentioned this pull request May 29, 2019

[Form] Throw exception when render a field which was already rendered #31704

Merged

	{%- block form_rest -%}
	{% for child in form -%}
	{% if not child.rendered %}
	{{- form_row(child) -}}
	{% endif %}
	{%- endfor -%}

[Form] Deprecate searchAndRenderBlock returning empty string #27247

[Form] Deprecate searchAndRenderBlock returning empty string #27247

Conversation

ostrolucky commented May 12, 2018 • edited Loading

nicolas-grekas commented May 13, 2018

ostrolucky commented May 13, 2018

nicolas-grekas commented May 13, 2018

ostrolucky commented May 15, 2018

nicolas-grekas commented May 15, 2018

Choose a reason for hiding this comment

ostrolucky May 15, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ostrolucky May 15, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ostrolucky May 15, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ostrolucky May 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ostrolucky commented May 21, 2018

fabpot left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ostrolucky May 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicolas-grekas left a comment

Choose a reason for hiding this comment

ostrolucky commented Jun 20, 2018

Choose a reason for hiding this comment

ostrolucky commented Jun 22, 2018

fabpot commented Jun 25, 2018

[Form] Deprecate `searchAndRenderBlock` returning empty string #27247

[Form] Deprecate `searchAndRenderBlock` returning empty string #27247

ostrolucky commented May 12, 2018 •

edited

Loading

ostrolucky May 15, 2018 •

edited

Loading

ostrolucky May 15, 2018 •

edited

Loading

ostrolucky May 15, 2018 •

edited

Loading

ostrolucky May 18, 2018 •

edited

Loading

ostrolucky May 22, 2018 •

edited

Loading