Neuentwicklung des pSys

[k00ni]

Hallo,
mir kam gerade etwas in den Kopf, was Powie ua. auch bei dem Thread ansprach, soweit ich weiß, wo es um die Zukunft der pSkripte geht: Die komplette Neuentwicklung des \"pSys\". Ich meine, der Gedanke daran bringt mich etwas in Euphorie, da man vieles anders, besser, schöner, schneller und was weiß ich nicht alles, machen kann. Aber wäre das auch sinnvoll? Sollte man nicht bestehenden Code anpassen und ggf. darauf aufsetzen? Es gab ja schonmal Anstregungen, die in eine Neuentwicklung (wo ich nicht ganz unbeteiligt war :ugly: ) gingen, dann aber wieder im Sand verlaufen sind.
Mein Standpunkt: Es bringt nichts, alles neu zu machen. Lieber ein neuschreiben von Teilen des pSys oder bearbeiten von Funktionen, als das ganze Ding neu zu planen. Probleme ergeben sich schon bei der Datenbank: Entweder man behält diese Daten bei oder man baut sie von Grund auf neu auf, was wiederum bei der Portierung Probleme bereiten könnte. Ich wäre für eine schrittweise Konvertierung des pSys in eine \"Art\" Framework, ein Baukasten. Es müssen keine Klassenhierarchien oder sowas vorkommen. Ein lockerer Verbund von Funktionen würde auch ausreichen. Denn für mich als Modulentwickler ist es gut, wenn ich bestehenden Code nutzen kann und nicht alles neuschreiben oder erdenken muss. Mir würde es ja schon was bringen, wenn als Grundlage, die Zugriffe über SQL auf die Datenbestände (bspw. die Usertabelle), einzeln in Funktionen gekapselt werden. Eine Funktion fragt alle User ab, die andere alle Usergruppen usw. usw. Wie der Powie schon sagt: Keep it simple and fast. Und man sollte auch nicht versuchen, Projekte wie Joomla oder Typo³ zu imitieren.
 
Wie ist euer Standpunkt?
 - Editiert von k00ni am 21.09.2007, 11:30 -

[Powie]

Ja man könnte es  neu schreiben, von Grund auf. Ich hätte auch einige generelle strukturelle Ideen was man dann anders / einfacher machen könnte.
Why not...

Ja man könnte es neu schreiben, von Grund auf. Ich hätte auch einige generelle strukturelle Ideen was man dann anders / einfacher machen könnte.Why not...
[/quote]
Gib das pSys doch auch einfach frei. Dann kann jeder, der der Meinung ist, etwas verändern zu können oder zu wollen, einfach seine Modifikationen durchführen. Du kannst ja weiter deine eigene Version pflegen.

[Powie]

Ich werde pSys mit freigeben. Anders macht es keinen Sinn. Die pScripte sind immer in zweierlei Hinsicht interessant gewesen. 1. als eigenständige Versionen, 2. als zusammengefasste Installation. So wird es bei Freigabe der pScripte sicher Projekte geben die sie eigenständig weiter entwickeln, aber ich denke genauso werden vielleicht Projekte darauf hinaus laufen, sie wieder in einer Art integriertes System ala pSys zusammenfassen. Daher kann ich dies ebenfalls gleich mit ermöglichen...

[k00ni]

Ich werde pSys mit freigeben[/quote]
 :H:
 

Ja man könnte es neu schreiben, von Grund auf. Ich hätte auch einige generelle strukturelle Ideen was man dann anders / einfacher machen könnte.Why not...
[/quote]
Lohnt es sich schon, erste Ideen zu sammeln? Oder sollte man warten bis sich weitere Interessenten gefunden haben?
 
Grüße

[Powie]

Ich denke schon das es sich lohnen könnte, im Sammeln würden vermutlich die Leute hinzukommen  /uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />

