Project

General

Profile

Task #79464

Updated by Ralf Zimmermann about 7 years ago

Claus suggested some very useful and necessary optimizations: 

 It might solve your issue to create a fresh View instance before each of the templates in \TYPO3\CMS\Form\Controller\FormEditorController::renderFormEditorTemplates. 

 although it means a bit more init, you're sure to receive a completely fresh parser etc. (it would not be necessary if you switched to renderSection and kept those in - for example - a partial): 

 h2. FormView.php 

 See https://review.typo3.org/#/c/51410/8/typo3/sysext/form/Classes/Mvc/View/FormView.php. 

 Line 243: protected function getCurrentParsedTemplate(): ParsedTemplateInterface 
 This one may come back to bite you one day. Compare with https://github.com/TYPO3/Fluid/blob/master/src/View/AbstractTemplateView.php#L346 - this variant of that method no longer respects the rendering stack and you may experience issues while rendering partials or when using layouts. 

 If your problem stems from reusing the View to render additional templates (and I think it does) then may I suggest a solution that's a more appropriate fix: 

 Use a fresh View instance to render each template file. Your template file is the entry point and as you experience, once you set it, it's hard to get rid of again (Views are not designed for such reuse). 

 An alternative could be to render renderables only by action name and force people to overlay TemplateRootPaths if they wish to add/override renderable templates (in other words, never specifying the actual template filename but only an emulated action name). 

 Personally I think you should have enforced that renderables must exist as partial template files and then provide one template file which "renders a renderable" and make that template file render an optional partial using a name provided from the renderable, with all arguments. It would be more efficient and more override-friendly and in the long run, it would free you up by not requiring a pretty significant amount of custom rendering of Views. 

 h2. Other optimizations 

 In \TYPO3\CMS\Form\Controller\FormEditorController::renderFormEditorTemplates you might consider either rendering sections or partials instead, using $view->renderPartial / $view->renderSection. A new action template for each seems like overkill. 

 You might also consider assigning the objects and fitting them with the necessary getters, rather than extracting their configurations and assigning those to template variables. Third party VH implementations would thank you for making the original objects available ;) 

 General Q: are the path configurations *truly* required enough to merit an exception? If one does not provide a certain path, the expected path gets generated based on extension context (as configured in Request / RenderingContext) 

 \TYPO3\CMS\Form\ViewHelpers\RenderAllFormValuesViewHelper should be converted to static callable + use CompileWithRenderStatic 

 \TYPO3\CMS\Form\ViewHelpers\RenderRenderableViewHelper could use CompileWithContentArgumentAndRenderstatic, make $renderable optional and describe that `{renderable -> form:renderRenderable()}` is also valid (nice to have) 

 ---------- 

 you should definitely consider now, refactoring all the built-in Renderables templates to become either partials or sections, then render these as optional and insert a warning "Template for Renderable %s not found in paths %s" if null is returned.  
 I would also consider dropping this mapping from the .yaml file (another thing is, I wouldn't have used yaml - I would have made it accept an array which could then come from, for example, TypoScript or other existing sources) 
 the reason for this recommendation: you copy much of the context when rendering these templates and instead of doing that, you could reuse the context and avoid nearly all your View init duplication.

Back