Hallo auch!
Ich wollte mal einige Punkte hier ansprechen, die mir in der letzten Zeit im Umgang mit dem Code aufgefallen sind und diese dann auch zur Diskussion stellen:
Zunchst einmal wollte ich den allgemeinen Aufbau ein bichen bemngeln, da der code in der derzeitigen Version nicht unbedingt gerade leserlich ist. Zum einen ist ziemlich wenig kommentiert, zum anderen werden irgendwelche codeschnipsel einfach in eine neue Datei gepackt, um dann bei bedarf einfach included zu werden und dabei auch sofort ablaufen.
blich in allen hheren Programmiersprachen ist jedoch eine Modulbildung mit klar abgegrenzten Schnittstellen, soda einzelne Programmteile als black box behandelt werden knnen und bei Bedarf einfach als feststehende(s) Function/Objekt mit richtiger Parameterbergabe aufgerufen werden knnen. Der Entwickler hat sich dann nicht dauernd darum zu kmmern, was denn jetzt in den includes eigentlich genau passiert, sondern ruft das Teil einfach auf und es funktioniert.
Das wrde auch die Mehrfachverwertung von code besser mglich machen, sowie eine klarere Aufgabenabgrenzung fr die einzelnen Entwickler bedeuten.
Die Templates an sich als include ganz am Schlu einer Datei sind ganz in Ordnung, da somit das Aussehen des chats nicht mehr so eng an den code an sich gekoppelt ist.. Allerdings knnte man hier in einer stable-release vielleicht sehr viel traffic sparen, wenn man alle unntigen Zeichen in diesen Dateien vermeidet. Der HTML-code, der letztendlich ber die Leitung geht kann ja ruhig wie Kraut und Rben aussehen, aber Traffic kostet geld und sollte meiner Meinung nach vermieden werden.
Des weiteren habe ich die letzten Tage PHP4.1 installiert, da ich den chat auch gleich unter der neuen Engine mal testen wollte. Es gab eigentlich nur einen greren Bug, der aufgetreten ist, alles andere schien vorerst mal zu funktionieren, allerdings sollte das ganze noch mit Vorsicht zu geniessen sein.
Was aber der Grund ist, warum ich das hier erwhne, ist, da ab der 4.1 register_globals als off empfohlen ist und angekndigt wurde, da dieses ab PHP 4.2 dann von vornherein abgeschaltet sein wird. Mit eben jenem Parameter auf off ging dann natrlich gar nichts mehr, da die globalen Variablen eben immer noch sehr intensiv genutzt werden. Auch hier knnte eine klare Schnittstellenabgrenzung weiterhelfen, soda Variablen eben bergeben und nicht global irgendwo gehalten werden.
Dann wollte ich mal langsam angehen, da fr die nchste Version des PHPOpenChats man vielleicht mal daran gehen sollte, die PHP3-Versionen auslaufen zu lassen. Die ganze Geschichte ohne Session-management kann man zwar weiterfhren, jedoch ist es ein wesentlich erhhter Entwicklungsaufwand, weil man vieles 2 mal schreiben mu und zudem bedeutet die alte Version weniger Sicherheit und viiiieeeel mehr traffic (wenn man in den HTML-CODE der input mal reinguckt, dann besteht der zu 2/3 aus Variablen, die hidden mitgeposted werden mssen). Deswegen wollte ich mal vorschlagen, da man das langsam aber sicher ausklingen lt?
Abschlieend hab ich einen weiteren Vorschlag: Um eine grere Flexibilitt zu erhalten, wollte ich mal ansprechen, ob wir die einzelnen Funktionsblcke (damit meine ich Eingabe / Channelwechsel / Farbwechsel / Friends / ..... also alles was man im chat als Funktion sieht) nicht noch weiter kapseln sollen, damit man dann beim Aufbau seines chats nur noch den Funktionsblock entweder included, soda zum Beispiel der channelwechsel Teil des inputframes ist, oder eben dem Block einfach einen eigenen frame zuweist. Auch das wrde dem Kraut- und Rbencode etwas entgegenwirken. Der static-frame war ja schon ein erster Schritt in diese Richtung.
Hm.. ich hab noch einige Vorschlge zu unterbreiten, aber ich denke fr heute reichts erst mal.
Gru
Thomas Schwoerer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo auch!
Ich wollte mal einige Punkte hier ansprechen, die mir in der letzten Zeit im Umgang mit dem Code aufgefallen sind und diese dann auch zur Diskussion stellen:
Zunchst einmal wollte ich den allgemeinen Aufbau ein bichen bemngeln, da der code in der derzeitigen Version nicht unbedingt gerade leserlich ist. Zum einen ist ziemlich wenig kommentiert, zum anderen werden irgendwelche codeschnipsel einfach in eine neue Datei gepackt, um dann bei bedarf einfach included zu werden und dabei auch sofort ablaufen.
blich in allen hheren Programmiersprachen ist jedoch eine Modulbildung mit klar abgegrenzten Schnittstellen, soda einzelne Programmteile als black box behandelt werden knnen und bei Bedarf einfach als feststehende(s) Function/Objekt mit richtiger Parameterbergabe aufgerufen werden knnen. Der Entwickler hat sich dann nicht dauernd darum zu kmmern, was denn jetzt in den includes eigentlich genau passiert, sondern ruft das Teil einfach auf und es funktioniert.
Das wrde auch die Mehrfachverwertung von code besser mglich machen, sowie eine klarere Aufgabenabgrenzung fr die einzelnen Entwickler bedeuten.
Die Templates an sich als include ganz am Schlu einer Datei sind ganz in Ordnung, da somit das Aussehen des chats nicht mehr so eng an den code an sich gekoppelt ist.. Allerdings knnte man hier in einer stable-release vielleicht sehr viel traffic sparen, wenn man alle unntigen Zeichen in diesen Dateien vermeidet. Der HTML-code, der letztendlich ber die Leitung geht kann ja ruhig wie Kraut und Rben aussehen, aber Traffic kostet geld und sollte meiner Meinung nach vermieden werden.
Des weiteren habe ich die letzten Tage PHP4.1 installiert, da ich den chat auch gleich unter der neuen Engine mal testen wollte. Es gab eigentlich nur einen greren Bug, der aufgetreten ist, alles andere schien vorerst mal zu funktionieren, allerdings sollte das ganze noch mit Vorsicht zu geniessen sein.
Was aber der Grund ist, warum ich das hier erwhne, ist, da ab der 4.1 register_globals als off empfohlen ist und angekndigt wurde, da dieses ab PHP 4.2 dann von vornherein abgeschaltet sein wird. Mit eben jenem Parameter auf off ging dann natrlich gar nichts mehr, da die globalen Variablen eben immer noch sehr intensiv genutzt werden. Auch hier knnte eine klare Schnittstellenabgrenzung weiterhelfen, soda Variablen eben bergeben und nicht global irgendwo gehalten werden.
Dann wollte ich mal langsam angehen, da fr die nchste Version des PHPOpenChats man vielleicht mal daran gehen sollte, die PHP3-Versionen auslaufen zu lassen. Die ganze Geschichte ohne Session-management kann man zwar weiterfhren, jedoch ist es ein wesentlich erhhter Entwicklungsaufwand, weil man vieles 2 mal schreiben mu und zudem bedeutet die alte Version weniger Sicherheit und viiiieeeel mehr traffic (wenn man in den HTML-CODE der input mal reinguckt, dann besteht der zu 2/3 aus Variablen, die hidden mitgeposted werden mssen). Deswegen wollte ich mal vorschlagen, da man das langsam aber sicher ausklingen lt?
Abschlieend hab ich einen weiteren Vorschlag: Um eine grere Flexibilitt zu erhalten, wollte ich mal ansprechen, ob wir die einzelnen Funktionsblcke (damit meine ich Eingabe / Channelwechsel / Farbwechsel / Friends / ..... also alles was man im chat als Funktion sieht) nicht noch weiter kapseln sollen, damit man dann beim Aufbau seines chats nur noch den Funktionsblock entweder included, soda zum Beispiel der channelwechsel Teil des inputframes ist, oder eben dem Block einfach einen eigenen frame zuweist. Auch das wrde dem Kraut- und Rbencode etwas entgegenwirken. Der static-frame war ja schon ein erster Schritt in diese Richtung.
Hm.. ich hab noch einige Vorschlge zu unterbreiten, aber ich denke fr heute reichts erst mal.
Gru
Thomas Schwoerer