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.

Offene Probleme

Vue Versions-update auf 3.2.39

Momentan gibt es mit der neusten Vue Version 3.2.39 ein Problem mit dem Typecheck, da mit dieser Patch-Version Typescript Type-Fehler in Vue behoben wurden (für Details der Fehlermeldungen, siehe Github Actions in der PR vom Dependabot. Behebt man allerdings diese Typecheck-Fehler, dann verlieren die Erklärungen in ExplanationContent.vue die Reaktivität, werden also nicht mehr geupdatet, wenn sich etwas im DataManager verändert. Das gleiche passiert für die Anzeige im DataViewer. Alle Probleme hängen mit der ComputedRef-Funktionalität von Vue zusammen, welche für diese Reaktivität verwendet werden.

Viele Fehler sind von der Form Type 'ComputedRef<T>' is not assignable to type 'T' wobei T in diesem Fall string oder DataModule ist. Man kann diesen Fehler wie folgt beheben: Als Beispiel ist hier das ExplanationContent.vue in Zeile 112 bis 116:

Momentan sieht es so aus, dass InfoCard.vue Strings als Eingabe akzeptiert. Die Argumente wie zB visibilityExplanationTitle sind jedoch vom Typ ComputedRef<string>. Daher der Fehler wie oben beschrieben.

    <InfoCard
      :title="visibilityExplanationTitle"
      :content="visibilityExplanation"
      :source="visibilityExplanationSource"
    />

Man löst dies, indem man bspw visibilityExplanationTitle durch visibilityExplanationTitle.value ersetzt. Dieser Fehler kam vorher nicht auf, da Vue reaktive Komponenten im Template automatisch "unwrapped". Dies scheint nun nicht mehr der Fall zu sein, oder es ist ein Fehler aufseiten von Vue. Behebt man nun den Fehler wie eben beschrieben, verlieren die Komponenten ihre Reaktivität.

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.