1. 24 Sep, 2021 1 commit
  2. 12 Jul, 2021 1 commit
  3. 14 May, 2021 1 commit
  4. 04 Jan, 2021 1 commit
  5. 19 Oct, 2020 1 commit
  6. 15 Apr, 2020 1 commit
  7. 14 Apr, 2020 1 commit
  8. 11 Aug, 2018 1 commit
  9. 18 Jul, 2018 1 commit
    • Christian Kuhn's avatar
      [FEATURE] Allow TCA description property · d421f7dc
      Christian Kuhn authored and Andreas Wolf's avatar Andreas Wolf committed
      When the site configuration module has been introduced, it came
      with a custom functionality to show an additional help text
      when editing site records between the field label and the field input.
      This useful feature is now changed into a general TCA feature
      available everywhere: A new field information node expansion / "wizard"
      is added to all form elements, the inline and flex containers: If
      the property "description" is set for a TCA column type (same array
      level as "label", it will show the value as localized string between
      the field label and the input section.
      There are three available render types for "wizard a-like" output:
      * Field information - text between label+field
      * Field control - buttons next to input sections like the link popup button
      * Field wizards - clickable stuff below the input section, for example
        the localization state selector
      If a field has been set to readOnly=true in TCA, field control and field
      wizards do not make sense to render since they are meant to act with the
      field value.
      The field information node however has only informational character
      which is useful for readOnly fields, too. Thus, this node expansion
      type is now the only one that is always rendered, even if a field has
      been set to readOnly.
      Note this patch is fully covered by ext:styleguide (master) to have
      examples for all changed elements now using the description property.
      Resolves: #85410
      Releases: master
      Change-Id: Idcfacafa19b8208614b653b8fac22ce47bca3b8f
      Reviewed-on: https://review.typo3.org/57397
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: default avatarJörg Bösche <typo3@joergboesche.de>
      Tested-by: default avatarJörg Bösche <typo3@joergboesche.de>
      Reviewed-by: Andreas Wolf's avatarAndreas Wolf <andreas.wolf@typo3.org>
      Tested-by: Andreas Wolf's avatarAndreas Wolf <andreas.wolf@typo3.org>
  10. 25 Apr, 2018 1 commit
  11. 15 Mar, 2018 1 commit
  12. 20 Apr, 2017 1 commit
  13. 31 Mar, 2017 1 commit
  14. 11 Feb, 2017 1 commit
  15. 07 Feb, 2017 1 commit
    • Oliver Hader's avatar
      [FEATURE] Introduce allowLanguageSynchronization · 2fd70c83
      Oliver Hader authored and Christian Kuhn's avatar Christian Kuhn committed
      This feature introduces a new functionality called
      "allowLanguageSynchronization" which can be set on a field
      configuration of a TCA column. This is the successor of
      "l10n_mode=mergeIfNotBlank" as the old option had several
      conceptual downsides:
      1) "mergeIfNotBlank" took the value of the default record
         during runtime, but only if the translation field was empty.
         This means it was not possible to see what the record
         actually contained without having all fields of the parent
         at hand.
      2) It was not possible to have a value "santa" in the original
         record but remove the option in a translation (because an
         empty string "" implicitly triggered the runtime call in the
      3) "mergeIfNotBlank" did not work on relations except for files
         fetched via the FileRepository API calls, but for no other
         inline elements.
      4) "mergeIfNotBlank" did the overlay functionality in the frontend,
         but only FormEngine and DataHandler took care of the option.
         Custom backend modules had to implement the same functionality.
      5) In FormEngine, there was an icon in the translation record that
         if the record kept empty the value of the original language was
         taken, but this is not optimal in terms of usability.
      6) "mergeIfNotBlank" did not take the new l10n_source option into
         account, where localizations could be made from other records
         than the default language "0".
      The new feature can be set on any TCA column setting:
      		['allowLanguageSynchronization'] = true;
      This brings an option to records with translations (both from
      l10n_parent and l10n_source) to have the value for all translations
      synchronized or explictly have a checkbox to use a custom value.
      The information whether a field is custom filled, or kept in sync
      from l10n_parent/l10n_source is stored in a separate field called
      "l10n_state" inside the database.
      The introduced upgrade wizard and TCA migration to remove
      "l10n_mode=mergeIfNotBlank" has been modified to migrate to this
      option and add a l10n_state database field if a TCA table used
      "mergeIfNotBlank" but did not add the l10n_state field manually
      via ext_tables.sql yet.
      New extensions can easily use the new option right away,
      extensions that need to stay compatible with v7 and v8 can add
      both options right away to have the same output.
      The main goals to achieve with this change is now:
      * Have consistent database values for all records regardless
        of l10n_mode=mergeIfNotBlank paving the way to fetch translated
        records without having to overlay (once l10n_mode=exclude is
        also copying values and relations)
      * Be more explicit for editors about records that have a different
        or the same state as their l10n_parent/l10n_source as a benefit
        for bigger instances with a lot of languages
      * Avoid hidden magic when retrieving localized records in the
        TYPO3 Frontend.
      Resolves: #79658
      Related: #79243
      Releases: master
      Change-Id: I6c2dbfeb09b47f958a536c9ab050c24ba4bbcbbd
      Reviewed-on: https://review.typo3.org/51291
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Frans Saris's avatarFrans Saris <franssaris@gmail.com>
      Tested-by: Frans Saris's avatarFrans Saris <franssaris@gmail.com>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  16. 26 Jan, 2017 1 commit
    • Christian Kuhn's avatar
      [!!!][FEATURE] FormEngine element level refactoring · 84be5e61
      Christian Kuhn authored
      The patch introduces a new API on FormEngine element level
      that substitutes the old "wizards" / renderWizard() API
      with a more powerful system.
      Single wizards are now split into one of three categories:
      * An informational wizard
      * A control button / icon
      * A true wizard with additonal functionality
      Method renderWizards() is still called in elements for compatibility
      reasons if people added own scrip/popup/userFunc wizards, but all
      core wizards are migrated.
      The patch significantly cleans the HTML of single elements, especially
      HTML stuff that was added by the SingleFieldContainer is now put down
      to single elements, while main HTML wraps formerly done by renderWizards()
      is fetched "up" to single elements. This gives single elements full
      control about the main HTML it is producing, which is a must have
      preparation in order to further advance in this area and to switch
      single elements to fluid rendering in one of the next steps.
      The patch brings a pretty huge list of TCA changes and
      simplifications, all TCA changes are supported by TCA migration,
      so existing extensions should benefit out of the box and just
      get deprecations logged.
      Change-Id: I45083e14e45bbf40c06267b51c9d0b7c15e2f7ab
      Resolves: #79440
      Resolves: #70032
      Releases: master
      Reviewed-on: https://review.typo3.org/51151
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
      Tested-by: Mona Muzaffar's avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  17. 03 Jan, 2017 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Improve flex and TCA handling in FormEngine · 38a1bc5d
      Christian Kuhn authored and Anja Leichsenring's avatar Anja Leichsenring committed
      The patch adapts a series of nasty form engine areas to more solid
      code. The evaluate condition code is rewritten and works much better
      in flex form scenarios. The suggest wizard and svg tree are much
      more solid in flex forms. The group element is rewritten
      towards a better readable and easier to refactor code, dropping
      method dbFileIcons(). A bunch of issues is resolved along the way.
      * TCA "default" now works in flex form section container elements
      * The "displayCond" parser is now strict and throws exceptions on
        invalid syntax and wrong referenced fields to help debugging
        faulty display conditions
      * TCA displayCond on flex fields can now be prefixed with the
        sheet name and can reference field values from neighbor sheets
      * TCA displayCond now works with flex section containers
      * TCA flex section container now throw an exception if select or
        group fields configure a MM relation - this is not supported
      * TCA ctrl requestUpdate field is dropped, onChange=reload is now allowed
        not only on flex form fields, but also on normal columns fields
      * TCA tree now works as section container element and initializes
        correctly on new records and new containers
      * GroupElement rewrite to drop dbFileIcons()
      * config option maxitems now optional for type=group and type=select
        and defaults to "many items allowed"
      * inline now works in "fancy" flex situations with "new" records
        by handing the final dataStructureIdentifier around
      * FormEngine no longer loads extJS
      Change-Id: Id1d081627529cc1502bb198389e5bd69372815cd
      Resolves: #78899
      Resolves: #72307
      Resolves: #75646
      Resolves: #76637
      Resolves: #72106
      Resolves: #78824
      Resolves: #76793
      Resolves: #68247
      Resolves: #69715
      Related: #78460
      Related: #67198
      Related: #72294
      Releases: master
      Reviewed-on: https://review.typo3.org/50879
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
  18. 01 Dec, 2016 1 commit
  19. 28 May, 2016 1 commit
  20. 17 Apr, 2016 1 commit
  21. 05 Nov, 2015 1 commit
  22. 29 Oct, 2015 1 commit
  23. 08 Oct, 2015 1 commit
  24. 05 Oct, 2015 1 commit
  25. 15 Sep, 2015 1 commit
  26. 13 Sep, 2015 1 commit
  27. 12 Sep, 2015 1 commit
  28. 08 Sep, 2015 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] The FormEngine is dead, long live the FormEngine! · b524fc86
      Christian Kuhn authored
      tl;dr: This patch makes FormEngine insanely flexible, extensions
      however should not rely on structures for now, since class names
      and array content will change.
      The patch applies a separation of concerns to the FormEngine
      class structure by extracting the data processing from rendering.
      As a main goal the render part consisting of container and element
      classes routed through the flexible NodeFactory only works on data
      created by the new FormDataCompiler class construct. This makes the
      FormEngine much more flexible and opens ways to not only use the render
      part in the context of database driven data, but on anything that is
      fed to it.
      This patch creates the main structure for this. The FormDataCompiler
      class returns a defined array container and elements can work on it.
      Data is added by single FormDataProvider, which are combined in
      FormDataGroups. FormDataProvider may depend on each other and a
      FormDataGroup "knows" its providers and calls them in a dedicated order.
      For instance, the "FullDatabaseRecord" FormDataGroup first calls a
      provider that fetches the record defined by uid and table name and
      a later called provider determines the given record type this record
      is assigned to, so another provider can then work on TCA to determine
      the list of record fields to be shown. The FormDataProvider used
      for the main FormDataGroup are defined in TYPO3_CONF_VARS, so
      extensions can add and remove their own providers to add or change
      certain data if needed. This is highly flexible and extensions are
      able to hook in at a specific position within the provider chain for
      the main data groups.
      This construct obsoletes the DataPreprocessor as well as several
      other side classes.
      With this patch the main architecture is created and lots of data
      preparation is transfered already, supported by a high unit test
      The FormEngine class itself is removed: The inline ajax entry point
      is moved to an own controller class, the getMainFields() and friends
      methods are substituted with FormDataCompiler / NodeFactory combinations
      and the data gathering is for now parked in a FormResultCompiler class.
      However, this process is not yet finished and lots of @todo
      statements are added to the code base to document open ends and to
      further separate the data handling from the render engine. Especially
      the IRRE data handling is currently still located within the render
      engine and makes the whole thing much more complicated than it should
      be. Lots of detail patches need to follow to bring this code
      to a level where it belongs to be.
      Warning: While this patch is already insanely huge touching more than
      22 thousands lines of code, lots of loose ends need to be tackled and
      the API is not final yet. The arrays will be reduced and sharpened
      during the next weeks, class names may change and structures will
      Change-Id: Ief1769f478373cc26d1bf6c49114258f0dae8355
      Resolves: #69568
      Releases: master
      Reviewed-on: http://review.typo3.org/41933
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: default avatarFlorian Peters <fpeters1392@googlemail.com>
      Reviewed-by: Mathias Schreiber's avatarMathias Schreiber <mathias.schreiber@wmdb.de>
      Tested-by: Mathias Schreiber's avatarMathias Schreiber <mathias.schreiber@wmdb.de>
      Reviewed-by: Alexander Opitz's avatarAlexander Opitz <opitz.alexander@googlemail.com>
      Tested-by: Alexander Opitz's avatarAlexander Opitz <opitz.alexander@googlemail.com>
      Reviewed-by: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
      Tested-by: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  29. 12 Aug, 2015 1 commit
  30. 14 Jul, 2015 1 commit
  31. 04 Jul, 2015 1 commit
  32. 26 Jun, 2015 1 commit
  33. 03 Jun, 2015 1 commit
    • Christian Kuhn's avatar
      [!!!][FEATURE] FormEngine: The extendables · 0ee65b8f
      Christian Kuhn authored and Anja Leichsenring's avatar Anja Leichsenring committed
      For details, see the ReST files with examples for new API
      and TCA changes.
      * Split TCA config "type" to "type" and "renderType":
        TCA config "type" is a technical debt since it both defines the
        database storage as well as the widget that is used to render
        a certain field in FormEngine. While "type" is kept, the
        render widget is now extracted to a "renderType".
      * t3editor uses this "renderType" now. type=text with
        renderType=t3editor will call the new T3editorElement provided
        by ext:t3editor, and falls back to TextElement if t3editor is
        not loaded.
      * t3editor is now enabled for "setup" and "constants" of
        sys_template records if opening the whole record.
      * t3editor now works when configured in a flex form.
      * Introduce an API in FormEngine NodeFactory to register new
        renderType, used by t3editor.
      * Introduce a resolver API in FormEngine NodeFactory to change
        the class that renders a widget or container.
      * Split TextElement into TextElement that only renders a textarea
        and RichTextElement provided by ext:rtehtmlarea that renders RTE.
        ext:rtehtmlarea uses the new resolver API to route rendering to
        its own class in case RTE is enabled and configured for a field.
      * In TCA section "types" a new array "columnsOverrides" is
        introduced that allows overwriting some column configurations
        of fields. Currently, this works for some View/FormEngine related
        settings like renderType and defaultExtras.
      * TCA Migration is introduced to dynamically rewrite TCA before
        it is put into cache.
      * TCA migration is called a second time in ext:compatibility6 in
        case TCA is still registered via ext_tables.php. This has performance
        penalty since it is done on every frontend and backend call.
      * TCA migration is also called dynamically for flex form definitions.
      * TCA migration moves configured t3editor wizards to type=text with
      * TCA migration removes the 5th parameter "style pointer" from
        types showitem
      * TCA migration moves the 4th showitem parameter "extra configuration"
        to "defaultExtras" of "columnsOverrides" of given TCA type.
      Change-Id: Ia2c2bc16463a01021c7a6be765b4efa872a130fd
      Resolves: #67229
      Releases: master
      Reviewed-on: http://review.typo3.org/39662
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: default avatarFrank Nägler <typo3@naegler.net>
      Tested-by: default avatarFrank Nägler <typo3@naegler.net>
      Reviewed-by: Markus Klein's avatarMarkus Klein <markus.klein@typo3.org>
      Tested-by: Markus Klein's avatarMarkus Klein <markus.klein@typo3.org>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
  34. 18 May, 2015 1 commit
    • Christian Kuhn's avatar
      [TASK] FormEngine: The factory · 86f42bc5
      Christian Kuhn authored
      Creation of container and elements instances in the FormEngine is
      hard coded and hard to overwrite or adapt.
      The patch extends the existing NodeFactory with resolver code to
      find an appropriate class for a given requested type. All FormEngine
      internal container and element requests are now routed through
      NodeFactory. This allows to loosen the strict dependency between
      TCA config "type" to an implementing class by moving the resolving
      code into the factory. This is done for SelectElement which is now
      split into multiple smaller classes - one for each display type. The
      NodeFactory is covered by unit tests since the resolving code will
      become more complex and fine grained in the future.
      As a side effect the patch resolves a hack in the FormDataTraverser
      which no longer calls internal stuff of the select element.
      The NodeFactory is prepared to be extended with an API for extensions
      to steer and overwrite default implementations. This will be added
      with a next patch.
      Change-Id: I2253a0fe3240366d0d271a3cd82119ce3dc52012
      Resolves: #67006
      Releases: master
      Reviewed-on: http://review.typo3.org/39517
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>