Phoscur

Da ich schon seit einiger Zeit darüber nachdenke, mein Browsergame clientseitig recht schwergewichtig zu machen habe ich mich viel mit Ajax und Softwarearchitektur beschäftigt. Dies hat mich zu einem Design mit Domainlayer geführt. Um konkret zu werden: ich werde für jedes sinnvolle reelle Objekt wie User = Spieler, Spielfiguren und -verbände, Technologiebäume etcetc. Objekte einführen.
Ich modelliere diese Objekte aber nicht nur in PHP, sondern auch in JavaScript. Schon diese Formulierung deutet auf Duplikation hin, ist aber in einem gewissen Ausmaß nicht zu vermeiden.
Nehmen wir das MVC pattern. Anfangs war ich mir nicht sicher auf welcher Seite ich was ansiedeln muss, mittlerweile bin ich mir sicher, dass ich die View komplett in JavaScript ansiedeln kann. Bleiben noch Model und Controller. Leider bin ich mir immer noch nicht ganz sicher, was denn nun der Controller tut, das Model soll jedenfalls bei mir nicht zum reinen Datenobjekt verkommen, viel lieber will ich die Businesslogik oder besser die Domäne im Model unterbringen. Der Großteil wird nur von PHP zu bewerkstelligen sein und wenn überhaupt vorausberechnet von JavaScript.
Dinge, die der User tun kann, würde ich Aktionen nennen, diese Art von Objekt würden sich an jegliches DOM-Event binden lassen. Eine Aktion führt aber nicht notwendigerweise zu einem Request zum Server. Muss aber auch Informationen zum rückgängigmachen der Aktion enthalten, für den Fall, dass etwas schief geht und was passieren soll, wenn der User "Zurück" klickt.
Ich werde wahrscheinlich mit Pollen arbeiten, um Informationen vom Server zu holen, die andere User ausgelöst haben. Wenn ich nun DomainObjekte im JavaScript habe, dann müssen diese nach dem Pollen evtl. refresht werden, daher erscheint es mir nicht sinnvoll Request von DomainObjekten aus zu steuern. Ich brauche also eine Stelle, die das kontrolliert. In Analogie habe ich in PHP etwas ähnliches mit einem anderen Problem: einen OR-Mapper oder gar eine Unit of Work.
Auch hier liegt dennoch eine Art Mismatch vor: JavaScript läuft durchgängig im Browser, während PHP nur über einen Request läuft, die Lebenszeit der Objekte unterscheidet sich.
Zwischenfrage: Mache ich mir umständlich Aufwand, vergewaltige ich die Sprache (PHP) wenn ich einen hohen Grad von Objektorientierung und Persistenz einführe?? Dennoch ist das nächstliegenste auch nicht sinnvoll: Ein JavaServer, der die Objekte über eine Session oder sogar noch länger im Speicher hält - ein Schwergewicht. PHP bemüht das nötigste und gibt es sofort wieder frei.
Ich bleibe bei den Vorgaben: PHP5.3, MySQL >=5 InnoDB, JavaScript (evtl. mit dem neuen ECMAScript 5 Standard)

Zurück zum Problem: Wie bastele ich den Controller(MVC) auf JavaScriptseite? Brauche ich überhaupt einen Controller? Letztlich wäre ein Controller doch eh nur eine Zusammenfassung von Aktionen zur Steuerung der Models. Naja, vielleicht kann man sie nach Themen ordnen...

Hier nun ein Ansatz zur Client-Server Kommunikation: Eine Aktion wird wenn sie ausgeführt wurde früher oder später namentlich an den Server übermittelt, der ein zugehöriges Objekt erstellt (JS und PHP Aktion müssen technisch nicht gleich sein, sie ergänzen sich eher um Sicherheit und Umfang, eine JS Aktion kann auch mehrere PHP Aktionen auslösen und umgekehrt, ich weiß noch nicht wie fein ich diese Aktionen gestalte. In JavaScript sind Objekte billiger, und belasten nicht meinen Server ).
Die DomainObjekte auf PHPseite müssen streng überprüfen ob die angewandte Aktion überhaupt zulässig ist. Danach antwortet der Server ob die Aktionen erfolgreich ausgeführt wurden. Wenn ja, bleibt der User unbehelligt, ansonsten kommt eine Fehlermeldung und die fehlgeschlagegenen Aktionen werden auch im JavaScript rückgängig gemacht.
Das minimiert die Kommunikation zwischen Server und Client stark, weil unverändertes nicht geholt werden muss. Trotzdem ist Vorsicht geboten, falls Client und Server out of Sync geraten könnte das verwirrend werden für den User. Ich schätze die DatenObjekte werden mit einer Maximallaufzeit ausgerüstet werden. Oder gibt es da bessere Lösungen?