[k00ni]

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  /uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />/uploads/emoticons/icon_e_biggrin.gif.1a84f5257b36e14b36d04985314f877f.gif\" alt=\":-D\" />
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 (http://de.wikipedia.org/wiki/Ruby_on_Rails\" rel=\"external nofollow\">Rails, Abschnitt Philosophie):

Convention over Configuration bedeutet, dass Rails sinnvolle Standardwerte erwartet. Erwartet wird etwa, dass der Primärschlüssel einer Tabelle vom Typ Integer ist und ID heißt, dass ein Model mit dem Namen Customer in der Datei #{RAILS_ROOT}/app/models/customer.rb gespeichert ist und die zugehörige Tabelle customers heißt. Ist dieses Model über eine 1:N-Beziehung mit einem Model Contract verknüpft, so wird erwartet, dass in der Tabelle contracts ein Fremdschlüssel mit dem Namen customer_id vorhanden ist. Wenn diese Standardwerte nicht zutreffen, können sie einfach umkonfiguriert werden, in den meisten Fällen bleibt der Entwickler jedoch von den ausführlichen Konfigurationsmöglichkeiten verschont.[/quote]
Dies erleichtert nicht nur die Arbeit, sondern beschleunigt die Entwicklung von Skripten ungemein.
 
Grüße

[Powie]

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.

[Powie]

Und noch eine Idee:
Start auf einem \"leeren\" CVS.
Dokumentieren -> implementieren.
Der Beginn wäre die Dokumentation.

[k00ni]

Zu 3: Aus Sicht der Ordnung ja, aus Sicht der Performance niemals![/quote]
Was soll hier auf die Performance drücken? Die schiere Anzahl an Verknüpfungen?
 

Zu 6: Gefällt mir nicht, müsste man schon anders machen[/quote]
Was gefällt dir daran nicht? Ist sehr einfach gehalten. Wir haben da bisher kaum Probleme gehabt.
 
Grüße

[k00ni]

Start auf einem \"leeren\" CVS. Dokumentieren -> implementieren.
Der Beginn wäre die Dokumentation.
[/quote]
Neues CVS, ja ok.
Aber warum voher dokumentieren? Die Dokumentation ist immer sehr schwer mit dem richtigen Code zu synchronisieren. Ich selbst würde dass entweder über ein externes Tool dokumentieren lassen oder nur eine kleine Übersicht geben und den Rest im Code lassen. Ich denke, dass man sich da zu viel Arbeit macht und es mit der Zeit schwierig sein wird dies aktuell zu halten, sowohl im Code, als auch in der Doku. Wer soll das pflegen? Oder wie hast du dir das vorgestellt.
Weiterhin bin ich der Meinung, dass das System nicht für DAUs geschrieben werden sollte. Nur grobe Überblicke per Doku und dann gleich in den Code rein, wenn man näheres erfahren will.
 
Grüße

[Powie]

Wenn mehrere Leute an solch einem Projekt arbeiten, so werden viele Dinge vorher \"dokumentiert\" werden müssen, damit sich an gewisse Rahmenbedingungen auch alle halten können. Namenskonventionen, Struktur, globale Funktionen etc.

Wenn mehrere Leute an solch einem Projekt arbeiten, so werden viele Dinge vorher \"dokumentiert\" werden müssen, damit sich an gewisse Rahmenbedingungen auch alle halten können. Namenskonventionen, Struktur, globale Funktionen etc.[/quote]
Vielleicht wäre die Übernahme oder Neuerstellung eines Coding Standards eine erste gute Idee. Ich bin kein großer Fan von umfangreicher Dokumentation - alleine, weil sie praktisch nach Erstellung sofort von der Programmierrealtität abweichen werden. Ich habe für meine Projekte ein paar einfache Merksätze:
1. Befolgen der http://pear.php.net/manual/de/standards.php\" rel=\"external nofollow\">PEAR Coding Standards, wobei ich Klammern nach (oder vor) Kontrollsturkturen jeweils in eine eigene Zeile stelle. Ziel ist es, robusten und sauber formatierten Code zu schreiben.

if (...)
{
   then ...
}

 
 
2. In Kontrollsturkturen stehen Konstanten oder Numerale immer vor der Vergleichsbedingungen.

if(true === isset($foo)
{
   then ...
}

 
 
3. Jede Änderung wird nach einem Funktionstest ins Repository eingecheckt.
4.
http://de.wikipedia.org/wiki/Mehrschichtigkeit\" rel=\"external nofollow\">Mehrschichtigkeit.
5. Trennung von Design und Markup (XHTML/CSS).
6. RFC-Konformität wo es RFC gibt.
7. Im Zweifelsfall entscheide ich mich für die robustere, nicht für die schnellere Methode.

[k00ni]

Hallo,
betreffend der Coding Standards (und die Dokumentation allgemein), sowie Ideen was die Inhalte des neuen Systems betrifft, würde ich das aufspalten in 2 getrennte Threads. Nicht das wir hier durcheinander kommen. /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />
 
Diskussionen über die Dokumentation: http://www.powie.de/cms/forum/showthread.php?id=22808\" rel=\"external nofollow\">hier
Diskussionen über Inhalt, Funktionalität und Logik: http://www.powie.de/cms/forum/showthread.php?id=22808\" rel=\"external nofollow\">hier
 
Grüße

[k00ni]

Wie sieht nun eigentlich die Weiterentwicklung des pSys aus? Wird das bis zum Beginn und vielleicht auch noch während der Entwicklung des neuen Systems weiter vorran getrieben oder auf Eis gelegt?
 
Grüße