Skip to content

GitLab

Switch branch/tag
  1. 04 Jan, 2021 1 commit
  3. 19 Oct, 2020 1 commit
  5. 15 Apr, 2020 1 commit
  7. 14 Apr, 2020 1 commit
  9. 08 Mar, 2020 1 commit
  11. 24 May, 2019 1 commit
    • Andreas Fernandez's avatar
      [!!!][TASK] Refactor client-side IRRE · 0842cea9
      Andreas Fernandez authored and Frank Nägler's avatar Frank Nägler committed 
      This patch refactors the IRRE handling on client side, the JavaScript
land has been rewritten to have a better structure and do less repeating
on-the-fly calculations. Each IRRE container is represented by a
independent instance of InlineControlContainer.

Most of the internally used `scriptCall` directives have been removed.
Currently, `scriptCall` can't get removed completely, as further
refactorings in different areas are required.

All of the "external" communication via `inline.foobar()` has been
replaced by a event-driven approach. This also affects ElementBrowser
windows, those use a minimalistic API based on postMessage.

Some code that was never evaluated in ElementBrowser is considered dead
and has been removed regarding inserting multiple items.

A new sorting library has been added in order to replace jqueryui piece
by piece.

Executed command:

    yarn add --dev sortablejs

On PHP side, some code has been removed as well since the rewritten client
code is event-based and doesn't depend on external calls anymore.

Resolves: #88182
Releases: master
Change-Id: I4176483d2882cef49fbaddb5e2e1914c1f76c908
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/59324

Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
Tested-by: Frank Nägler's avatarFrank Naegler <frank.naegler@typo3.org>
Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
Reviewed-by: Frank Nägler's avatarFrank Naegler <frank.naegler@typo3.org>
      0842cea9
  13. 14 Mar, 2019 1 commit
  15. 14 Jan, 2019 1 commit
  17. 19 Nov, 2018 1 commit
  19. 30 Sep, 2018 1 commit
  21. 27 Sep, 2018 1 commit
  23. 11 Aug, 2018 1 commit
  25. 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>
      d421f7dc
  27. 25 Apr, 2018 1 commit
  29. 15 Mar, 2018 1 commit
  31. 12 May, 2017 1 commit
  33. 20 Apr, 2017 1 commit
  35. 11 Feb, 2017 1 commit
  37. 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
   frontend)

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:

$GLOBALS['TCA'][<table-name>]['columns']
	[<field-name>]['config']['behaviour']
		['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>
      2fd70c83
  39. 05 Feb, 2017 1 commit
  41. 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>
      84be5e61
  43. 04 Jan, 2017 1 commit
  45. 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>
      38a1bc5d
  47. 01 Dec, 2016 1 commit
  49. 28 Sep, 2016 1 commit
  51. 30 Aug, 2016 1 commit
  53. 19 Jul, 2016 1 commit
  55. 17 Apr, 2016 1 commit
  57. 24 Mar, 2016 1 commit
  59. 26 Feb, 2016 1 commit
  61. 28 Jan, 2016 1 commit
  63. 20 Nov, 2015 1 commit
  65. 08 Oct, 2015 1 commit
  67. 22 Sep, 2015 1 commit
  69. 20 Sep, 2015 1 commit
  71. 14 Sep, 2015 2 commits
  73. 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
coverage.

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.

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>
      b524fc86
  75. 06 Aug, 2015 1 commit
  77. 05 Aug, 2015 1 commit