Leider bin ich mir nicht sicher wieviel Businesslogik ich tatsächlich ohne Requests in JavaScript umsetzen kann. Aber wahrscheinlich nicht so viel.. Vielleicht breche ich mir auch unnötig einen ab und erzeuge nur viel Duplikation.
Irgendwelche Kommentare, Anregungen, Kritik, Ideen?

__________________

Mister Ad

nikosch

Gerade mit einer View rein auch JS-Seite scheint die Rolle des Controllers doch klarer als in sonstigen PHP-Applikationen: bspw. wertet er die Art des Requests aus und liefert Ajax-Inhalte (JSON) oder ganze Seiten aus.
Den Controller in JS anzusiedeln halte ich für falsch. Es sei denn Du siedelst die Datenbank Server-unabhängig an (wie bspw. Couch-DB) oder willst serverseitig gar keine Daten speichern (hast also quasi auch ein clientseitiges Model).

Im Übrigen würde ich nochmal zwischen Domain/Businessobjekt und MVC unterscheiden.

Da JS bspw. mit seinen Events viel mehr Model, Aktionen u.ä. zusammenbringt, würde ich über ein clientseitiges Domainobjekt nachdenken, ein serverseitiges Model (Datenschicht), einen Abgleich der Datenschicht mit der Clientseite über JSON.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Phoscur

Ja, tut mir Leid wenn der Beitrag von mir etwas konfus war, ich bin mir mit dem ganzen noch nicht so klar.. ein paar Dinge kamen beim Schreiben.

CouchDB schaue ich mir architektonisch an, meine aber, dass mir das schon früher mal nicht gefallen hat.
Leider ist ein Browsergame nur teilweise eine Webapplication und muss viele Daten auf dem Server verwalten, das sehe ich keinen Weg dran vorbei. Zudem müssen die Aktionen des Spielers kontrolliert werden.
Da die ganze Businesslogik - die Spielregeln - erweiterbar sein soll, möchte ich das in einem DomainLayer umsetzen. Ich brauche also auch DomainObjekte in PHP, so gern ich das auch einfacher hätte. Ich weiß nicht, ob ich dafür den Code in JS und PHP duplizieren muss.

__________________

nikosch

CouchDB erwähnte ich deshlb, weil sie ein Interface bietet, das rein über Javascript-Requests CRUD-Funktionalität bietet. Zudem arbeitet es mit JSON-artiger Speicherung, kann also ganze Objekte, Usersettings, ... ablegen. Hör Dir ruhig mal den Podcast bei Chaosradio Express an.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

dr.e.

Hallo Phoscur,

gerne kommentiere ich deinen Betrag - wie per PN gebeten.

Ich hatte meine Meinung zu JS-Applikation im Artikel AJAX and the APF kund getan. Dieser ist zwar schon einige Tage alt, nur lässt sich zusammenfassend auch heute sagen: komplette Applikationen parallel in JS aufzusetzen ist keine gute Idee. Sofern du eine flexible Basis einsetzt, sollte das MVC auf Server-Seite implementiert sein. Nur dann bist du IMHO flexibel für Anpassungen.

Das bedeutet für deine Applikation, dass du das Domänen-Modell zwar in der JS-GUI kennen und behandeln können solltest (beispielsweise durch eine JSON-Repräsentation), die Verarbeitung sollte jedoch immer auf dem Server stattfinden. Hier kannst du entsprechende Front-Controller-Aktionen aufrufen (z.B. für das Ändern einer Benutzer-Eigenschaft). Finden dabei gleichzeitig Änderungen der Oberfläche statt, bietet es sich an, die kleinen Teile, die es betrifft, auf dem Server zu rendern und per AJAX-Call in die GUI einzusetzen. So kannst du deutllich flexibler auf Design- und Funktions-Änderungen reagieren, als wenn du im Client haufenweise DOM-Operationen implementierst.

Soviel zum allgemeinen Teil. Hier noch ein paar Anmerkungen zu Details:

Hier würde ich eine JSON-/oder XML-Schnittstelle auf PHP-Seite implementieren. Vermutlich ist das Command-Pattern hier sinnvoll, weil es ja unterschiedliche Aktionen ausführbar sein müssen. Vielleicht kannst du das so generisch implementieren, dass man das auch als externe API nutzen kann.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Phoscur

