http://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692021-05-12T12:46:37ZTYPO3 ForgeTYPO3 Core - Bug #94125: Fluid f:render with argument "contentAs" does not work as expectedhttp://forge.typo3.org/issues/94125?journal_id=4442992021-05-12T12:46:37ZGabriel Kaufmann / Typoworx NewMediainfo@typoworx.de
<ul><li><strong>File</strong> <a href="/attachments/36062">RenderViewHelper.php.issue-94125.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/36062/RenderViewHelper.php.issue-94125.patch">RenderViewHelper.php.issue-94125.patch</a> added</li></ul><p>I've made the following xclass-override which resolves my proposal:</p>
<pre><code class="php syntaxhl" data-language="php"><span class="kn">use</span> <span class="nc">TYPO3Fluid\Fluid\Core\Rendering\RenderingContextInterface</span><span class="p">;</span>
<span class="kd">class</span> <span class="nc">RenderViewHelper</span> <span class="kd">extends</span> <span class="nc">\TYPO3Fluid\Fluid\ViewHelpers\RenderViewHelper</span>
<span class="p">{</span>
<span class="cd">/**
* @return mixed
*/</span>
<span class="k">public</span> <span class="k">static</span> <span class="k">function</span> <span class="n">renderStatic</span><span class="p">(</span><span class="kt">array</span> <span class="nv">$arguments</span><span class="p">,</span> <span class="nc">\Closure</span> <span class="nv">$renderChildrenClosure</span><span class="p">,</span> <span class="nc">RenderingContextInterface</span> <span class="nv">$renderingContext</span><span class="p">)</span>
<span class="p">{</span>
<span class="nv">$content</span> <span class="o">=</span> <span class="k">parent</span><span class="o">::</span><span class="nf">renderStatic</span><span class="p">(</span><span class="nv">$arguments</span><span class="p">,</span> <span class="nv">$renderChildrenClosure</span><span class="p">,</span> <span class="nv">$renderingContext</span><span class="p">);</span>
<span class="k">if</span><span class="p">(</span><span class="o">!</span><span class="k">empty</span><span class="p">(</span><span class="nv">$arguments</span><span class="p">[</span><span class="s1">'contentAs'</span><span class="p">]))</span>
<span class="p">{</span>
<span class="nv">$renderingContext</span><span class="o">-></span><span class="nf">getVariableProvider</span><span class="p">()</span><span class="o">-></span><span class="nf">add</span><span class="p">(</span><span class="nv">$arguments</span><span class="p">[</span><span class="s1">'contentAs'</span><span class="p">],</span> <span class="nv">$content</span><span class="p">);</span>
<span class="k">if</span><span class="p">((</span><span class="nv">$content</span> <span class="o">=</span> <span class="nv">$renderChildrenClosure</span><span class="p">())</span> <span class="o">!==</span> <span class="kc">NULL</span><span class="p">)</span>
<span class="p">{</span>
<span class="nv">$renderingContext</span><span class="o">-></span><span class="nf">getVariableProvider</span><span class="p">()</span><span class="o">-></span><span class="nf">remove</span><span class="p">(</span><span class="nv">$arguments</span><span class="p">[</span><span class="s1">'contentAs'</span><span class="p">]);</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="k">return</span> <span class="nv">$content</span><span class="p">;</span>
<span class="p">}</span>
<span class="p">}</span>
</code></pre>
<p>And the following patch should solve this in the original class.</p>
<p>This would allow such cases rendering optional wraps only if content exists:</p>
<pre><code class="html syntaxhl" data-language="html"><span class="nt"><f:render</span> <span class="na">section=</span><span class="s">"Footer"</span> <span class="na">contentAs=</span><span class="s">"footerSection"</span><span class="nt">></span>
<span class="nt"><div</span> <span class="na">class=</span><span class="s">"footer--content"</span><span class="nt">></span>
{footerSection -> f:format.raw()}
<span class="nt"></div></span>
<span class="nt"></f:render></span>
</code></pre> TYPO3 Core - Bug #94125: Fluid f:render with argument "contentAs" does not work as expectedhttp://forge.typo3.org/issues/94125?journal_id=4948432023-06-16T10:28:48ZSimon Praetorius
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Rejected</i></li></ul><p>The documentation states:</p>
<blockquote>
<p>If used, renders the child content and adds it as a template variable with this name for use in the partial/section</p>
</blockquote>
<p>So contentAs provides the tag content of f:render as a variable to the partial/section that should be rendered, not the other way around. Your XCLASS would introduce an infinite loop if you use the variable inside the partial as documented: You provide a variable which depends on the rendered partial to the partial itself.</p>
<p>As the tag content is already used for this feature, it isn't possible to implement your alternative behavior without introducing a breaking change and losing the other functionality.</p> TYPO3 Core - Bug #94125: Fluid f:render with argument "contentAs" does not work as expectedhttp://forge.typo3.org/issues/94125?journal_id=4948512023-06-16T11:45:54ZGabriel Kaufmann / Typoworx NewMediainfo@typoworx.de
<ul></ul><p>Simon Praetorius wrote in <a href="#note-2">#note-2</a>:</p>
<blockquote>
<p>Your XCLASS would introduce an infinite loop if you use the variable inside the partial as documented: You provide a<br />variable which depends on the rendered partial to the partial itself.</p>
</blockquote>
<p>Thanks for pointing that out that edge-case. Well as far as I can remember it worked at least for my case. Which not means it was perfekt. I think it would be useful to figure out the children-closure already had been invoked. May be this could be implemented in RenderingContext as kind of method return true or false being able to prevent such case where multi-invoking RenderChildrenClose will end up in a mess.</p>
<p>Of course there may still be cases where such an override may not work depending on how the parent-class renderer behaves. But this solution would be better than changing the render-method interface f.e. making $renderChildrenClosure optional (?\Closure $renderChildrenClosure) breaking up too much for 3rd-party code having then broken implementations.</p>