Diskussion: CMS wie Joomla als Basis eines Browsergames?

Hi,

Viele benutzen ja Frameworks als Basis für ein Browsergame um Zeit zu sparen und eine flexible und getestete Basis für das Projekt zu besitzen. Ich würde gerne mal eine Diskussion starten und Vor- und Nachteile sammeln ob es sich lohnen würde einen Schritt höher zu gehen und gleich ein komplettes CMS als Basis für das Spiel zu nehmen (da ich gerade selbst eine Homepage für jemanden erstellen soll und wohl auch in das Schreiben von Erweiterungen einarbeiten muss). Als CMS Beispiel würde ich gerne Joomla nehmen, das ist mir am geläufigsten. :)

Vorteile:

• Die meisten "Standardfunktionalitäten" wie Benutzerverwaltung, statische Seiten, Navigationen bis hin zu Forum und Medienverwaltung sind im CMS schon inbegriffen im Gegensatz zu den meisten Frameworks
• Die Schnittstellen sind in einem CMS für Erweiterungen festgelegt und man kann sein Spiel auch später hin noch mit frei verfügbaren Erweiterungen erweitern. Das Spiel selbst würde man bei Joomla beispielsweise modularisiert aufbauen mit Modulen, Plugins und Komponenten (eine Komponente beispielsweise für Allianzverwaltung oder eins für Kommunikation)
• Erweiterte Sachen wie Templateverwaltung, Sprachverwaltung usw. sind ebenfalls schon fertig inbegriffen. Vor allem können auch Benutzer eigene Templates einfacher schreiben, wenn sie Erfahrung mit Joomla Templates haben (kein individuelles System zur Einarbeitung)
• Das Aufsuchen von neuen Mitarbeitern wäre erleichtert, da Erfahrungen in Joomla eine schnelle Einarbeitung zulassen

Nachteile:

• Joomla unterliegt der GPL, daher wäre es nur möglich ein Open Source Browsergame zu erstellen (was ich zum Beispiel sowieso in Überlegung hatte)
• Neue Joomla Versionen erfordern möglicherweise auch Anpassungen an den Spielerweiterungen. Hier hab ich noch nicht lange genug Erfahrung mit Joomla um sagen zu können wie stabil die API oder Schnittstellen für Erweiterungen sind
• Es wird sehr problematisch, wenn man dann irgendwann mitten im Projekt an die Grenzen stößt, da man am Kern nur schwer etwas ändern kann/sollte. Daher das CMS muss von sich aus durch Erweiterungen schon so flexible sein, dass die Umsetzung möglich ist

Daher die Frage, fallen euch noch Vor- und Nachteile ein? Gibt es irgendein starkes Argument warum man so etwas nicht machen sollte oder warum es bisher keiner überlegt hat? Soweit ich weiß gab es doch mal ein Projekt auf Joomla Basis, gibt es denn noch irgendwelche Projekte hier die Joomla als Basis verwendet haben? Und falls sich jemand direkt mit Joomla besser auskennt: Ist Joomla flexible genug für ein solches Projekt?

Als wohl stärkstes Argument wäre für mich wohl die Lizenzierung, da wohl die meisten kein Open Source Browsergame machen wollen.

Ein paar kurze Gedanken:
Ich sehe da auf den ersten Blick nur einen Vorteil.
Man hätte die Basics wie News, Forum, Registrierung schon mal fertig out of the box.
Aber ich denke die Anforderungen eines BGs sind so speziell,
das du dann inGame höchstens die Joomla Session zur Authentifizierung nutzen könntest.
Den Rest müsstest du ja dann sowieso selbst implementieren.
Also wieso Joomla mit rum schleppen, wenn man keinen wirklichen Mehrwert davon hat?
Diverse Bedenken hätte ich aber dabei.
Wie sieht das mit der Performance aus?
Was ist mit der Sicherheit?
Was ist mit Updates?
Wie vertragen sich die Updates mit den eigenen Erweiterungen?
Wo bleibt da der Spass am Coden?
Und gerade den letzten Punkt finde ich ganz wichtig als Hobbycoder.
Warum sich durch circa 12 MB, 3500 Dateien und 600 Ordner wühlen?

