Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Number formatting / Locale #32

Open
OpenXE-ERP opened this issue Nov 17, 2022 · 9 comments · Fixed by #95
Open

Number formatting / Locale #32

OpenXE-ERP opened this issue Nov 17, 2022 · 9 comments · Fixed by #95
Labels
enhancement New feature or request

Comments

@OpenXE-ERP
Copy link
Contributor

Formatting of Numbers in SQL use $this->app->erp->FormatMenge or $this->app->erp->FormatBetrag ONLY for display, NEVER for use in calculations.

For output formatting must be done with locale... (where? how? what?)

@OpenXE-ERP
Copy link
Contributor Author

FormatMengeBetrag() but it is not used
FormatMenge() but it is to be used inside SQL statements...

-> All crap. Separation of DB and UI must be designed from scratch.

@rrusch
Copy link
Contributor

rrusch commented Aug 10, 2023

Ich könnte mir folgendes Vorgehen vorstellen:

  1. FormatMenge zurück zur ursprünglichen Version mit TRIM()+0)
  2. Implementation einer Locale-Erkennung
  3. Implementation eines Input-Parsers auf Basis der PHP NumberFormatter Klasse
  4. Umbau der FormatMenge auf FORMAT mit Locale
  5. Implementation eines Output-Formatters auf Basis der PHP NumberFormatter Klasse und Locale

So hätten wir am Schluss beide Möglichkeiten für die Ausgabe, ohne dass wir den ganzen DB-Spaghetticode auseinandernehmen müssen. Sollte der Datenbank-Zugriff irgendwann über eine Abstraktion gelöst werden, fällt FormatMenge dann weg.

@OpenXE-ERP
Copy link
Contributor Author

FormatMenge sollte nur für die reine Anzeige verwendet werden mit korrekter Darstellung der Locale des Nutzers oder Browsers. (Browser wäre besser, damit es einheitlich ist). Vorschlag, wenn decimals nicht angegeben, Nullen am Ende entfernen mit trim.

Für das Laden von Eingabemasken ggf. eine neue Funktion anlegen die korrekt formatiert für die Verarbeitung in der Maske (trim). die Lokalisierung macht der Browser. Das Zahlenformat muss dabei ohne Tausenderzeichen sein, Dezimalzeichen ist der Punkt, Nullen am Ende sind nicht erlaubt.

@OpenXE-ERP
Copy link
Contributor Author

Nachtrag: Formatierungen über Javascript sind zu vermeiden.

@rrusch
Copy link
Contributor

rrusch commented Aug 11, 2023

Also die Lokalisierung über den Browser funktioniert nach meiner Erfahrung nicht zuverlässig und auch nicht einheitlich.

Javascript ist auch nicht mein Favorit, obwohl ich da schon ansprechende Lösungen gesehen habe.

Bleibt also nur noch die Formatierung serverseitig. Und die brauchts sowieso.

Und für alle Lösungen braucht es eine Ermittlung der Locale. Siehe PR #95.

@OpenXE-ERP
Copy link
Contributor Author

Anmerkung: Für die Darstellung im PDF muss die Locale der Adresse genommen werden.

@rrusch
Copy link
Contributor

rrusch commented Aug 14, 2023

Danke für den Hinweis. Ich werde die \Xentral\Components\I18n\Localization erweitern mit einer Funktion, um einen Klon basierend auf der Adresse zu erzeugen.

@rrusch
Copy link
Contributor

rrusch commented Aug 26, 2023

Im PR #100 implementiere ich die konkreten Formatierungsfunktionen. Details siehe im PR.

@OpenXE-ERP
Copy link
Contributor Author

Im Tablesearch wird bei Verwendung von $sumcol und $numbercols die Summe falsch zusammengerechnet.

@OpenXE-ERP OpenXE-ERP linked a pull request Feb 8, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants