fraport/fradrive-old
fraport/fradrive-old
Archived
3
1
Fork 0
Code Issues 65 Pull Requests 5 Actions Packages Projects Releases 197 Wiki Activity

DBTable: Kein automatisches Filtern bei Input-Change, sondern manuelle Übernahme via Button #130

New Issue
Open
opened 2023-10-17 00:53:24 +02:00 by savau · 9 comments
savau commented 2023-10-17 00:53:24 +02:00 (Migrated from gitlab.uniworx.de)
Copy Link

Status Quo

Auf DBTables werden Frontend-Utils (async-table) initialisiert, welche dafür sorgen dass Änderungen an den Filter- und Sortier-Funktionen der DBTable asynchron Backend-Requests absetzen, verarbeiten und (bei Response) asynchron das entsprechende Frontend-DOM ersetzen.

Problem

Die async-table Funktionalität funktioniert an und für sich zwar wie erwünscht, bei größeren Tabellen (d.h. vielen Zeilen) dauert dieser gesamte Prozess aktuell allerdings so lange, dass das ursprünglich als Usability-Feature gedachte asynchrone Nachladen die Usability eher negativ als positiv beeinträchtigt. Das geht auch vermehrt aus User-Feedback aus den Fahrschulen hervor.

TODO

Das asynchrone Abarbeiten von DBTable-Änderungen soll daher wieder synchron werden, indem erst alle gewünschten Änderungen an der DBTable-Ansicht vorgenommen werden, welche dann manuell über einen Submit-Button übernommen werden sollen. Dieser Submit-Button soll dann einen „echten“ Page Reload triggern, mit den gewünschten Änderungen via GET-Parametern.

Bei kleineren Tabellen könnte man die asynchrone Funktionalität beibehalten; bei größeren Tabellen via Backend deaktivieren.

Allgemein

  • Noch zu überlegen/diskutieren: Neues Frontend-Util (siehe sync-table unten) für gewünschte Funktionalität, oder Erweiterung von bereits existierendem async-table Util (d.h. Weichen einbauen für synchrone Verarbeitung und Umbenennung des Utils in z.B. dbtable)?
  • An allen Usage Sites von DBTables einzeln überlegen, wie lange die entsprechende DBTable üblicherweise zum Laden braucht und ggf. manuell synchrones Laden setzen (unabhängig von Anzahl Zeilen; manche DBTables haben bereits pro einzelner Zeile eine längere Ladezeit da viele Joins oder anderweitig rechenintensiv!)

Backend

  • Weiche implementieren, welche abhängig von der Anzahl Zeilen einer DBTable dem Frontend signalisiert, entweder das async-table oder ein neues sync-table Frontend-Util zu laden

Frontend

  • Neues sync-table Frontend-Util implementieren, welches eine synchrone Abwandlung von async-table sein soll:
    • Zustand der Filter/Sortierer/etc. der DBTable on change persistieren (GET Params setzen)
    • Reload/Submit-Button implementieren, der aktuell gesetzte Tabellen-Einstellungen in GET-Params übersetzt (analog zu async-table) und dann aber statt asynchron zu verarbeiten einen Page Reload triggert
      • Usability-Frage: Wo soll der Button hin?
      • Evtl. custom styling des Buttons: Einfacher kleiner Knopf mit Reload-Symbol („Kreis-Pfeil“)?
# Status Quo Auf `DBTable`s werden Frontend-Utils (`async-table`) initialisiert, welche dafür sorgen dass Änderungen an den Filter- und Sortier-Funktionen der `DBTable` asynchron Backend-Requests absetzen, verarbeiten und (bei Response) asynchron das entsprechende Frontend-DOM ersetzen. ## Problem Die `async-table` Funktionalität funktioniert an und für sich zwar wie erwünscht, bei größeren Tabellen (d.h. vielen Zeilen) dauert dieser gesamte Prozess aktuell allerdings so lange, dass das ursprünglich als Usability-Feature gedachte asynchrone Nachladen die Usability eher negativ als positiv beeinträchtigt. Das geht auch vermehrt aus User-Feedback aus den Fahrschulen hervor. # TODO Das asynchrone Abarbeiten von `DBTable`-Änderungen soll daher wieder synchron werden, indem erst alle gewünschten Änderungen an der `DBTable`-Ansicht vorgenommen werden, welche dann manuell über einen Submit-Button übernommen werden sollen. Dieser Submit-Button soll dann einen „echten“ Page Reload triggern, mit den gewünschten Änderungen via GET-Parametern. Bei kleineren Tabellen könnte man die asynchrone Funktionalität beibehalten; bei größeren Tabellen via Backend deaktivieren. ## Allgemein - [ ] Noch zu überlegen/diskutieren: Neues Frontend-Util (siehe `sync-table` unten) für gewünschte Funktionalität, oder Erweiterung von bereits existierendem `async-table` Util (d.h. Weichen einbauen für synchrone Verarbeitung und Umbenennung des Utils in z.B. `dbtable`)? - [ ] An allen Usage Sites von `DBTable`s einzeln überlegen, wie lange die entsprechende `DBTable` üblicherweise zum Laden braucht und ggf. manuell synchrones Laden setzen (unabhängig von Anzahl Zeilen; manche `DBTable`s haben bereits pro einzelner Zeile eine längere Ladezeit da viele Joins oder anderweitig rechenintensiv!) ## Backend - [ ] Weiche implementieren, welche abhängig von der Anzahl Zeilen einer `DBTable` dem Frontend signalisiert, entweder das `async-table` oder ein neues `sync-table` Frontend-Util zu laden ## Frontend - [ ] Neues `sync-table` Frontend-Util implementieren, welches eine synchrone Abwandlung von `async-table` sein soll: - [ ] Zustand der Filter/Sortierer/etc. der `DBTable` on change persistieren (GET Params setzen) - [ ] Reload/Submit-Button implementieren, der aktuell gesetzte Tabellen-Einstellungen in GET-Params übersetzt (analog zu `async-table`) und dann aber statt asynchron zu verarbeiten einen Page Reload triggert - [ ] Usability-Frage: Wo soll der Button hin? - [ ] Evtl. custom styling des Buttons: Einfacher kleiner Knopf mit Reload-Symbol („Kreis-Pfeil“)?
jost commented 2023-11-07 10:41:41 +01:00 (Migrated from gitlab.uniworx.de)
Copy Link