Original von Amun Ra

Ich sehe da auf den ersten Blick nur einen Vorteil.
Man hätte die Basics wie News, Forum, Registrierung schon mal fertig out of the box.
Aber ich denke die Anforderungen eines BGs sind so speziell,

Und die anderen Vorteile sind keine Vorteile? :)

das du dann inGame höchstens die Joomla Session zur Authentifizierung nutzen könntest.
Den Rest müsstest du ja dann sowieso selbst implementieren.
Also wieso Joomla mit rum schleppen, wenn man keinen wirklichen Mehrwert davon hat?

Klar, alles spielspezifischen muss man natürlich selbst schreiben, kann dabei aber auf die API von Joomla zugreifen. Gerade so Sachen wie Einstellungen im Adminbereich zusammen mit den Inhaltsseiten in einer Erweiterung sauber getrennt zu halten finde ich schön. Die Verwaltung der Erweiterungen und der kompletten Basis entfällt.

Wie sieht das mit der Performance aus?

Performance wüsste ich nichts, aber Zend_Framework beispielsweise ist auch nicht das Schnellste. Je mehr Abstraktion man hat umso langsamer wird es ja in der Regel. Aber für mich gehört das Argument eher zu den unwichtigeren Dingen, wenn ich durch Frameworks oder hier durch das CMS meine Entwicklungszeiten stark beschleunigen kann.

Was ist mit der Sicherheit?

In wie fern, ist Joomla nicht sicher? Gibt es offene Sicherheitslücken oder benötigen diese sehr lange bis sie behoben werden? Immerhin wird Joomla ja sehr viel eingesetzt, stark getestet dadurch. Also warum Bedenken bei der Sicherheit?

Was ist mit Updates?
Wie vertragen sich die Updates mit den eigenen Erweiterungen?

Das sind die größten Bedenken die ich auch habe. Wie hoch ist der Aufwand bei neuen Versionen von Joomla. Wobei es sich eigentlich in Grenzen halten sollte, solang alles vom Spiel über die normalen Erweiterungen hinbekommst ohne am Kern etwas zu ändern. Denn die Schnittstellen bleiben ja eher stabil (nur der Wechsel von 1.0 auf 1.5 war bei Joomla ja ein großer Unterschied, aber ich denke nicht dass das jedes Jahr gemacht wird).

Wo bleibt da der Spass am Coden?

Gerade der Punkt wäre eher ein Vorteil in meinen Augen. Du brauchst keine Basics machen da ja auf der Basis aufsetzt (siehe oben), sondern kannst dich rein auf die spielspezifischen Sachen kümmern.

Und gerade den letzten Punkt finde ich ganz wichtig als Hobbycoder.
Warum sich durch circa 12 MB, 3500 Dateien und 600 Ordner wühlen?

Warum sollte ich mich durch die Ordner wühlen? Die API ist dokumentiert, die Schnittstellen sind dokumentiert und man selbst entiwckelt ja "nur" an Erweiterungen, nicht im Kern.

Bei den großen CMS tauchen wie Joomla oder Drupal tauchen häufig Sicherheitslücken auf. Die werden natürlich geschlossen, allerdings musst du beim aktualisieren dann auch schnell hinterherziehen. Wenn du mal im Urlaub bist oder noch deine eigenen Module auf Kompatibilität testen musst, dann könnten Spieler, wenn sie clever sind, die Lücken nutzen um zu cheaten (abgesehen von externen Hackern). Das wäre zumindest in einem Spiel ein großer Anreiz.

Gebe ich dir Recht, allerdings betrifft das doch jede Software?!? Also auch Webserver und Datenbanksoftware sind nicht vor Sicherheitslücken sicher. Und insbesondere Eigenentwicklungen dürften in der Regel ein größeres Maß an Unsicherheit mitbringen, da diese nicht so langwierig und von so vielen Benutzern getestet wurden.

