Javascript für chatsystem

[misch]

Hi!

Ich entwickle seit über einem Jahr ein Chatsystem und bin mit dem serverseitigen Skripten(PHP) schon weit fortgeschritten. Nun fange ich langsam an, über das clientseitige softwaremodell nachzudenken.

Prinzipiell besteht die Applikation aus mehreren Frames: ( Iconbar, Eingabe, ausgabe, raumliste,....)

Nun stellt sich mir die Frage, ob ich die Javascript klassen in den jeweiligen Frame packe(A), oder ob ich ein großes Clientobjekt zentral in den Frame iconbar packen(B) soll und aus den frames via "this.parent.iconbar.roomlist.foo()" darauf zugreifen soll. Gibt es hier Erfahrungswerte, oder Meiningen hierzu?

(A)
+ Der Code ist dort, wo er gebraucht wird.
- viele skriptdateien => unübersichtlich?

(B)
+ Eine Skriptklasse und eine zentraler Ort wo sie liegt.
- Da großes Objekt, vielleicht performanceprobleme.

misch

[webcool]

Hallo

ich habe auch ein Chatsystem geschrieben in PHP für meine Seite
und brauchte nur Java um den Curser im Textfeld zu behalten
und anderen funktionen wie smilies

Pack die Scripte da hin wo Sie gebraucht werden

sonst gibt es nur Probleme und suchst dir ein ab

hab ich auch so gemacht und nicht mit Hinweisen Sparen

aber warum brauchst du ein Jahr dafür ?

[misch]

Warum ein Jahr

Hi!

Danke für deine Antwort.

Ein Jahr brauche ich dafür, weil es ein Hobbyprojekt ist.

Weiters habe ich jedoch grundlegende Überlegungen angestelt und viele Systeme angesehen. Ebenso habe ich eine saubere Klassen und Datenbankstruktur entworfen usw.

Gruppen:

Ich habe zum Beispiel die Möglichkeit Chatbefehle in eine befehlsgruppe zu packen und diese Befehlsgruppe einer Benutzergruppe zu zuweisen.

Ebenso verhält es sich mit Raumgruppen und Filtergruppen.

ChatFilter:

Die meisten Systeme haben den Filter an der eingabeseite. Das führt dazu, dass das gefilterte wort in die DB geschrieben wird und so für jeden Benutzer die gleichen Filterregerln gelten.

Ich schreibe das ungefilterte Wort in die DB und wende den Filter bei der Ausgabe an. Das ist zwar aufwendiger, hat aber den Vorteil, dass jeder Benutzer andere Filterregeln haben kann.

Bsp.:

Ich kann in einem Raum das Wort "Sonnenblume" schreiben. Der Benutzer in der Filtergruppe FSK13 bekommt dafür das Wort "Sxxxxxxxxxe" ausgegeben während der Benutzer in der Filtergruppe FSK18 "Sonnenblume" bekommt.

Darüber hinaus habe ich drei Filterstufen geplant:

1. String exchange
2. extended String exchange (ähnlich einem Spamfilter |/ => V)
3. soundex filter

Ebenso streng ist das Klassendesign. Ich habe eine DB-baseklasse. Von dieser sind die Logikklassen abgeleitet. Und von diesen wiederum der HTMLwrapper. So habe ich die Möglichkeit den HTMLwrapper durch einen XMLwrapper zu ersetzen und ein Flashfrontend zu bauen.

Und viel mehr ...

misch

[misch]

Hi!

Ich habe noch was vergessen:

Ich habe eine eigene Template engine geschrieben und damit erreicht, dass alles templatebasierend ist. So kann ich auch unterschiedliche skins verwenden.

misch

[webcool]

Das hört sich ja gut an aber du musst ja dann auch eine altersüberprüfung machen weisst du schon wie du das machen möchtest

achso ich persönlich würde es nicht über eine Datenbank machen den desto mehr User du hast wird die performance immer mehr eingeschränkt

nach meiner meinung !!

Das mit der Template engine find ich gut

[misch]

Hi!

Die Alterskontrolle ist mir egal, das obliegt dem Chatbetreiber nicht dem Entwickler. Beziehungsweise könnte dieser vom Chatsystem dabei unterstützt werden, aber darüber habe ich mir noch keine Gedanken gemacht.

Was würdest du nicht über eine db machen?

misch

[webcool]

Die Einträge von den Usern würde ich nicht über die Datenbank machen sondern über einer Datei CSV oder so !!

Ich nehme mal an das du das System verkaufen möchtest
und finde das man die Alterskontrolle als Entwickler mit einbauen sollte
den dan braucht der Käufer sich nicht darum zukümmern vielleicht hat er ja auch noch keine ahnung

aber das mit FSK find ich ist ne tolle idee !!

[misch]

Hi!

Um die Performance der Datenbank mache ich mir noch keine Sorgen.
Ich habe so was wie eine "Garbage collegtion" geplant, die die Datenbank möglichst klein hält.

Ausserdem bezweifle ich, dass man mit einem CSV file eine bessere Performance bekommt, als mit einer DB.(Ich könnte mich aber auch täuschen.)

Im Gegenteil, ich habe sogar alles, was nur irgendwie in DB geht dort reingepackt. z.B.: Logging über trigger usw. und PHP greift nur über VIEWS auf die DB zu.

misch