Skip to content

Protokoll 16.10.2018

Jump to bottom
Dennis Grabowski edited this page Oct 17, 2018 · 1 revision

Datum: 16.10.2018
Uhrzeit: 13:30
Raum: Projektraum 1H.0.20
Protokollant: Dennis Grabowski

Freistehende Kommentare

Die Gruppe hat den Projektleiter daraufhin gewiesen, dass sie die geplante Agenda ggf. unguenstig ist, und sie lieber bedarf bei einem reinen Fokus auf der weiteren Programmierung sowie Ueberarbeitung der Architektur sieht.

Agenda

  • Architektur sowie zu klaerende Probleme
  • Noch bestehende Probleme

Architektur sowie zu klaerenden Probleme

Zunaechst hatte die Gruppe die Diskussion aufgegriffen, ob DTOs oder die Domaenenmodelle an die Views schicken. Nach einer laengeren Diskussion ist der Gruppe aufgefallen, dass die Argumente fuer und gegen beide Vorgehensweise fuer den kleinen Use Case des Projekts ggf. nicht greifen, da die Menge an Business Logic zu klein ist. Da diese Diskussion folglich auf eine reine Praeferenzwahl hinauslaeuft, wurde entschieden, dass die Domaenenmodelle an die Views weiter gegeben werden.
Als naechstes ausstehendes Problem wurde das Handling unserer Policies angegangen. Julius schlug einen Annotation-basierten Ansatz vor. Dieser Ansatz hatte verschiedene Vorteile, beispielsweise Composability, Extensibility, sowie die Tatsache, dass dieser Mechanimus bereits fuer die Authentisierung verwendet wird. Dadurch waere gegeben, dass der selbe Mechanismus fuer das Handling jeglicher Policy genutzt wird.
Nachteil war, dass viel durch den HTTP Context geklaert wurde, und daher nicht simpel ersichtlich war, in welcher Action welche Variablen aus dem HTTP Context gezogen werden koennen. Darueber hinaus ist die Testbarkeit fragwuerdig gewesen. Bei der Entwicklung eines Prototypes ist allerdings bewusst geworden, dass hier technische Barrieren bestehen, die nicht geloescht werden koennen.
Philip schlug vor, dass alle Policies als stumpfe, static methods geschrieben werden, die die Controller nutzen koennen. Das ist ein recht simpler Ansatz, der vorallem sehr simpel zu testen ist. Die Gruppe hat sich auf diesen Mechanimus entschieden.

Ansonsten wurde eine Konvention geschlossen, wie Controller Actions und ihre dazugehoerigen Routes benannt werden sollen. Beschlossen wurde folgende Konvention, am Beispiel der User Resource:

/users           GET    routes.Controller.showUsers()
/users/add       GET    routes.Controller.showAddUser()
/users/add       POST   routes.Controller.addUsers()
/users/delete    GET    routes.Controler.showDeleteUser()
/users/delete    POST   routes.Controler.deleteUser()

Noch bestehende Probleme

Torben & Philip auesserten, dass sie bei der praesentierten DB Integration von Dennis unschoen finden, dass das Model selbst die Queries bereit stellt. Queries sollten lieber unter dem Finder bereit gestellt werden. Das wurde einstimmig unterstuetzt.

Generierte IDs fuer die Models: Das scheint bisher implizit zu funktionieren, muss aber noch ausgiebiger ueberprueft werden.

Sessionmanagement wurde ansonsten ebenfalls ausgiebiger besprochen. Im Issue #14 steht alles besprochene, aber die Gruppe wurde nochmal gebeten, sich darueber Gedanken zu machen.

Clone this wiki locally