Oder kann man Joomla Allgemein als sehr unsichere bzw. unqualitative Software bezeichnen? (sollte mir vielleicht mal Auszüge aus dem Quellcode anschauen *g*)

Dass ein System nicht ohne weiteres endlos alleine läuft ist ja klar, es muss gepflegt werden. Updates muss ich ja auch beim Webserver, bei einem Framework und ähnliches einspielen.

Naja, um meinen Webserver zu aktualisieren reicht im Idealfall ja nen guter Paketmanager, die Wahrscheinlichkeit, dass ich mir dabei das Spiel zerschieße, ist nicht sehr hoch. Wenn bei Joomla aber an einer Stelle was an der API geändert wurde, muss erst das komplette Spiel wieder durchgetestet werden. Das kann Zeit kosten, vor allem da automatisierte Unit Tests trotz Selenium oder so im Browser doch schon sehr schwer sein können.

Ich darf arbeitstechnisch im Moment ein Drupal nutzen (nur benutzen, nicht programmieren usw) und mein Eindruck ist, dass sich das für ein BG nicht eignet. Man fängt sich zu viel Abstraktion an Stellen ein, wo man sie nicht braucht, und zu wenig Flexibilität an Stellen, wo man sie dringend braucht. Falls jemand ein ordentliches BG auf Basis eines solchen CMS gemacht hat (oder haben wird), würd ich das gern mal sehen :-)

Original von abuzeus

Ich darf arbeitstechnisch im Moment ein Drupal nutzen (nur benutzen, nicht programmieren usw) und mein Eindruck ist, dass sich das für ein BG nicht eignet. Man fängt sich zu viel Abstraktion an Stellen ein, wo man sie nicht braucht, und zu wenig Flexibilität an Stellen, wo man sie dringend braucht. Falls jemand ein ordentliches BG auf Basis eines solchen CMS gemacht hat (oder haben wird), würd ich das gern mal sehen :-)

Sehe ich genauso. Ich hab mal eine mittelgroße Homepage mit Drupal aufgesetzt und selbst da waren schon sehr viele eigene Anpassungen mit dabei.

Original von abuzeus

Ich darf arbeitstechnisch im Moment ein Drupal nutzen (nur benutzen, nicht programmieren usw) und mein Eindruck ist, dass sich das für ein BG nicht eignet. Man fängt sich zu viel Abstraktion an Stellen ein, wo man sie nicht braucht, und zu wenig Flexibilität an Stellen, wo man sie dringend braucht. Falls jemand ein ordentliches BG auf Basis eines solchen CMS gemacht hat (oder haben wird), würd ich das gern mal sehen :-)

Uga-Agga setzt zumindest beim Portal auf Drupal. Ingame weiß ich nicht, aber es ist ja Opensource, ließe sich also prüfen.

Ich sehe dass es bei Joomla sehr viele Erweiterungen gibt wie Foren, Blogs, Bilder Galerien, Kalender usw. eigentlich alles was man für eine Standardhomepage braucht. Solche Erweiterungen wären denk ich nicht möglich wenn die Basis dafür nicht flexible genug ist.

Ich denke da kommt es sehr stark auf die Technik an, die im Browsergame zum Einsatz kommen soll. Ein Flash basiertes Rollenspiel wäre da wohl unangebracht, da bringt mir die Basis von Joomla recht wenig.

Aber wenn man ein vorwiegend Textbasiertes Game haben will (sozusagen von der alten Sorte) mit ein bisschen grafischer Unterstützung (Bilder, Karte) dürfte dies doch sicherlich ohne Eingriffe in den Kern möglich sein. Ist ja auch nicht mehr als Text, Formulare und Bilder.

Zunächst mal:

Joomla unterliegt der GPL, daher wäre es nur möglich ein Open Source Browsergame zu erstellen (was ich zum Beispiel sowieso in Überlegung hatte)

Das ist Unsinn. Du kannst das Browsergame "Closed" machen, du willst es ja sicher nicht vertreiben, sprich veröffentlichen? Es ist doch nur für dich..

