Skip to content
  • Christian Kuhn's avatar
    [TASK] Simplify Templating Bootstrap in BE Controllers · 37ac299f
    Christian Kuhn authored
    This patch introduces a new EXT:fluid view class
    "BackendTemplateView" to be used as main view for
    backend-related non-Extbase views.
    
    This class is the base of a new non-Extbase and
    non-request dependent backend view. The class is for
    now marked @internal and experimental since we'll
    probably add a factory to configure backend template
    overrides for any backend view later-on.
    
    A few ViewHelpers are changed to work without
    accessing the request if enough VH arguments are provided.
    
    This is the first patch in a series of patches that will
    switch from StandaloneView usages in backend
    controllers to this new BackendTemplateView.
    
    Basic strategy:
    * $view->getRequest()->setControllerExtensionName('SysNote')
      is removed. This is Extbase-specific and not needed nor
      wanted for common non-Extbase controllers.
    * Instantiate the View (for now with makeInstance, will be
      replaced with a factory later-on)
    * Set the needed paths via ->setTemplateRootPaths() etc.
      For these, we *always* use the main extension's entry
      templating paths, for instance
      'EXT:sys_note/Resources/Private/Templates' or
      'EXT:sys_note/Resources/Private/Partials'.
      We do *not* use sub directories here to clear up path
      logic.
    * ->assign() / ->assignMultiple() whatever is needed.
    * ->render('SubDirectory/TemplateName') the actual
      action / template, no '.html' suffix.
    
    As a demo, EXT:sys_note is adapted accordingly which hands
    over arguments to the above mentioned VH's in a way so
    these don't access the request object anymore. The sys_note
    code gets a couple of additional changes so the hooks can
    prepare request dependent arguments and set them as
    template variables (here: returnUrl).
    
    This patch triggers a hidden gem: Since ViewHelpers no
    longer receive an Extbase request, they also don't trigger
    Extbase magic anymore. The casual victim here is
    f:translate, which has already been prepared to not trigger
    Extbase's frontend TypoScript parsing if there is no
    Extbase request. This often improves backend view performance
    by 25% or more, depending on the amount of frontend
    TypoScript to parse.
    
    Further patches will adapt other core backend routes and will
    relate to this patch for reference.
    
    Change-Id: I4fec3ad690452a00e731c9f6928273048397dd89
    Resolves: #96513
    Related: #96473
    Releases: main
    Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72966
    
    
    Reviewed-by: default avatarBenni Mack <benni@typo3.org>
    Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
    Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
    Tested-by: default avatarcore-ci <typo3@b13.com>
    Tested-by: default avatarBenni Mack <benni@typo3.org>
    Tested-by: default avatarOliver Bartsch <bo@cedev.de>
    Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
    37ac299f