Dokumentation zum Massive Multiplayer Online Game - Universität ...

5. Spieler, Allianzen und Nachrichten
83
self.destroy #action done
elsif
[...]
end
end
Controller
Nutzer dürfen den Request Controller nur ansteuern, wenn sie als gültiger Nutzer in Devise authentifizert sind:
before_filter :authenticate_user!
Im Controller existieren zwei Methoden: create und reaction. Diese sind über das HTTP-Verb Post unter den
Adressen /requests und /requests/reaction erreichbar. Nach der Implementierung dieser 2 Methoden ist uns
aufgefallen, dass wir den Controller mit weiteren Kontrollstrukturen versehen müssen. So sollte beispielsweise
kein Nutzer in eine Allianz eingeladen werden können, der bereits zu einer anderen Allianz gehört. Des Weiteren
sollte man auch keine Freundschaftsanfrage an Nutzer schicken können, die bereits in der Freundesliste des
Senders existieren. Die beiden Methoden create und reaction akzeptieren nur die Aktionen, die tatsächlich
im System eingepflegt sind und beachten die soeben beschrieben Umstände.
create ist für die Erstellung von Requests zuständig. Diese Methode validiert die vom Browser übertragenen
Parameter, ermittelt den Empfänger, erstellt bei Validität den Request und pflegt alle nötigen Parameter ein.
Danach wird auf dem Requestmodel die oben beschrieben Methode decide_notify() aufgerufen.
reaction verarbeitet Antworten auf existierende Requests. Die Methode bekommt den zu einem Request
gehörigen SHA1-Hash vom Browser übermittelt. Des Weiteren wird vom Browser der Parameter 'answer'
übermittelt, der entweder 'no' oder 'yes' als Zustand haben kann. Nachdem überprüft wurde, ob der
anzusprechende Request existiert und der Nutzer, der eine Browseranfrage an diese Methode gesendet hat,
berechtigt ist, auf diesen Request zu antworten, wird je nach Antwort entweder direkt das Requestobjekt zerstört
oder aber die zugehörige Aktion auf dem Model ausgeführt.
Nach Abhandlung einer dieser beiden Methoden wird der Nutzer auf die Startseite zurückgeleitet und über
eine Notiz über Erfolg oder Misserfolg der entsprechenden Browseranfrage informiert.
View
Aufgrund unserer Modellierung auf Applikationsebene wurde keine konkrete View für Requests gebraucht. Wir
mussten lediglich in den Views, in denen das Requestsystem greifen soll, die Zieladressen der Buttons und
dessen Parameter auf den Request Controller umleiten. Bei unserer Gruppe war von den Änderungen die View
der Allianzbearbeitung zum Einladen von Nutzern und die Freundesliste betroffen. Des Weiteren haben wir die
Routen auf die Ursprünglich für diese Aufgaben vorgesehenen Controller entfernt.
| Abb.6: Einladedialog in der Allianzbearbeitung