--

Ich habe auch schon mal mit dem Gedanken gespielt, ein CMS (nicht die genannten) für ein Browsergame zu nehmen. Im Vordergrund stand auch, dass man auf ein großes Framework zurückgreifen kann (das haben eigentlich alle besseren CMS). Außerdem gibt es meistens bereits fertige Backend-Tools, sodas man mit "wenigen Handgriffen" Backendbereiche gebaut hat - wichtig, um einen guten Support, aber auch schnelle und ggf. sogar entwickler-unabhängige Einstellungen zu tätigen.

Wo es natürlich dann hakt, sind die Probleme der Erweiterbarkeit.. das bedeutet, wenn das Framework/CMS doch nicht genug bietet (schlechte Wahl?) oder schlecht erweiterbar ist (schlechte Wahl?). Man muss entweder Leute finden, die sich mit dem System auskennen (je nach CMS schwer oder leicht) oder man muss sich/Vorhandene/Neue in das System einarbeiten. Bei guter Dokumentation kann das dauern, bei schlechter Dokumentation dauert es noch länger (Zeit?).

Schlussendlich komme ich für mich auf folgendes Fazit:

1. Sollte das Browsergame-Genre es wirklich zulassen (mir fällt spontan keins ein), und ein CMS ist tatsächlich ideal.. bitte nutzen. Wir leben im Jahr 2009, wir müssen das Rad nicht immer neu erfinden.. (Punkt 2).
2. Frameworks nutzen. Ob nun das CMS die geeignete Wahl ist, oder ein Framework: Wenn ich mich nur einmal um die Techniken kümmern musste, kann ich später freier am "Geschäft" arbeiten.
3. Ein CMS bietet viel, und wird dadurch - vor allem für neue - zum regelrechten Feature-Monster. Das kann sowohl gut, als auch böse sein.
4. Problematik Cache: Die meisten CMS und Frameworks wie CakePHP haben integrierte Caching-Algorithmen bzw. -funktionen. Dummerweise funktionieren die in den meisten Browsergames nicht, weil man meist dennoch auf echte Realtime-Daten angewiesen ist. Eine Homepage (selbst mit aktuellen Inhalten) kann entweder mit "Minuten-Scheiben" leben oder wird mit einem "Push" gecached. Bei Browsergames faktisch unmöglich, weil man ja doch in der Datenbank nachgucken muss, wie der Stand der Dinge ist..

Das ist Unsinn. Du kannst das Browsergame "Closed" machen, du willst es ja sicher nicht vertreiben, sprich veröffentlichen? Es ist doch nur für dich..

Du lebst aber immer im Risiko, dass es eines Tages unter der AGPL fällt und du es veröffentlichen musst.

Joomla hat schon einmal die Entwickler von Komponenten eine Entscheidung vor die Füße gelegt, mit denen sie nur schwer leben konnte:

http://www.nitsche.org/news/joomla/core-developer-haelt-kommerzielle-joomla-komponenten-fuer-illegal.html

Daher würde ich nur auf Frameworks setzen, bei denen man sich kommerziell eine wirklich freie Nutzung erwerben kann und ich nicht eines Tages überrascht bin und in einen 'Vendor-Lockin' gerannt bin.

Original von DrakeL

Ich sehe dass es bei Joomla sehr viele Erweiterungen gibt wie Foren, Blogs, Bilder Galerien, Kalender usw. eigentlich alles was man für eine Standardhomepage braucht. Solche Erweiterungen wären denk ich nicht möglich wenn die Basis dafür nicht flexible genug ist.

Ich denke da kommt es sehr stark auf die Technik an, die im Browsergame zum Einsatz kommen soll. Ein Flash basiertes Rollenspiel wäre da wohl unangebracht, da bringt mir die Basis von Joomla recht wenig.

