8000 [Form] Improve the doc about "recursive" rendering · Issue #1055 · symfony/symfony-docs · GitHub
[go: up one dir, main page]
Skip to content

[Form] Improve the doc about "recursive" rendering #1055

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
vicb opened this issue Feb 2, 2012 · 5 comments
Closed

[Form] Improve the doc about "recursive" rendering #1055

vicb opened this issue Feb 2, 2012 · 5 comments
Labels
actionable Clear and specific issues ready for anyone to take them. Form

Comments

@vicb
Copy link
Contributor
vicb commented Feb 2, 2012

Is it possible to make recursive calls in order to decorate the base template:

 {% block _text_id_widget %}
 <div id="container">
    {{ form_widget(form) }}
 </div>
{% endblock %}

The doc should give hints on when to call the flexible {% form_xxx %} vs when to call the speedy {% block() %}.

Refs:
symfony/symfony#1369
symfony/symfony#3195
@weaverryan
Copy link
Member

@vicb Are the advantages of {% block() %} only for speed or are there some functional reasons why you would use it? I know this is an old issue - I'm trying to decide exactly what actions should be taken and why so we can get this closed on way or another.

Thanks!

@vicb
Copy link
Contributor Author
vicb commented Jan 20, 2013

@weaverryan when you call form_xxx you the whole (form specific) inheritance rendering is triggered, ie any part of what gets rendered could be overridden by your theme, it's much more powerful. But sometimes calling form_xxx will only result in rendering an input box or a label. In such a case calling block will be much more efficient - but you loose the ability to hook in some override. More efficient = much less function calls and then CPU cycles.
@bschussek I think still is still true after the rendering refactorization ? If the cache mechanism has made the difference neglectable we might not document the block option at all.

@webmozart
Copy link
Contributor

I think, however this is documented, it should also take Twig's parent() function into account.

In form themes you need to consider two levels of inheritance:

  1. Template inheritance (i.e. my_layout extends form_div_layout)
  2. Type inheritance (i.e. url extends text extends form)

When you want to render the current block of the parent template (inheritance type 1), you should use parent().

When you want to render the block of the (any) parent form type (inheritance type 2, from any loaded theme template), you should use form_*().

In any other case, for example if you split a block into multiple blocks for practical reasons (as in choice_widget), you should use block().

@weaverryan
Copy link
Member

I think the best place for this is here: http://symfony.com/doc/current/cookbook/form/form_customization.html

We should at least add a section somewhere that basically mirrors @bschussek's words here, as I think the end-takeaways are explained quite clearly.

@linaori
Copy link
Contributor
linaori commented Feb 8, 2018

This is more or less mentioned on this page: http://symfony.com/doc/current/form/form_customization.html#referencing-base-blocks-from-an-external-template

I think this issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
actionable Clear and specific issues ready for anyone to take them. Form
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@weaverryan @webmozart @vicb @linaori
0