Skip to content

GitLab

Switch branch/tag
  1. 13 Jan, 2022 1 commit
  3. 12 Jan, 2022 1 commit
  5. 08 Dec, 2021 1 commit
  7. 04 Dec, 2021 1 commit
  9. 03 Dec, 2021 1 commit
  11. 02 Dec, 2021 4 commits
  13. 01 Dec, 2021 3 commits
  15. 30 Nov, 2021 4 commits
  17. 29 Nov, 2021 1 commit
  19. 28 Nov, 2021 4 commits
  21. 24 Sep, 2021 1 commit
  23. 16 Sep, 2021 1 commit
  25. 15 Sep, 2021 1 commit
    • Christian Kuhn's avatar
      [TASK] Deprecate ext:backend BackendTemplateView · 98267055
      Christian Kuhn authored 
      The BackendTemplateView is a - usually Extbase backend
module related - Fluid view that adds a default backend
ModuleTemplate to render backend module content.

That implementation has a couple of drawbacks:
* Using BackendTemplateView hides a dependency to the
  request object by triggering a fallback in ModuleTemplate
  accessing $GLOBALS['TYPO3_REQUEST'].
* Using $this->view->getModuleTemplate() is pretty ugly,
  controllers should work with the ModuleTemplateFactory
  instead and retrieve an instance of ModuleTemplate using
  create($request).
* The level of indirection by having ModuleTemplate within
  the view class magically created makes controller actions
  harder to follow and understand.

With extbase Request nowadays implementing ServerRequestInterface
we can get rid of this indirection: Controllers should get an
instance of ModuleTemplateFactory injected, receive the
ModuleTemplate using ->create($request), and add further
title and doc header related details using that instance.

The patch changes ext:indexed_search, ext:extensionmanager and
ext:form to do that, and deprecates BackendTemplateView.

Change-Id: I613a560c8fc3c35343e31f397479f0c008a4a314
Resolves: #95164
Related: #92513
Related: #94428
Related: #94209
Related: #93885
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70973

Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      98267055
  27. 09 Sep, 2021 1 commit
  29. 08 Sep, 2021 1 commit
  31. 04 Sep, 2021 1 commit
  33. 03 Sep, 2021 2 commits
  35. 02 Sep, 2021 3 commits
  37. 26 Aug, 2021 1 commit
  39. 25 Aug, 2021 1 commit
  41. 23 Aug, 2021 1 commit
  43. 12 Aug, 2021 1 commit
    • Nikita Hovratov's avatar
      [FEATURE] Register SoftReference parsers via DI · 48810cb7
      Nikita Hovratov authored and Benni Mack's avatar Benni Mack committed 
      The concept for registration and usage of soft reference parsers
received a complete overhaul.

Starting with the registration, it is now possible to register soft
reference parsers by dependency injection in the extension's
Services.(yaml|php) file. For this, the new tag name
"softreference.parser" has been introduced. One has to provide the
additional attribute "parserKey" to identify the parser. This
replaces the old way of registering these parsers in the $GLOBALS
array. If a parser is registered with the same key in both ways,
the old way takes precedence for b/w compatibility.

This comes with a completely new factory service class
TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserFactory.
This classes' responsibilities are collecting all registered soft
reference parsers and serving them to the consumer by calling the
method "getSoftReferenceParser" with the desired parser key as the
only argument. There is a compatibility layer for the old way of
registration and for classes not implementing the new interface.

Soft reference parsers now have to implement
TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserInterface.
The interface defines the implementation of the "parse" method.
The first 4 and the last parameter stay the same as in the old method
"findRef". The remaining two parameters "spKey" and "spParams" have to
be set with the "setParserKey" method, if they are needed. The key can
be retrieved by using the "getParserKey" method.

The different parser implementations in the old class
TYPO3\CMS\Core\Database\SoftReferenceIndex have been extracted and
moved into dedicated classes in the
TYPO3\CMS\Core\DataHandling\SoftReference namespace. Missing tests
for parsers other than "typolink" and "typolink_tag" are added.

The method makeTokenID of SoftReferenceIndex has been moved into
TYPO3\CMS\Core\DataHandling\SoftReference\AbstractSoftReferenceParser.
A parser can extend this abstract class, if this method is needed.

The methods of BackendUtility "softRefParserObj" and
"explodeSoftRefParserList" are now deprecated and the replacement
TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserFactory
should be used instead.

Resolves: #94687
Resolves: #94741
Releases: master
Change-Id: I460bfdd4478194fa4b4111fc44871f7225c6c084
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70177

Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      48810cb7
  45. 04 Aug, 2021 1 commit
  47. 02 Aug, 2021 1 commit
    • Christian Kuhn's avatar
      [TASK] Deprecate generic extbase domain classes · 3c78adc6
      Christian Kuhn authored 
      Extbase provides a couple of generic domain repositories
and models, especially frontend / backend users and
groups. Those are flawed by design:

The main issue is that domain models have to be specific
for the domain they are used in. By definition, a generic,
opinionated model can't be "correct" since the domain
it is used in, is unique: It might be that a backend user
email has to be set and the domain does not model
anything but email and firstname?

Many usages don't need backend groups attached to a
backend user model at all, or if they need them, then
maybe in a recursive presentation, or a specific order
or something similar. Having a default group resolution
is thus at least misleading, if not wrong, and can be a
performance issue on top.

A generic model can never foresee its usages. The existing
models thus try to 1:1 adapt the database fields, which
is also misleading since a domain model is not and should
not be a direct representation of a database table. It
would only be by chance if the generic models fit a
specific domain.

Similar issues exist with the repositories: The
CategoryRepository for instance assumes it is a good
idea to set respectStoragePid(false), which is most
likely not the right thing for an extension use.
In the end, whatever extbase delivers here, is most
likely wrong and does not fit the problem domain.

The patch keeps the 'experimental' FAL related models
since those can be actually useful for extensions and
their final fate has not been decided, yet. The other
generic models, especially those with lots of properties
are marked as deprecated with the patch.

Change-Id: I06629fddd0258c517f3fa8bdf2e9c4b342be9678
Resolves: #94654
Related: #83296
Releases: master
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70061

Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      3c78adc6
  49. 23 Jul, 2021 1 commit
  51. 18 Jun, 2021 1 commit