Hallo,
ich bin dabei ganz grob nach den Vorbild Facebook-Neuigkeiten (persönliche Startseite) bestimmte Aktionen als "News" (Streams) zu posten. Ein Stream kann eine News, ein Benutzerstatus, das Anlegen/Bearbeiten eines Teams/Gruppe etc. sein. Ein Stream definiert sich also sowohl nach verschiedene Klassen/Datenbanktabellen als auch Aktionen.
Beispiel:
- Benutzer [B1] hat das Team [T1] erstellt.
- Firmennews (von [B2]): "großartige Neuigkeiten" ([mehr...])
- Im Gruppenforum [FG1] wurde ein neues Topic [FT1] von [B3] angelegt.
- [B4] hat die Gruppe [G2] wurde bearbeitet.
Die eckigen Klammern symbolisieren Hyperlinks. Folgendes Layout habe ich dabei gewählt, es funktioniert auch. (Was mir nicht gefällt erläutere ich gleich, daran schließt sich dann auch meine Frage nach dem besten Softwareentwurf dafür an.)
Uploaded with ImageShack.us
für Beispiel 1 (oben) also:
Per sprintf() wird dann der Text zusammengesetzt:
"[Chriz] hat das Team [Super Team] erstellt.";
Dazu habe ich einfach meiner News-/Team-/Benutzer/.. Klasse ein Interface verpasst, so dass es "Streamable" wird. Nun gefällt mir das aus mehreren Gründen nicht.
1.) Jede Klasse, die ich Streamable machen möchte, muss erweitert werden. Das widerspricht meiner Meinung nach dem Single-Responsibility-Prinzip (wobei mir der Gedanke kam, dass Interfaces im Allgemeinen diesem Prinzip widersprechen). Wäre ein Decorator/Proxy ein besseres Designpattern, um die Verbindung zwischen einer beliebigen Klasse und einem Streameintrag herzustellen?
2.) Durch das Interface muss ich ja nun den Inhalt des Streamtextes definieren. Um es schön zu formatieren benötige ich HTML. HTML in Klassen ist schlecht.
3.) Jede Änderung, jeder Statuswechsel, jede News erzeugt nicht nur einen Eintrag in der eigenen Tabelle, sondern auch in "stream" und "stream_var". Das ist inkonsistent, vor allem wenn ich nun News bearbeite, muss ich ja gleichzeitig auch den Eintrag im Stream wiederfinden und aktualisieren (Content ändern oder als "obsolete" markieren). Kann ich zwar, gefällt mir aber nicht.
Was für ein Datenbankmodell ist denn sinnvoll und wie kann ich beliebige Klassen mit dem Stream koppeln, ohne die Abhängigkeiten per Interfaces so dämlich zu erhöhen?
Am liebesten wäre es mir, wenn die Ausgabe eines Streameintrages über einen View/ein Template laufen würde, so dass Änderungen am Template auch rückwirkend Einfluß haben. Sollte ich dazu den Template-Pfad in der Stream-Tabelle speichern?
Warum ich übrigens stream_var verwendet habe ist, damit ich später die "Einzelteile" noch kenne, sprich das ich keine Statusmeldungen von Kollegen bekomme, die für mich garnicht relevant sind. Das heißt ich brauche zwingend die Informationen darüber welche Variablen an dem Stream beteiligt sind, so dass ich später die Ausgabe filtern kann.
Edit: Achso wichtig, was ich noch vergessen hatte und *für* die Felder "Text" spricht ist das eine doppelt gestreamte Änderung (B1 hat T1 geändert, danach hat B2 T1 umbenannt) ja nun dort die Änderung von B1 rückwirkend mit dem neuen Titel versehen wird, wenn ich den Text des Streams nur stumpf "verlinke". Das ist natürlich nicht gewünscht. Eine Versionierung von Änderungen allerdings auch nicht. Hm schwierig.
ich bin dabei ganz grob nach den Vorbild Facebook-Neuigkeiten (persönliche Startseite) bestimmte Aktionen als "News" (Streams) zu posten. Ein Stream kann eine News, ein Benutzerstatus, das Anlegen/Bearbeiten eines Teams/Gruppe etc. sein. Ein Stream definiert sich also sowohl nach verschiedene Klassen/Datenbanktabellen als auch Aktionen.
Beispiel:
- Benutzer [B1] hat das Team [T1] erstellt.
- Firmennews (von [B2]): "großartige Neuigkeiten" ([mehr...])
- Im Gruppenforum [FG1] wurde ein neues Topic [FT1] von [B3] angelegt.
- [B4] hat die Gruppe [G2] wurde bearbeitet.
Die eckigen Klammern symbolisieren Hyperlinks. Folgendes Layout habe ich dabei gewählt, es funktioniert auch. (Was mir nicht gefällt erläutere ich gleich, daran schließt sich dann auch meine Frage nach dem besten Softwareentwurf dafür an.)
Uploaded with ImageShack.us
für Beispiel 1 (oben) also:
Code:
stream id = 1 user_id = 123 (Session-User-ID) type = "team.insert" text = "%s hat das Team %s erstellt." stream_var (1:n zu stream) stream_id = 1 type = "db-table" key = "team" value = 456 (Team-ID) text = '<a href="/team/view/456">Super Team</a>'
"[Chriz] hat das Team [Super Team] erstellt.";
Dazu habe ich einfach meiner News-/Team-/Benutzer/.. Klasse ein Interface verpasst, so dass es "Streamable" wird. Nun gefällt mir das aus mehreren Gründen nicht.
1.) Jede Klasse, die ich Streamable machen möchte, muss erweitert werden. Das widerspricht meiner Meinung nach dem Single-Responsibility-Prinzip (wobei mir der Gedanke kam, dass Interfaces im Allgemeinen diesem Prinzip widersprechen). Wäre ein Decorator/Proxy ein besseres Designpattern, um die Verbindung zwischen einer beliebigen Klasse und einem Streameintrag herzustellen?
2.) Durch das Interface muss ich ja nun den Inhalt des Streamtextes definieren. Um es schön zu formatieren benötige ich HTML. HTML in Klassen ist schlecht.
3.) Jede Änderung, jeder Statuswechsel, jede News erzeugt nicht nur einen Eintrag in der eigenen Tabelle, sondern auch in "stream" und "stream_var". Das ist inkonsistent, vor allem wenn ich nun News bearbeite, muss ich ja gleichzeitig auch den Eintrag im Stream wiederfinden und aktualisieren (Content ändern oder als "obsolete" markieren). Kann ich zwar, gefällt mir aber nicht.
Was für ein Datenbankmodell ist denn sinnvoll und wie kann ich beliebige Klassen mit dem Stream koppeln, ohne die Abhängigkeiten per Interfaces so dämlich zu erhöhen?
Am liebesten wäre es mir, wenn die Ausgabe eines Streameintrages über einen View/ein Template laufen würde, so dass Änderungen am Template auch rückwirkend Einfluß haben. Sollte ich dazu den Template-Pfad in der Stream-Tabelle speichern?
Warum ich übrigens stream_var verwendet habe ist, damit ich später die "Einzelteile" noch kenne, sprich das ich keine Statusmeldungen von Kollegen bekomme, die für mich garnicht relevant sind. Das heißt ich brauche zwingend die Informationen darüber welche Variablen an dem Stream beteiligt sind, so dass ich später die Ausgabe filtern kann.
Edit: Achso wichtig, was ich noch vergessen hatte und *für* die Felder "Text" spricht ist das eine doppelt gestreamte Änderung (B1 hat T1 geändert, danach hat B2 T1 umbenannt) ja nun dort die Änderung von B1 rückwirkend mit dem neuen Titel versehen wird, wenn ich den Text des Streams nur stumpf "verlinke". Das ist natürlich nicht gewünscht. Eine Versionierung von Änderungen allerdings auch nicht. Hm schwierig.
Kommentar