Aber wenn man ein vorwiegend Textbasiertes Game haben will (sozusagen von der alten Sorte) mit ein bisschen grafischer Unterstützung (Bilder, Karte) dürfte dies doch sicherlich ohne Eingriffe in den Kern möglich sein. Ist ja auch nicht mehr als Text, Formulare und Bilder.

Es geht mir ja auch eher um Datenlogik im Hintergrund. Was interessiert mich die Präsentation? So wie moderne CMS aufgebaut sind, ist der Kern sehr flexibel. Für so eine Flexibilität bezahlt man aber immer einen Preis, und zwar mit Laufzeit. Meiner Meinung nach hat man, wenn man sein BG um ein CMS herum aufbaut zu viel Overhead an Stellen, wo er nicht Not tut. Die Alternative wäre, doch eigene Datenhaltung zu betreiben und dann nur an wichtigen Stellen zum CMS zu "bridgen". Sowas artet aber schnell in Frickelei aus. Bei einfachen Tabellen gibt es vielleicht noch keine Probleme, aber wenn zum Beispiel komplexe Kampfberechnungen und dergleichen dazu kommen sehe ich Probleme.

Ich glaube auch, dass das Benutzungsprofil von Browserspielen und dem einer herkömmlichen, mit einem CMS betriebenen Webseite sich zu sehr unterscheiden. Und man muss sich den Konventionen eines Frameworks unterwerfen, welches nunmal nicht auf BGs gemünzt ist.

Wenn es ein BG-Framework gäbe, welches die benötigten Grundfunktionen (Portalaccount, Forum, Eventhandler, Erzeugen von Spielweltinstanzen, Bugtracker) sinnvoll bereitstellen würde ohne allzu viel einzuengen und Annahmen zu machen, wäre dies vielleicht geeignet, aber ein solches Framework gibt es meines Wissens nicht (obwohl die Idee mit schöner Regelmäßigkeit durch die gerade aktuellen Entwicklerforen kursiert). Am dichtesten dran an so etwas ist vielleicht die Bibliotheksammlung die die Pixeltamer mal hier veröffentlicht haben (viel Spaß beim suchen). Undeads FBK zum Beispiel halte ich für ungeeignet, er macht zu viele Annahmen über das Spielprinzip.

[x] für eine Vorschaufunktion

Original von TheUndeadable

Das ist Unsinn. Du kannst das Browsergame "Closed" machen, du willst es ja sicher nicht vertreiben, sprich veröffentlichen? Es ist doch nur für dich..

Du lebst aber immer im Risiko, dass es eines Tages unter der AGPL fällt und du es veröffentlichen musst.

Joomla hat schon einmal die Entwickler von Komponenten eine Entscheidung vor die Füße gelegt, mit denen sie nur schwer leben konnte:

http://www.nitsche.org/news/joomla/core-developer-haelt-kommerzielle-joomla-komponenten-fuer-illegal.html

Daher würde ich nur auf Frameworks setzen, bei denen man sich kommerziell eine wirklich freie Nutzung erwerben kann und ich nicht eines Tages überrascht bin und in einen 'Vendor-Lockin' gerannt bin.

Wenn du Updates nutzen willst, ja. Denn eine Lizenz für ein bestimmtes Release kannst du doch nicht mehr zurücknehmen..

Es geht mir ja auch eher um Datenlogik im Hintergrund. Was interessiert mich die Präsentation? So wie moderne CMS aufgebaut sind, ist der Kern sehr flexibel. Für so eine Flexibilität bezahlt man aber immer einen Preis, und zwar mit Laufzeit. Meiner Meinung nach hat man, wenn man sein BG um ein CMS herum aufbaut zu viel Overhead an Stellen, wo er nicht Not tut.

Nun ja - wo hat ein CMS oder ein Framework keinen Overhead und führt zu mehr Laufzeit? Die Abstraktion, Flexibilität führt zwar zu aufgeräumten, strukturierten und sicherlich auch effizienten Code.. aber eine Individuallösung ist immer besser (hinsichtlich von Overload o.ä.).

