Warning: include_once(/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php): failed to open stream: No such file or directory in /var/www/html/fields/dbp13/local/config.php on line 4

Warning: include_once(): Failed opening '/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php' for inclusion (include_path='.:/opt/php/lib/php') in /var/www/html/fields/dbp13/local/config.php on line 4

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/fields/dbp13/local/config.php:4) in /var/www/html/pmwiki-2.2.86/pmwiki.php on line 1250
Datenbankpraktikum SS 2013 - MMOG - Schiffe Und Missionen Reports

Berichte

von Alexander Löhr

Aufgabenstellung:

Informiere den Benutzer über den Ausgang von Missionen. Dazu ist es notwendig die Daten zum Zeitpunkt des Ereignisses zu erfassen, abzuspeichern und dem Benutzer die Möglichkeit zu geben, die Daten einzusehen.

Realisierung:

Dies soll mittels Berichten gelöst werden. Für jede Missionstypen gib es einen speziellen Bericht, der alle Informationen als Attribute oder mittels Beziehungen abspeichert. Da es 5 Missionstypen gibt, gibt es auch 5 Berichtstypen:

  • Battlereport: Gibt Auskunft über den Ausgang eines Kampfes.
  • Colonisationreport: Informiert, welcher Planet kolonisiert wurde.
  • Spyreport: Enthält Informationen über den Ausspionierten Planet.
  • Tradereport: Beinhaltet Anzahl an Ressourcen, die an einen anderen Planeten geschickt wurden.
  • Travelreport: Zeigt welche Schiffe von einem Planeten zum anderen gereist sind.

Datenbankentwurf:

Der Mittelpunkt des Entwurfs sind die Entitäten Battlereport, Colonisationreport, Spyreport, Tradereport, Travelreport.

Da dieses Entitäten eine identische Teilmenge an Attributen haben, ist es sinnvoll diese in eine allgemeine Entität auszulagern. Deshalb wurden die Attribute Herkunft, Herkunftsplanet, Ziel, Zielplanet und Ereigniszeitpunkt in die Entität Report verschoben und mit den verschiedenen Berichtstypen mittels einer polymorphen 1 zu 1 Beziehung verbunden.

Weiterhin stehen Reports in einer N zu M Beziehung mit Usern, welche die Empfängerliste des Reports darstellt. Das Attribut "read" an der Beziehung ermöglicht es zu erfassen, ob ein Report von einem User schon gelesen wurde.

Die Verschiedenen Berichtstypen habe noch weitere Attribute und Beziehungen, die zum Speichern der notwendigen Informationen dienen.

Model:

Die Models der Berichtstypen beinhalten neben den Beziehungen noch jeweils eine Instanzmethode finish_report(...). Nach dem erstellen einer Instanz werden mittels dieser Methode dem Bericht die Informationen übergeben und abgespeichert.

Battlereport:

Dabei sticht der Battlereport heraus, da er zusätzlich noch die Methode init_report(...) besitzt, mit der die Informationen vor dem Kampfgeschehen übermittelt werden.

Spyreport:

Im Spyreport wird das Spylevel einer Spionageaktion erechnet:

def calc_spylevel(atk_spy_factor, def_spy_factor)
	spy_factor = atk_spy_factor - def_spy_factor
 
	r = rand 0.6..1.1
 
	spy_factor *= r
 
	spy_factor = (spy_factor + 1)* 0.5
 
	if spy_factor > 0.7
		self.spylevel = 4
	elsif spy_factor > 0.5
		self.spylevel = 3
	elsif spy_factor > 0.3
		self.spylevel = 2
	elsif spy_factor > 0.05
		self.spylevel = 1
	else
		self.spylevel = 0
	end		
end

Je nach Spylevel werden mehr Informationen über den ausspionierten Planeten und dessen Besitzer angezeigt:

Informationen\Spylevel01234
Schiffe auf dem Planeten    x
Technologien   xx
Gebäude  xxx
Planetinformationen xxxx

Controller:

Für alle Berichte wird nur der reports_controller verwendet.

Index:

Die Index-Methode des Controllers holt alle Berichte eines Users und sortiert diese nach gelesen/ungelesen und nach Datum. Da nur die allgemeinen Berichte für die Index-View benötigt werden, kommt hier die polymorphe Beziehung zum tragen und man benötigt nur einem Query.

Show:

Die Show-Methode holt sich zu einem Bericht den speziellen Bericht und entscheidet dynamisch je nach Bericht, welche View angezeigt werden soll. Zusätzlich werden alle benötigten Informationen vorgeladen, damit möglichst wenig Querys abgesetzt werden müssen, dies geschieht wieder dynamisch, je nachdem welcher Berichtstyp vorliegt.

def show
    if @report.nil? || !@report.receiver_ids.include?(current_user.id)
            redirect_to reports_path, notice: "Der angeforderte Bericht existiert nicht."
    else
      ReceivingReport.where(user_id: current_user.id, report_id: @report.id).first.update_attribute :read, true
      respond_to do |format|
        format.html { render "show_#{@report.reportable_type}" }
        format.js
      end
    end
  end
destroy:

Ruft die Destroy-Methode des Reports auf, löscht damit den Empfänger aus der Empfängerliste und falls die Liste danach leer ist wird auch der komplette Report gelöscht

View:

Übsericht:

Hier werden alle Berichte eines Benutzer mit Berichtstypen Ziel und Herkunft angezeigt. Ungelesene Berichte sind fett markiert und stehen oben in der Liste. Wenn man auf den Mülleimer klickt, wird der Bericht im Hintergrund mit einem Ajax Request gelöscht und per JQuery aus der Tabelle entfernt. Beim Klicken auf das Auge wird die Übersicht mit einem SlideOut Effekt ausgeblendet und die View des Berichtes nachgeladen und sobald sie fertig geladen ist mit einem SlideIn Effekt angezeigt. Sollte der Bericht noch nicht gelesen worden sein, wird er zusätzlich als gelesen markiert und erscheint beim nächsten mal nicht mehr fett gedruckt. Dies alles geschieht ohne die komplette Seite neuzuladen.

View eines Berichtes:

Stellt die Informationen eines Berichtes anschaulich dar. Dabei wird beispielsweise beim Battlereport unterschieden, ob man Angreifer oder Verteidiger, Gewinner oder Verlierer war und dementsprechend unterschiedliche Formulierungen angezeigt. Mit einem Klick auf "Zurück" wird der Bericht ausgeblendet und eine aktualisierte Übersicht der Berichte nachgeladen.


Page last modified on August 24, 2013, at 01:24 AM