Ich hatte halt gehofft Befehle beim Client direkt auszuführen und den Server unabhängig zu kontaktieren. Das funktioniert natürlich nicht, wenn spezielle Daten vom Server notwendig sind. Wahrscheinlich hast du recht und es ist zu aufwendig und bringt dann doch nichts. Das kann ich ja evtl. in einer zweiten Version einbauen.
Ein reiches Interface mit JavaScript werde ich trotzdem bauen. Gerade die Views werden in JS implementiert. Trotzdem wird der User warten müssen, bis der Server antwortet, wäre ja zu schön gewesen.

__________________

Chriz

Ich würde dir da auch eher von abraten, selbst kleine JavaScripte können schnell sehr komplex werden und du hast kaum noch sinnvolle Möglichkeiten zum Debuggen.

Außerdem bekommst du vermutlich Probleme beim Synchronisieren. Sei es dass der Timer in JS gestartet wurde und plötzlich mit der Serverzeit nicht übereinstimmt und darum abgelehnt wird oder dass dir mehrfach geöffnete Tabs oder Browser sowieso alles zerschiessen.

Außerdem wird es dann schwierig Hackversuche festzustellen, weshalb du ja doch wieder alles Server-seitig validieren musst. Gewinnen würde nur der Frontend-User, allerdings auch nur, wenn du die genannten Fehlerquellen ausmerzen konntest und auch dann vermutlich nicht einmal spürbar. Der Aufwand lohnt meiner Meinung nach nicht.

Das Command-Pattern hätte ich dir auch vorgeschlagen, wobei es ja dann doch relativ schwierig wird komplette Anfragen wieder rückgängig zu machen. "Kaufe Planeten, Verkaufe Sonnensystem" so und jetzt dreh den Kauf des Planeten wieder zurück?! Da musst du schon einiges an Logik nachimplementieren, für jede Aktion. Nur so als Info, falls du dachtest das geht schnell von der Hand

Deinen Objekt-orientierten Ansatz könntest du möglicherweise mit RPC-Aufrufen nachbauen. Dann musst du allerdings ein Rechtemanagement für Klassen und Methoden definieren, nicht dass dir jemand den Datenbank-Adapter ansteuert und fleißig virtuelles Geld auf sein Konto schaufelt

Phoscur

Mittlerweile gibt es doch schon einige Tools die einem die Entwicklung mit JavaScript erleichtern. Google hat gezeigt, dass man auch mit JavaScript größere Anwendungen schaffen kann.
Ja, JS zählt und rechnet komisch. Damit muss man leben. Mehrere Tabs werden vorerst nicht und wenn dann mit verschiedenen Widgets möglich sein.
Ja, ums Validieren komm ich so oder so nicht herum.
Oh nein, ich dachte nie dass das schnell von der Hand gehen würde. Ich überlege nur wie sinnvoll es ist, ob ich das auch in JavaScript implementiere

Rechtesystem. Ich weiß nicht ob ich sowas bauen will. Bisher hatte ich eigentlich vorgesehn auch diese Art von Validierung in den DomainObjekten anzusiedeln.
So muss zum Beispiel die nötige Tech vorhanden sein, wenn der Spieler etwas kaufen will, und natürlich genug Geld.

__________________

Chriz

Schaffen Ja, Übersicht behalten sehr schwierig. Ich hatte mich mal in qooxdoo eingearbeitet, tolles Framework fürs Nachbauen einer Desktopoberfläche, trotzdem wuchert der Code irgendwann und das lag weder am Framework noch an meinen JS-Kenntnissen. Ich meine in PHP entwickelt sich mit der Zeit auch eine Vielzahl an Klassen, nur finde ich hier das Debugging viel viel einfacher. Bei JavaScript ist alles etwas mehr "live" (Callbacks, Events, viel mehr Userabhängigkeit) und damit auch extrem variabler und schwieriger nachzuvollziehen. Mal eben einen Dump oder Backtrace rauslassen ist auch nicht, weil dir gleich der Browser zuläuft oder du erst die Interaktionen nachführen musst, die zu einem Problem führten.

Deshalb vermeide ich größere "JavaSkripte" und versuche das ganze mit AJAX zu umgehen, ohne die Interaktion zu verlieren, die JS bietet.

Phoscur

Ich werde wahrscheinlich JSpec als Testframework verwenden und so gut wie möglich Test-Driven entwickeln, das sollte mir das ganze nochmal um einiges erleichtern.

__________________