Developer Guidelines Naechste Schritte

Nächste Schritte

Spezifische Schritte zum Erweitern der Funktionalität

Erweitern eines DataFields um ein Attribut

Was muss man tun, wenn man ein Attribut zu einer DataField-Unterklasse hinzufügen möchte?

Beispielsweise soll jeder User auch noch ein Adress-Feld haben.

1. Füge das Attribut zu der Klasse hinzu. Dieses muss public sein und mit den entsprechenden Decorators versehen werden. In diesem könnte dies so aussehen:

   import { Expose, Type } from "class-transformer";
   export class User extends DataField {
     // ...
   
     @Expose()
     @Type(() => Address)
     address: Address;
   }

2. Erweitere das DataField-Enum um den neuen Datentyp:

   export enum DataField {
     // ...
     UserAddress = "address",
   }

3. Erstelle einen neuen Eintrag im public/data/risk/risk.json mit den entsprechenden Werten für den Datentyp. In diesem Fall könnte dies so aussehen:

   {
     "dataType": "UserAddress",
     "riskLevel": "Medium",
     "roleVisibility": ["Company", "User"],
     "explanation": {
       "retentionPeriod": "stored_until_no_longer_necessary",
       "riskLevelExplanation": {
         "translationKey": "medium_risk_explanation",
         "source": "https://gdpr-info.eu/issues/personal-data/"
       }
     }
   }

   Der dataType-Wert muss mit dem in Schritt 2 definierten Key (hier UserAddress) des Enums übereinstimmen.

4. Füge einen neuen Eintrag für die Übersetzungen in locales/explanations/explanation{ DE|EN }.json hinzu:

   {
     "address": {
       "isVisible": "Erklärung, wenn der Datentyp in der momentanen Rolle sichtbar ist.",
       "isNotVisible": "Erklärung, wenn er nicht sichtbar ist"
     }
   }

   Möchte man keine individuelle Erklärung schreiben, kann man die Standard-Erklärungen benutzen:

   "address": {
      "isVisible": "@:explanation.data_is_visible",
      "isNotVisible": "@:explanation.data_is_not_visible"
    }

   Man kann einen Bezug zur aktuellen Rolle einbauen, indem man den Platzhalter { role } im Erklärungs-String benutzt.

5. Füge die Übersetzung für den Datentyp selbst hinzu: In locales/{de|en}.json, füge unter data den neuen Key (hier address) mit der Übersetzung hinzu.

6. Falls die Tests trotzdem fehlschlagen, müssen die Daten im src/backend/__tests__/data angepasst werden. Hier müsste die user-Liste in expectedData.ts angepasst werden.

Verbesserungsvorschläge

Einige optionale Features konnten bei der Entwicklung nicht umgesetzt werden. Hier werden einige Vorschläge genannt, was in der momentanen Version noch verbessert werden könnte.

1. Zufällige Generierung der Daten. Die Daten werden momentan statisch in json-Dateien definiert und zur Laufzeit eingelesen. Die definierten Daten sind zwar größtenteils zufällig generiert worden, wechseln aber nicht bei jedem Laden der Website neu. Die Funktionalität dafür wurde im RandomDataGenerator bereits größtenteils implementiert. Jedoch muss dies in den DataManager integriert werden. Dafür könnte eine Schnittstelle des DataLoaders definiert werden, und dann ein Adapter (z.B. class RandomDataLoader implements DataLoader) umgesetzt werden, der dann im DataManager benutzt werden kann. Dazu muss aber auch der DataManager geringfügig abgeändert werden.
2. Company-Dropdown. Es wäre hilfreich, wenn der Nutzer ein bestimmtes Unternehmen filtern könnte, z.B. KVV. Dazu könnte in der Navigationsleiste anstatt des Buttons Company eine Drop-Down Liste aller Unternehmen implementiert werden. Bei Auswahl eines bestimmten Unternehmens, werden dann zB nur die Fahrzeuge dieses Unternehmens angezeigt.
3. Analog zum Company-Dropdown könnte ein User-Dropdown implementiert werden. Dies wurde allerdings von uns bewusst nicht umgesetzt, da es Verwirrung stiften könnte. Denn das würde bedeuten, dass alle Daten von Trips, die nicht zum ausgewählten User gehören, zensiert werden müssten. Dasselbe Problem kommt allerdings auch beim Company-Dropdown auf.
4. Echzeit-Standorte von Nextbike-Fahrrädern. Es könnte die Nextbike-API angefragt werden, um echte Standorte von Nextbike Fahrrädern auf der Karte anzuzeigen. Damit könnten deutlich mehr inaktive Fahrräder angezeigt werden, wenn man noch ein Leaflet-Plugin für Marker-Cluster einbaut.
5. Unterstützung für mehr User pro Fahrzeug. Momentan wird jedem Fahrzeug ein Trip und damit ein User zugeordnet. Insbesondere bei öffentlichen Fahrzeugen wie Bussen oder Bahnen wäre es aber interessant, wenn mehrere Nutzer denselben Bus benutzen könnten.
6. Einen Trip-Kreislauf implementieren. Momentan muss nach einer bestimmten Zeit Reset gedrückt werden, weil alle Trips fertig abgefahren sind und sich daher nichts mehr auf der Karte bewegt. Man könnte aber für jeden Trip einen Vor- und Nachfolger definieren, sodass ein Trip-Kreislauf entsteht. Dazu benötigt man dann auch im TripAnimator die activeTrips-Liste, denn dann werden nicht alle definierten Trips jederzeit animiert. Wenn ein Trip fertig ist (über die Trip::isFinished-Methode feststellbar), dann könnte der TripAnimator den Trip aus der activeTrips Liste entfernen und den Nachfolger des Trips hinzufügen.