[size=150]Hi @All,[/size]
Ich baue gerade eine Art Framework auf, das mithilfe von Javascript den PHP-Webserver entlasten soll.
Laufen sollen darauf z.B. meine Bewerbungsseite, meine Homepage, ein noch kleines Forum, dass webseitenübergreifende Benutzer(gruppen)-synchronisation mittels requests erledigt.
Die Benutzer hätten dann den Vorteil, dass ihre Namen in jedem Forum die gleichen sind, sie sich immer an dem selben Server anmelden, und ihre Anmeldenamen ( ohne PW, dafür aber mit emails ) überall gleich sind.
Untereinander vereinbaren die Server dann Passwörter und so weiter um die Session-Ids Authentifizieren zu können ( wie bei LDAP ).
Jeder Benutzer ist gleichzeitig auch eine Gruppe in der andere Benutzer per buddi aufgenommen werden. Die Vererbten Berechtigungen ( keine Zusätzlichen Restriktionen. ) gelten nur für die vom Benutzer erstellten Threads, von seinem Profil-pseudo-forum verlinkt und evt. untergruppiert sind.
Das eigentliche forum verlinkt dan Quasi nur noch auf diese Threads falls der Benutzer diesen Öffentlich einträgt. Sollte der Thread dann vom Benutzer freigegeben werden können sich andere Mitglieder bei diesem Benutzer / Bei den Admins um die Moderatoren-Berechtigungen bewerben.
Solange der Thread nicht öffentlich ist, ist er Quasi auch mal ein guter Ersatz für das PN-System im Konferenzmodus für eingeladene User und kann jederzeit gelöscht werden, falls alle Beteiligten die Löschung wünschen - bei Streitigkeiten kann jeder die Admins / Globalen Mods einladen.
[size=150]Wo ich Eure Hilfe bräuchte ( Ich hoffe da kennt sich bei Euch jemand aus und ist bereit mir zu helfen, oder Links zu schicken. ):[/size][ul]
[li]Da ich das ganze momentan noch in Dateien speichere, die der PHP-parser versteht, suche ich schon länger einen Befehl, der zwar nur Arrays mit den standart-Datentypen einlesen kann, aber dafür performanter arbeitet.[/li]
[li]Bei der Gliederung bräuchte ich eigentlich nur noch bei den Caches und für die Benutzerdaten hilfe. Aber es wäre auch mal gut zu hören, was ihr ihr zu dem Restlichen Konzept denkt, der ob ich es noch verbessern könnte. Dabei muss JavaScript sauber von PHP getrennt werden und erstmal nur das allernötigste PHP geladen werden.[/li]
[li]Wie kann ich das mit den Berechtigungs-Gruppen am besten (logisch) regeln und Cachen?[/li]
[li]Wie vermeide ich am besten, das allzuviele PHP-Module geladen werden?[/li][/ul]
[size=150]Allgemeine Funktionsweise:[/size][ul]
[li]Es soll im Allgemeinen keine Factories und solche Schnittstellenmodule wie in den bereits erhältlichen Systemem geben.[/li]
[li]Smileys werde ich mit dem aktualisieren des Dialog-Caches direkt aus dem Ordner lesen. Sinnvolle Kürzel berechnet das System aus dem Dateinamen. Die Datenbank wird benutzt um überflüssige Kürzelberechnungen zu vermeiden.[/li]
[li]Sollte das ganze mit Java-Script laufen übernimmt der Webserver nur die Zugriffskontrollen und giebt den Inhalt der globalen Kofiguration ohne intime Daten, Daten der jeweiligen Benutzerdatenbank usw. an das JavaScript.[/li]
[li]Auch werden dann Vom Client eine standart Framework.js-Datei und das jeweilige Modul benötigt und werden bereitgestellt.[/li]
[li]Um unnötige Rechnerei zu ersparen, ließt dann das JavaScript den body-tag aus, parst den Inhalt nach HTML und entlastet den Webserver.[/li]
[li]Weiter Performance-Gewinne versuche ich aus CSS+AllesMögliche-Chaches und Request-Abhängige auslieferung von Bildern etc. zum vermeiden von fremdverlinkung zu ziehen.[/li][/ul]
[ul]Wenn das Javascript mit daten bedient werden soll, muss dem Webserver ja schließlich folgendes bekannt sein:[li]Ist die Session gültig?[/li]
[li]Welcher User - bzw welche User-Datenbankdatei.[/li]
[li]Hat er überhaupt Javascript an, oder muss PHP herhalten.[/li]
[li]Welcher Module braucht der User und wo sind sie zu finden.[/li]
[li]Wenn Datenbankzugriffe erfolgen, braucht er alle Daten? ist es sinnvoller PHP einzusetzen, oder mehr Daten zu übertragen?[/li]
[li]Datenbankqueries müssen validiert und abgearbeitet werden.[/li]
[li]Der Benutzer braucht ja noch eine Erfolgsmeldung - auch wenn es nur eine Meldung für den erfolgreiche Meldung bei einem Fehlschlag ist.[/li][/ul]
[ul]Was soll das JavaScript erledigen?
[li]Aufbau der HTML-Elemente.[/li]
[li]Bearbeiten von Request-Abhängigen CSS-codes.[/li]
[li]Mithilfe erhaltener Daten die vorläufige Güligkeitsprüfung auf Client-Seite, um unnötige Requests zu vermeiden.[/li]
[li]Bestätigungsanforderungen, CSS-Popups und vorläufige Input-Gültigkeitsprüfung übernehmen.[/li]
[li]Berechen, welche Daten vom Server angefordert werden müssen, um diesen seine Arbeit zu erleichtern.[/li][/ul]
[size=150]Momentan sehen die Dateien so aus:[/size][ul]
[li]index.php referenziert die erste index-Datei.[/li]
[li]index definiert die Konstanten SYSTEM, DB, TEMP, CACHE, USERS, PLUGINS und FILES, benötigt jedoch eine funktion aus tools für die relativen dateipfade.
Wenn möglich sollte eine doppelte definition dieser Methode in tools verhindert werden - allerdings weiß ich noch nicht wie ich das Managen soll - Über Hilfe freue ich mich 
.
Ruft SYSTEM/index auf - der Code ist evt später in dieser Datei und und die normale index damit überflüssig.
Da bräuchte ich dann aber eine Möglichkeit die definitionen einfach anzupassen - deshalb hab ich bisher noch diesen Zwischenschritt.[/li]
[li]SYSTEM.index hat eine Sicherung gegen Server-Überlast, die bei durchschnittlich über 70% und akueller über 80% Auslastung erst mal einen Hinweis ausgiebt es noch mal später zu Probieren ( 7 Code-Zeilen, ist glaub ich nicht die Welt… ).
Hier werden dann auch die SYSTEM/tools/index und SYSTEM/javascript/index eingebunden. Weitere Dateien wie z.B. SYSTEM/framework/index ( eventuell regelt das mit den img, usw. in späteren Versionen die framework ) werden danach eingebunden.[/li]
[li]SYSTEM/framework/index soll dann den eigentlichen Code enthalten, da dies sehr viel werden kann und eventuell den PHP-Compiler belastet.
Hier soll kein Code rein der bei JavaScript - Unterstützung im Browser benötigt wird[/li]
[li]SYSTEM/tools/index lädt fehlende Klassen mit autoload nach.
Die Strategie ist, vom Namespace den Ort ( z.B bei Plugins erst PLUGINS und dann SYSTEM/module ) abzuleiten. Da eine Datei auch mehrere Klassen / Interfaces beinhalten kann, wird erst dirname verwendet ( Es sind relative dateinamen, weil erster Befehl: str_replace(’’, ‘/’, … ) ).
^^ Dadurch werden auch erweiterungsplugins automatisch fähig, vorhandene zu ersetzen.[/li]
[li]Die SYSTEM/tools/FilesystemDatabase definiert eine eigene Array-Klasse für das Top-Element, um automatisch auf Änderungen reagieren zu können.
Sie weißt PHP an, auch setzt sie wärend dem Schreiben ignore_user_abbort, um inkonsistenzen zu vermeiden.
Im gegensatz zu einer richtigen Datenbank ohne weiteren Code kann sie Gruppen von Dateien festlegen, die Quasi gleichzeitig geschrieben werden müssen. Die Verwaltung mit Lock-Dateien ist Threadübergreifend und funktioniert notfalls auch mit entfernten Servern.
Im Prinzip wird eine Lockdatei im Temporären Ordner angelegt, zu den jeweiligen Dateien ein Verweiß auf die Lockdatei angelegt ( dabei wird ebenfalls überprüft dass nicht 2 Threads gleichzeitig schreiben. ) und falls alle Änderungen erfolgt sind die Lockdatei in die eigentliche Datendatei umgewandelt ( Dieses Verfahren ist leider noch sehr aufwändig und wird nur wenn absolut notwendig für die Konsistenz eingesetzt. ).
Später ( wenn ich mit MySql erst einmal mehr Erfahrung habe, ) ersetze ich das dann.[/li]
[li]Jeder Request behandelt eine bestimmte Anzahl an anstehenden Aufgaben um die Temporären Dateien zu entfernen und erhält dazu bzw. für die Lockfiles eine eindeutige unique ID mit einer PHP-Funktion.
[list]Der Plugin-Manager definiert folgende Klassen und Interfaces ( Der Backslash ist der Namespace-Delimiter seit PHP 5.3 ):[]plugins\DefaultInterface:
Enthält alle wichtigen Elemente eines Plugins[/li]
[li]plugins\DefaultClass:
Enthält bereits wichtige Methoden wie init, release und so weiter.
Diese sind leer und dafür da, bei Bedarf überschrieben zu werden.[/li]
[li]plugins\Requestable:
Für alle Module, für die ein Menülink angelegt werden soll ( Wegen Performancegründen werden diese - sofern nicht durch andere Interfaces beeinflusst - nur dann geladen, wenn sie benötigt werden. Auch das Menü wird vom Installer generiert. )
Beispiele: link-tag-extractor und menü-generator, Online-Bewerbungsmodul[/li]
[li]plugins\Embedable:
Dieses Plugin wird jedesmal, wenn der Cache mit dem jeweiligen Inhalt ( CSS, JS, Menüs, etc. ) neu aufgebaut wird geladen und ( evt nur teilweise weil mehrere Bereiche definiert ) ausgeführt.
Frage: Habt ihr ideen zu weiteren Optimierung?[/li]
[li]Serveable:
Diese können jeweils nur einen Service anbieten.
Zukünftige beispiele sind: LDAP- und MySql-Queries oder XML-RPC.[/li]
[li]PluginManager:
Installiert/Deinstalliert in eine eigene Datenbank-Datei Plugins.
Er überprüft dabei, welche interfaces sie enthalten und ordnet sie dem entsprechend ein.
Außerdem ist er in der Lage, für zwei Plugins mit der gleichen Aufgabe ein Konfiguration-HTML-Code zu erstellen und zu Cachen.[/li][/ul][/:m][/list:u]
Bitte schreibt mir Antworten - auch wenn ich etwas besser erklären könnte oder wenn es einen besseren Thread dafür giebt - konstruktive Kritik und Beiträge sind erwünscht.
