Project

General

Profile

Actions

Epic #86022

closed

Backend-Form-Elements - Evaluation is an epic mess.Custom DateTimePicker DateFormats lead to values not being shown (though format is correct of course), itemsProcFunc is not evaluated for web_list overview and many more bugs

Added by Oliver Kleinecke almost 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
-
Target version:
-
Start date:
2018-08-29
Due date:
% Done:

0%

Estimated time:
Sprint Focus:

Description

I have a german TYPO3 installation, used in professional, productive surrounding. It is really important for me, to be able to define "sane" localized settings and regional formats (currencies, date/datetime) .. ideally in one single point in system settings, which should then be obeyed by any included resource (js datetimepicker and others).

Currently, the whole eval - section of input fields in TCA is a pure mess (sorry, but I have to say that, it is just true). - There are only few predefined formats set, that cant be changed, and just fit for US-american usage - localization of Backend-RecordList-Records is just not possible without modifying the core. No Docs available on how to change JS-default-settings (have to look up everything in code -.-)
If someone files a bug towards that, devs just say "gnaaah this is important for 1% of the users only"... which I think is basicly ridiculous. As I said : I have to work with typo3 (!! otherwise I`d already run away .. localization and datahandling in backend is just such an epic, epic mess, stealing weeks of time for nothing)
I can`t understand why you are bothering so many users to write their completely own record-list modules, only because a few devs never have experienced, how bad it is, not to be able to localize important data-record-values to the format used in their living place.

Just to make sure you get what the problem is : Try to build a custom extbase domain model that displays exact timestamps (datetime with seconds!) in german localized format. If you use ItemsProcFunc to use your own renderer : Overview-Recordlist-Field still shows the pure db-value (itemsprocfunc not evaluated).
If you want to add seconds/change the format : no way. Use ItemsProcFunc with the above stated downside. If you modify the core yourself : wow.. do the same thing every 2 weeks, whenever there is a new minor-update. Contributing the changes to the core : nearly impossible for non-24/7-typo3-devs, because the code-review downranks contributions for insane reasons, like slightly/minimal imperfect text-formatting (a space too much and the contribution is dead.)

I really want to ask you in general : Do you think it will help, stopping people from contributing this way ? Rather have no more contributions, so that a code-reviewer has less work to reformat stuff? Well, yep .. code-reviewers won`t have much to do in future I suppose.
Coding + Contribution Guidelines are really important and I see and emphasize that. But you are going much too far with the current system, what results in a open-source-project where few people are still able to contribute.

I think datahandling-routines and the ability to render values in a custom, desired format is such an essential thing, that it should be put up much further on top in the current agenda.

If you think I should review my language and stuff : please consider the weeks of work and effort I put into nothing and then being told : "AAAh this is just not important" .. well .. if you are an american .. maybe not. For everyone else in the world : this is really really really bad.
Also : where can I find Docs about TYPO3-JS-default-settings ?! The documentation lacks a lot of info about all those things.

Actions

Also available in: Atom PDF