Neuentwicklung des pSys: Inhalt, Funktionalität, Logik

[k00ni]

Hallo,
hier erfolgt die Diskussion das ganze Inhaltliche aus http://www.powie.de/cms/forum/showthread.php?id=22804&from=1190541149\" rel=\"external nofollow\">diesem Thread, wie SQL, welche Funktionen brauchen wir, wie soll das Framework strukturiert sein, brauchen wir überhuapt eines, was soll wie wo wann gemacht werden.
 
Grüße

[k00ni]

Folgendes wurde bisher angesprochen:

1. Ich wäre für ein frameworkähnliches System. Eine Funktions- und Klassensammlung, die die Zugriffe auf die Datenbank und die Grundfunktionen des Systems kapselt. Da würden dann die DBClass, FilterClass, SQL-Funktionen, die SQL absetzen und aufbereitet zurückgeben, usw. reinfallen.
2. Das Designsystem war richtig gut beim pSys. Das würde ich weiter nutzen. Vielleicht nicht mit 6 Dateien, sondern nur noch mit 4. Ist aber erstmal unerheblich denk ich.
3. Getrennte Userinformationen. Nicht alles was zum User gehört, muss auch in eine Tabelle. Name, Nickname, Passwort, ID, Lastonline und vielleicht noch das Registrierungsdatum, mehr nicht. Der Rest kann in Tabellen mit Zusatzinformationen. Da könnte man einen Weg gehen, bei dem man eine Tabelle hat mit variablen Userfeldern und eine andere mit den Eintragungen des Users. So bietet man mehr Flexibilität. Das könnte man dann noch mit Gruppen versehen und hat somit schöne Möglichkeiten mit den Daten zu jonglieren.
4. Saubere und verständliche Kommentare!!!eins!elf  
5. Wir haben bei unserem Friends ein gutes templateartiges System eingebaut. Man trennt einfach den Code in 2 Dateien: php- und tpl-Datei. Ersteres enthält die Logik und Funktionalität und Letzteres die STruktur, Formatierung und ggf. noch Variablen für die Ausgabe. Ist nichts übermäßig innovatives, aber man kann seinen HTML-Kram im Dreamweaver erstellen, einbinden, kurz nachbearbeiten und schon läuft es. Auch beim Update würde es nicht so schwierig, da man nur die PHP-Datei anpasst, die ja der User meist nicht angerührt hat.
6. Das Modulmanagement ist geil, einfach und effektiv. Würde ich so übernehmen.
7. Umfangreichere Logaktivitäten. Ich würde seher vieles mehr loggen, als es zur Zeit getan wird. Besonders auch die übergebenen Adressen und die zugehörige IP, um ggf. Angriffe erkennen zu können.
8. \"Ruby on Rails\", kurz Rails. Da gibt es 2 Leitsätze im System. Einer davon heißt, Konventionen über Konfiguration. Dazu einfach mal die schöne Erklärung aus der Wikipedia (Rails, Abschnitt Philosophie)
[/quote]

Zu 1: Ja so sollte es sein.
Zu 2: Ich weiss nicht, wenn ich das neu machen würde von Grund auf würde ich vermutlich ein komplett anderes System haben wollen. Der ähnliche Aufbaue ergibt sich sowieso.
Zu 3: Aus Sicht der Ordnung ja, aus Sicht der Performance niemals!
Zu 4: Wo es hingehört.
Zu 5: Wenn dann ein echtes TPL System was Wiederverwendung von Strukturen ermöglicht!
Zu 6: Gefällt mir nicht, müsste man schon anders machen
Zu 7: Logging um DOS oder Angriffe zu erkennen gehört nicht in das php Script. Sowas macht man auf Webserver Ebene effektiver, dafür gibt es bereits fertige Tools.
Zu 8: Das ist eigentlich DB Managment. Bisher in alten mySQL Versionen garnicht möglich, da wir aber eh ab 4.1.x aufwärts unterstützen wäre es hier erstmalig korrekt einsetzbar.
[/quote]

4. Mehrschichtigkeit.[/quote]