Ansonsten teile ich deine Meinung: Es gibt einige Ideen, aber alle vorgeschlagenen Lösungen sind eigentlich unbrauchbar, weil sie nur einen bestimmten (kleinen) Teilbereich von Browsergames abdecken. Eigentlich kann ein "BG-MS" über die Business-Logic nichts aussagen, nur Hilfestellung bieten...

Ich seh hier ganz viel Konfusion, angefangen bei der Lizenzfrage.

Kommerziell muss echt nicht sein, schaut einfach mal was unter LGPL, Apache License oder BSD style License zu finden ist.

Idr braucht man sich bei der Lizenz auch keine Sorgen machen, dass sie spontan irgendwann zu euren Ungunsten verändert wird, eine Rückwirkende Anderung der Lizenz dürfte im Regelfall rechtsunwirksam sein. Viele Lizenzen betonen sogar das unbegrenzte Nutzungsrecht, um im Vorfeld solche Bedenken auszuräumen.

Betrachtet man, was man von einem CMS in einem Browsergame benötigt, dürfte ein CMS in den meisten Fällen ohne hin die falsche Wahl sein. Benutze ich z.B. Drupal oder Joomla, dann verwende ich davon sicher vorwiegend die gleichen Features, die ich bei Googlesuche leicht mit den Stichworten "CMS top ten sql injection" finde. Muss nicht sein.

Als Unterbau für Browsergames wäre wohl viel eher ein CMF geeignet, oder ein Application Server, für den es modulare Lösungen für Authentifizierung oder andere Gängige Standardkomponenten gibt.

Ein Browsergame zum Beispiel auf Grok (schlank) oder Zope (macht "industrial strength browser game Sinn?") aufzusetzen macht sicher mehr sin, als es in den doch meist recht eingeschrängten Nutzungsrahmen eines Blogs mit extras hineinzupressen.

Zudem darf nicht vergessen werden, dass einem das lernen nie erspart bleibt, sondern sich nur der Bereich ändert in dem ich lernen muss. Schmalhans "cms" auf der Lampp Plattform bieten meist nicht genügend Features um die greulichen Performanceinbussen zu rechtfertigen, professionelle Plattformen wie Typo3 haben erst einmal eine niederschmetternde Lernkurve (3-6Monate) zu überwinden, bis ich etwas damit anfangen kann, und ein Plone... naja, das muss man lieben, und solange man die out-of-the-box produkte reichen ist alles in Ordnung, aber wenn eigene Contenttypes entwickelt werden müssen, dann wirds auch da richtig spassig.

Saludos,

Stefan

Ich hatte mich damals bevor ich anfing ein neues BG zu programmieren mit diesem Thema auseinandergesetzt.

Um es kurz zu machen, warum es für mich nicht in Frage kam:

1. CMS/Frameworks sind open Source. Es treten zu oft irgendwelche Fehler oder Sicherheitslücken auf, die von bösen Usern direkt genutzt werden.
2. Bei Fehlern jeglicher Art muss man sich in dieses CMS/Framework erst einarbeiten. Auch wenn man die API hat, ist dies eine viel zu große Aufgabe. Da habe ich es leichter, wenn ich meinen Code kenne ;)
3. CMS/Frameworks haben einfach zu viele Features, die man im BG nicht gebrauchen kann.
4. Caching Alg. sind im BG fast sinnlos.

... ;) Gruß,

Du hast Recht. Aber du hast Unrecht, weil

• nur weil du keine Fehler gefunden hast deine Software nicht unbedingt fehlerfrei ist (Prinzip der Blindheit).
• du bestimmt kein QS wie die (größeren) Opensource-System aufweisen kannst.
• du quasi das Rad neu erfindest (Anti-Pattern).
• es es bestimmt ein Framework gibt, welches für deinen Zweck ausreicht. Ein CMS muss es aber nicht wirklich sein.

Sorry, deine Punkteliste war einladend :)

Wofür Sorry?

Jede Medaille hat zwei Seiten, gell? ;)

Ich fande das meine Argumente gut genug waren, um mich dafür zu entscheiden ein eigenes Framework zu entwickeln.