assigned to @savau

assigned to @savau
savau commented 2024-05-23 17:46:05 +02:00 (Migrated from gitlab.uniworx.de)
Copy Link

changed the description

changed the description
savau commented 2024-05-23 17:46:16 +02:00 (Migrated from gitlab.uniworx.de)
Copy Link

assigned to @mosbach and unassigned @savau

assigned to @mosbach and unassigned @savau
mosbach commented 2024-06-03 02:23:27 +02:00 (Migrated from gitlab.uniworx.de)
Copy Link

created branch 130-dbtable-kein-automatisches-filtern-bei-input-change-sondern-manuelle-ubernahme-via-button to address this issue

created branch [`130-dbtable-kein-automatisches-filtern-bei-input-change-sondern-manuelle-ubernahme-via-button`](/fradrive/fradrive/-/compare/master...130-dbtable-kein-automatisches-filtern-bei-input-change-sondern-manuelle-ubernahme-via-button) to address this issue
mosbach commented 2024-07-01 03:48:12 +02:00 (Migrated from gitlab.uniworx.de)
Copy Link

created branch 130-dbtable-kein-automatisches-filtern-bei-input-change-sondern-manuelle-ubernahme-via-button-2 to address this issue

created branch [`130-dbtable-kein-automatisches-filtern-bei-input-change-sondern-manuelle-ubernahme-via-button-2`](/fradrive/fradrive/-/compare/master...130-dbtable-kein-automatisches-filtern-bei-input-change-sondern-manuelle-ubernahme-via-button-2) to address this issue
mosbach commented 2024-07-01 03:49:24 +02:00 (Migrated from gitlab.uniworx.de)
Copy Link

mentioned in merge request !34

mentioned in merge request !34
mosbach commented 2024-07-01 03:52:31 +02:00 (Migrated from gitlab.uniworx.de)
Copy Link

mentioned in merge request !35

mentioned in merge request !35
jost commented 2024-07-29 08:33:55 +02:00 (Migrated from gitlab.uniworx.de)
Copy Link

Die Fahrerausbildung hat sich erneut über dieses Problem beschwert. Bei einigen Suchen (leider unklar welcher) ist das Problem so groß, dass es zu Verbindungsabbrüchen durch Timeouts führt.

Die Fahrerausbildung hat sich erneut über dieses Problem beschwert. Bei einigen Suchen (leider unklar welcher) ist das Problem so groß, dass es zu Verbindungsabbrüchen durch Timeouts führt.
jost commented 2024-07-29 08:34:22 +02:00 (Migrated from gitlab.uniworx.de)
Copy Link

mentioned in issue #2

mentioned in issue #2
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
Aufwand: Hoch

   
Aufwand: Mittel

   
Aufwand: Niedrig

   
Blockiert

   
Diskussion

Benötigt Klärung, noch nichts zu implementieren

  
Dokumentation

Won't fix

  
Frontend

   
Konfigurationsproblem

Kubernetes, Nix, etc.

  
Prio: Angehalten

Kann jetzt noch nicht gelöst werden, da noch Abhängigkeiten bestehen

  
Prio: Blocker

   
Prio: Hoch

   
Prio: Mittel

   
Prio: Niedrig

   
Prio: Unbedeutend

   
Prüfung ausstehend

Problem vermutlich behoben, muss aber noch beobachtet oder getestet werden

  
Schnittstelle

   
Schnittstelle: APC

   
Schnittstelle: AVS

   
Schnittstelle: LMS

   
Schnittstelle: SAP

   
Uni2Work

Wird in Uni2work behoben und später portiert

  
UniWorX

Ordered from and appointed to UniWorX Systems LLC

  
Working

This issue is currently being worked on; probably within a branch

No Label
Aufwand: Hoch
Aufwand: Mittel
Aufwand: Niedrig
Blockiert
Diskussion
Dokumentation
Frontend
Konfigurationsproblem
Prio: Angehalten
Prio: Blocker
Prio: Hoch
Prio: Mittel
Prio: Niedrig
Prio: Unbedeutend
Prüfung ausstehend
Schnittstelle
Schnittstelle: APC
Schnittstelle: AVS
Schnittstelle: LMS
Schnittstelle: SAP
Uni2Work
UniWorX
Working
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: fraport/fradrive-old#130
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?