Die Struktur des pSys würde ich aufspalten. Ein frameworkartiges Gebilde, was den Grundstock bildet. Darunter u.a. zählt die Kapselung der SQL-Logik und -funktionalität (Arbeit mit mehreren RDBMS möglich), Funktionen für den Zugriff auf die Datenbestände, für die angesprochene Templateengine angesprochene Dinge, AJAX ( ? ) / JavaScript-Funktionen, usw.
Ich würde die SQL-Logik und -funktionalität von Funktionen für den Zugriff auf die Datenbestände trennen, weil das eine die reine Interaktion mit dem RDBMS organisiert und durchführt, dass andere die Daten abfragt und ggf. aufbereitet zurückliefert. Ich finde es sehr angenehm, wenn man nur eine Funktion aufrufen muss (Informationen für einen User abfragen, Rückgabe wäre ein Array) und dann ganz einfach mit dem Rückgabewert weiterarbeiten kann ohne groß noch was dafür zu tun. Da würden wir die vom Statler angesprochene Mehrschichtigkeit haben (in einem Punkt von vielen).
Powie hat eine Templateengine angesprochen. So etwas wie bei Joomla? Oder bei Typo³? Also ich komm mit dem tpl und php-Prinzip von uns ganz gut klar. Welchen Umfang soll diese haben?
Auf meinen angesprochenen Punkt 3 (Getrennte Userinformationen.) hat Powie noch nicht geantwortet. Was ist daran Performancefessend? Es geht mir dabei nicht nur um die Übersichtlichkeit, sondern auch um die Konsistenz der Daten. Zur Zeit ist alles in einer Tabelle. Wird was gebraucht, so kommt eine Spalte hinzu. Na toll, das erschwert aber die Entwicklung von Aufsätzen oder das Forken ungemein. Da wäre dieser Ansatz von mir doch etwas offener: man speichert nur das aller Nötigste des Users in der Usertabelle und lagert den Rest in einer anderen Tabelle aus.
Damit könnte man dann auch eine Art \"Benutzergruppen\"-bezogene Userfelder erstellen: Gehört User A zu Gruppe so muss er Feld C unbedingt ausfüllen (Pflichtfeld).
Bei Punkt 6 habe ich das Modulsystem angesprochen. In welcher Form soll es sich denn vom bisherigen unterscheiden?
 
Grüße

Powie hat eine Templateengine angesprochen. So etwas wie bei Joomla? Oder bei Typo³? Also ich komm mit dem tpl und php-Prinzip von uns ganz gut klar. Welchen Umfang soll diese haben?[/quote]
Ich bin da etwas zwiegespalten: Einerseits ist PHP eigentlich eine Template-Sprache, andererseits mag ich Smarty ganz gerne (habe da in richtig großen Environments gute Erfahrung gemacht). Ich wäre deshalb für Smarty.

Auf meinen angesprochenen Punkt 3 (Getrennte Userinformationen.) hat Powie noch nicht geantwortet. Was ist daran Performancefessend? Es geht mir dabei nicht nur um die Übersichtlichkeit, sondern auch um die Konsistenz der Daten. Zur Zeit ist alles in einer Tabelle. Wird was gebraucht, so kommt eine Spalte hinzu. Na toll, das erschwert aber die Entwicklung von Aufsätzen oder das Forken ungemein. Da wäre dieser Ansatz von mir doch etwas offener: man speichert nur das aller Nötigste des Users in der Usertabelle und lagert den Rest in einer anderen Tabelle aus.Damit könnte man dann auch eine Art \"Benutzergruppen\"-bezogene Userfelder erstellen: Gehört User A zu Gruppe so muss er Feld C unbedingt ausfüllen (Pflichtfeld).
[/quote]
Ich stimme dir hier zu. Ich würde das Datenbankdesign komplett vollnormalisieren. Ein  gutes Beispiel, wo man ansetzen könnte, sind die drei Userfelder. Sowas muss man nicht als \"Feld1, Feld2, Feld3\" in die Datenbank schreiben, sondern lieber in eine getrennte Tabelle. Das bedeutet zwar mehr Arbeit beim Abfragen und Eintragen, ist aber langfristig einfach robuster.