Die paar einfachen Pakete die ich brauchte, waren schnell gezaubert. ( Session Verwaltung, Private Nachrichten, User verwaltung) und der Rest muss sowieso von Spiel zu Spiel immer wieder angepasst werden. Das hällt mein Framework schön klein und übersichtlich :) Auch wenn man das Rad neu erfindet:

Jede Medaille hat zwei Seiten, gell? ;)

Es gibt auch kommerzielle Frameworks und CMS. Das musst nicht zwangsweise Open-Source sein.

Dazu fällt mir folgendes ein:

http://benjismith.net/index.php/2005/09/30/hate-frameworks/

Original von Kampfhoernchen

Es gibt auch kommerzielle Frameworks und CMS. Das musst nicht zwangsweise Open-Source sein.

 Seit wann sind das zwei Paar Schuhe? Oder meintest du kommerzielle, nicht open source Lizenzen? Also Closed-Source?

Dann stelle ich die Frage: Ist Closed-Source wirklich sicherer?

-> Thema "Security Through Obscurity vs. Open Source Security".

Closed source ist erfahrungsgemäss nicht sicherer. Viele Augen sehen mehr als wenige, und wenn ich mir ansehe wie "renommierte" closed source Softwareproduzenten mit relativ trivialen Bugs kämpfen und teilweise mehr Arbeit investieren sie schönzureden als zu beseitigen, dann lob ich mir Open Source, da hab ich meinen code, und wenn was nicht funzt kann ich wenigstens selber dran ohne mich strafbar zu machen oder grausame Dekompilate zu lesen.

CMS und Framework in einen Topf zu werfen in der Debatte halte ich für kritisch. Je nach Geschäftslogik kann für ein Browsergame sogar ein gutes CMS sinn machen, wenn ich z.B. Inhalte wie Rundenberichte in verschiedenen Formaten zugänglich machen will (Wap, pdf, html, xml wasauchimmer), bei Frameworks müsste man im speziellen usecase erst einmal definieren WAS für ein Framework man nun benutzt. In Java verbessert zum Beispiel die Verwendung des Springframeworks grundsätzlich die Wiederverwendbarkeit von Code und erleichtert Routinetasks wie Datenbankzugriffe etc.

Ahnlich hilfreich ist das Zend Framework in PHP, welches zum beispiel ausgereifte Services zu verfügung stellt, wie sie in Browsergames gut Verwendung finden (sollten oder könnten).

my2pesos,

Stefan

Original von Tron

CMS und Framework in einen Topf zu werfen in der Debatte halte ich für kritisch. Je nach Geschäftslogik kann für ein Browsergame sogar ein gutes CMS sinn machen, wenn ich z.B. Inhalte wie Rundenberichte in verschiedenen Formaten zugänglich machen will (Wap, pdf, html, xml wasauchimmer), bei Frameworks müsste man im speziellen usecase erst einmal definieren WAS für ein Framework man nun benutzt. In Java verbessert zum Beispiel die Verwendung des Springframeworks grundsätzlich die Wiederverwendbarkeit von Code und erleichtert Routinetasks wie Datenbankzugriffe etc.

Ahnlich hilfreich ist das Zend Framework in PHP, welches zum beispiel ausgereifte Services zu verfügung stellt, wie sie in Browsergames gut Verwendung finden (sollten oder könnten).

Dem kann ich mich nur anschließen. Bei einem CMS habe ich auch mittlerweile eher das Gefühl da mehr Nachteile als Vorteile am Ende zu haben. Vor allem ist ein CMS dafür gedacht redaktionelle Inhalte zu verwalten und es eher ein Krampf wäre es umzubiegen für Browsergamelogik.

Ein Framework hingegen ist eher für alle Arten von Anwendungen geeignet und bietet in vielen Bereichen schon die Lösungen die man eh selbst nachbauen würde (DB Layer, MVC etc.).

Ich bin mittlerweile auch auf Zend Framework gestossen und damit recht zufrieden.