Tabellarische Auflistung der Begehungsdaten - MOCK
Da aktuell noch keine Möglichkeit der Datenübermittlung von Begehungsdaten besteht. Wird vorerst ein View zur Listung von Funden erstellt in Tabellenform.
In der Tabelle ist für jede Begehung folgende Information als Attribut zu erkennen:
- Datum
- Transekt (Name)
- Anzahl der beobachteten Arten
- Anzahl der beobachteten Individuen
Diese Attribute sind in gegebener Reihenfolge in je eine Spalte eingeordnet. (Rechts dieser Spalten befindet sich eine weitere: "Aktionen". Hier kann man zu einer Detailansicht der Begehung gelangen (Kopf- und Fußdaten).
Links ist jede Zeile mit einem Kästchen ausgestattet über welches man eine, mehrere oder auch alle- (ganz oben auswählbar) Begehungen auswählen kann. Dies dient der Auswahl der Begehungen für die Anzeige/Export/Analyse.
Schema:
- Datum (Spalte 1)
- Transektname (Spalte 2)
- Wetterdaten (Temp, Wind, Bewölkung)
- Beobachter
- Anzahl der beobachteten Gattung (Spalte 3)
- Liste von Gattungen (Gattung-1, Gattung-2, Gattung-3)
- Anzahl der beobachteten Arten (Spalte 4)
- Liste von Arten (Art-1, Art-2, Art-3)
Modularisierung/ Wiederverwendbarkeit
-
Hauptkomponente für Tabelle -
Nested Komponenten für Tabellenzeile (siehe Ticket) -
Filterkomponente ist vorhanden (siehe Ticket) -
Spaltensortierung ist vorhanden (siehe Ticket)
AKs:
-
View für Begehungsdatenübersicht existiert und ist aufrufbar -
i18n -
Tabellenkomponente existiert und ist eingebunden -
Mockschema ist erstellt für 10 Elemente -
Unittest -
Weiterleitung von Editieren auf Einzelview (Begehung) - erstmal statisch mit leeren Begehungsdaten -
Modularisierung ist wie oben umgesetzt und anhand der Komponentstruktur nachvollziehbar - aber Logik der Zusatztickets wird hier nicht betrachtet
Review:
-
View für Begehungsdatenübersicht existiert und ist aufrufbar -
i18n -
Tabellenkomponente existiert und ist eingebunden -
Mockschema ist erstellt für 10 Elemente -
Unittest -
Weiterleitung von Editieren auf Einzelview (Begehung) - erstmal statisch mit leeren Begehungsdaten -
Modularisierung ist wie oben umgesetzt und anhand der Komponentstruktur nachvollziehbar - aber Logik der Zusatztickets wird hier nicht betrachtet
[4-5 PT - für Hauptkomponenten]