Skip to content
Snippets Groups Projects
  1. Aug 02, 2021
    • 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: 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>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      3c78adc6
    • Oliver Bartsch's avatar
      [FEATURE] Introduce TCA type "category" · 1e7653ce
      Oliver Bartsch authored
      A new TCA type "category" is introduced, which
      allows to simplify the configuration of category
      TCA columns. Besides the benefit for integrators,
      this allows to deprecate the CategoryRegistry
      in the next step.
      
      The new type can also be used for other use cases.
      Therefore, the TCA option "relationship" is available
      for this TCA type. Besides "manyToMany" (default), this
      can also be set to "oneToOne" or "oneToMany".
      
      Using the new type, FormEngine will always render a
      category tree. This means, no additional `renderType`
      is defined. In such case, TCA type "select" can
      still be used as before, without any limitation. However,
      all relevant places in core are adjusted in this patch.
      
      The category element is rendered through a custom element
      (web component), reducing inline javascript.
      
      Resolves: #94622
      Releases: master
      Change-Id: I1b95c42288b070fa6bac114266f5ad246a045b21
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69899
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      1e7653ce
    • Nikita Hovratov's avatar
      [BUGFIX] Clean up DataHandler unit tests · d34217be
      Nikita Hovratov authored
      This fixes wrong input configuration, wrong method calls and adds
      some missing test cases.
      
      - The first parameter of assertSame expects the expected value. All
      occurrences in DataHandlerTest, which had them mixed up, are corrected.
      
      - TCA configuration "type => input" corrected.
      
      - Missing test cases with empty string as input added.
      
      Resolves: #94682
      Releases: master
      Change-Id: If31ad11bb1e958fd24b1cbdb7d525d056fe3111b
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70175
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      d34217be
  2. Jul 30, 2021
  3. Jul 29, 2021
  4. Jul 28, 2021
  5. Jul 27, 2021
  6. Jul 26, 2021
  7. Jul 25, 2021
  8. Jul 23, 2021