Wir haben drei Bereiche, an denen etwas geschieht, und diese müssen zusammenarbeiten

• Views-UI (add/edit view)
  • Benutzer legt views an und richtet diese ein
  • auf Basis der Tabelle adv_reports
  • Wählt ein Advanced Report aus (nach Modul und Report)
  • Gibt weitere Optionen an
  • Masken dazu vom Modul adv_reports nach Daten von module_x

• Module adv_reports
  • Schnittstelle zwischen Views-UI und Modulen, die Reports bereitstellen
  • Views-UI wird einzig von Modul adv_reports bedient, also die benötigten Bedienelemente
  • Erhält Reportspezifische Daten von eigenständigen ReportModulen
  • Erstellt Reports nach den erstellten Views und deren Optionen, und mit den Daten von den ReportModulen
  • adv_reports dient nur der Datenaufbereitung, nicht der Ausgabenart
  • Styles wie Chart oder andere können evtl. von einem Untermodul angeboten werden
  • adv_reports kann beliebig viele ReportModule bedienen, von denen jedes beliebig viele Reports anbieten kann
  • Übernimmt alle Arbeiten, die nicht ReportModul spezifisch sind (ReportModule sollen so wenig Arbeit haben wie möglich)
  • Stellt Funktionen bereit, die von den ReportModulen benötigt werden könnten (vermeidet Redundanz)
  • Holt sich die benötigten Daten über Callback-Funktionen, die die ReportModule implementieren müssen (evtl. über Handler, nach abgeleiteten Klasse einer abstrakten Klasse)

• ReportModule, etwa module_x
  • Während das adv_reports Modul einmalig ist, kann es beliebig viele ReportModule geben
  • Nachdem das adv_reports einmal geschrieben ist, ist die tägliche Arbeit das Schreiben der ReportModule
  • Diese müssen deshalb möglichst einfach zu handhaben sein
  • Ein ReportModul leistet alles, was adv_reports nicht selbst leisten kann, dazu gehören:
    • Metadaten zu den einzelnen Reports (Liste der unterstützten Reports + deren Zusatzdaten)
    • Zusammentragen der Nutzdaten aus den betroffenen Tabellen