Das sollte diskutiert werden.
Für die Entwicklung ist ein Framework eine feine Sache. Für Resourcen und Effektivität nicht immer, da es mehr Möglichkeiten abdecken muss, etc.
Es kommt wirklich drauf an was aus dem Kind werden soll und worauf die Prioritäten gesetzt werden sollen. Ich könnte mich auch mit einem "eigenen" kleinen Framework für bestimmte Funktionen anfreunden, welches man sicherlich durch andere Frameworks und ausgewählte Funktionen ergänzen kann. (PEAR, Zend, etc.)

Auch gefällt mir in den FW teilweise die Kapselung von AJAX nicht, welches definitiv im neuen CMS Einzug halten muss.

Nach meiner Einschtäzung wird man um die Umsetzung eines MVC-Musters nicht herum kommen. Bereits da stellt sich dann die Frage nach einem Framework. Und Dinge wie die DB-Abstraktion muss man auch nicht unbedingt selber programmieren. Je mehr Fremdcode (und dabei möglichst einheitlicher) verwendet wird, desto schneller ist die Entwicklung.

Die Kapselung von AJAX ist in der Tat häufig schlecht. Muss ja auch nicht unbedingt sein. Ein Framework zwingt dich ja nicht notwendigerweise, es auch zu verwenden.

Es kommt drauf an in welchen Bereichen du das FW einbinden willst.
Beispiel: Falls wieder mit Modulen für die Frontendentwicklung gearbeitet wird, ist dort weder die Arbeit mit Pattern noch mit MVC oder ähnlichem sinnvoll. Contenido ist auch deshalb beliebt, weil du auch als Anfänger einfache Module mit einfachem PHP schreiben kannst und nicht wie bei Typo erst wochenlang auf die Schulbank musst.
Soll es dann dort einen Art Wrapper zum FW hin geben oder wie ist der Gedanke dahinter?

nun, es gibt einen kern. es geht primär darum. die modulentwicklung muss sich nicht notwendigerweise ändern. ich würde bloss die ausführung in einer funktion kapseln und damit einen eigenen begrenzten kontext schaffen. die verwendung eines frameworks kann die modulentwicklung beeinflussen, muss das aber keineswegs. das ist eine frage des designs und nicht des frameworks.

Sekunde mal. Unter der Berücksichtigung, dass wir ein Framework nehmen wollen. Wie sieht es denn mit der Wiederverwendbarkeit des bisherigen Codes aus? Falls das sowieso zweitrangig ist, und alles auf ein Framework umgestrickt wird, dann spreche ich mich auch für ZF aus. Hmm?! Das hieße dann aber, dass wir uns auf PHP festlegen.

Aber ich muss gestehen, dass mich es mich total reizen würde, etwas zu bauen, bei dem man dann später einfach das Framework austauschen kann. So wie mit einem DB Abstraktionslayer. Z.B. in CakePHP oder gar in RoR. ;)

Sounds like magic... und nach Zukunft. Im Moment müssen wir uns wohl oder übel auf eine Programmiersprache festlegen. Und die kann bei einem Fork von Contenido aus keiner anderen Sprache bestehen als PHP. Mir wäre mindestens noch keine Technik untergekommen, die keine Festlegung der Programmiersprache auskommt (.NET macht diesbezüglich keine Ausnahme, obwohl das auf den ersten Blick so aussehen mag).

nein, .NET macht da keine Ausnahme, meines wissens nach zumindest.
allerdings macht php da eine ausnahme, das kann wenigstens im ansatz (ist das noch immer experimentell?) .net ;-)

@Frank

soll es nun ein Fork werden oder soll es was Neues werden. Wird es ein Fork sind wir, wie Andreas schon sagt, bei PHP, da ein Fork doch wohl auf das vorhandene aufbaut. Auch denke ich das ein solcher schneller zu einem vorzeigbaren Ergebnis führen wird. Die Einbindung eine Frameworks kann sicherlich auch modular erfolgen, indem man nur benötigte Funktionen und Klassen des FW nutzt bzw. erweitert.

@Ortwin

Die Frage stelle ich mir auch. Und wie gesagt, ich bin der Letzte, der sich gegen PHP ausspricht. Oder gar gegen ZF. Aber mir fehlt offengestanden ein wenig die Fantasie, wie man ein ZF um den Fork aufbaut und dabei doch wieder die Contenido-Klassen einbinden muss.

Was hält denn die Gemeinde von zwei Entwicklersträngen?

Ich kenne bisher nur ZF als PHP-Framework bin davon aber hell begeistert und gebe meine Stimme deshalb für Zend Framework ab.

wie genau was umgesetzt wird, wird zu diskutieren sein. ich kann zumindest sagen, dass es sich machen lässt. die integration eines frameworks bedeutet zunächst nur, dass man vorzugsweise die bordmittel des frameworks verwendet (als library). die umsetzung eines mvc-patterns wäre aus meiner sicht dann der zweite schritt. damit begegnet man dem problem, dass man eine unzahl von includes hat, die einem jeder übersicht nehmen. gleichzeitig erreicht man die dringend notwendige trennung von layout und logik, die bei einer verteilten entwicklung unabdingbar ist.

Eine Neuentwickung ist sicher wünschenswert, aber wozu alles was wir in den Schubladen haben einfach wegwerfen?

*Andreas*: Hat eine Suite die man fest integrieren kann
- und sicher noch einiges mehr...
*Murat*: Hat das AMR (oder irre ich hier schon wieder?)
- und sicher noch das eine oder andere
*Ortwin*: Hat einige Erfahrungen und sicher Sachen in der Schublade
*Christian (GaMbIt)*: Hat nette Sachen was Grafiken angeht und einige APIs optimiert
Karsten (also ich): Habe ein Shop-System (das ich ehrlich gesagt, auch nicht neu erfinden möchte)
- Und aktuell bastel ich ein nagelneues Plugin zur dynamischen Userverwaltung in einer gesonderten Tabelle, das auch für bereits vorhandene User sofort genutzt werden kann

So denke ich, geht es einigen von uns und wir machen es uns nicht leichter, wenn wir das Rad neu erfinden.
Zudem schneiden wir uns die potentielle Übernahme von Contenido-Nutzern quasi direkt ab.

Gegen einen zweiten Entwicklerstrang wäre sicher nichts einzuwenden, sofern dieser von den Ressourcen her machbar und finanzierbar ist.

Ich tendiere zur Verwendung des ZF von Andreas als Basis. Hierin Umsetzung der Tickets/des Change-Requests und dann ein qualitativ hochwertiges Produkt auf den Markt zu werfen.

Updating tickets (#6, #1, #3, #7, #2, #4, #5, #8)

Alle aktuellen Tickets nach Backlog Milestone

Mir wäre es lieber, wenn das Baby mit einem Framework umgesetzt wird, idealerweise unter Verwendung moderner Paradigmen wie z. B. MVC.

Das bedeuet aber, dass wir dabei in Richtung Neuentwicklung gehen müssten. DB Abstraktion, Authentifizierung und sonstige Features lassen sich im Laufe der Zeit Stück für Stück einbauen. Beim MVC geht das aber nicht, das kann man meiner Meinung nach nicht nachträglich einem Projekt "unterjubeln". Diese Entscheidung muss wohl am Anfang gefällt werden.

@murat:

ich hoffe, du irrst dich. verstehe mich bitte nicht falsch. günstig ist es natürlich auf jeden fall, wenn man das muster von anbeginn umsetzt. diese möglichkeit haben wir bei contenido allerdings ja nicht. ich hätte deshalb vorgeschlagen, zunächst mit einer bootstrap zu beginnen und alle bestehenden links auf die bootstrap umzuschreiben (im code). damit könnten wir mindestens alle erforderliche initialisierungen zentral machen (z.b. registry und db-verbindung) und aus einer zentralen stelle alle dateien, die bislang direkt angsprochen worden sind, aus der bootstrap includieren. dann sollten sich die bereiche einzeln (und verteilt in verschiedene releases) umprogrammieren.

alles was neu ist, könnte dann sauber geschrieben werden und der bisherige urschleim wäre mindestens maskiert, bis eine saubere umsetzung vorgenommen ist.

@kummer:

Wenn ich mir das so überlege, muss ich dir recht geben. Da das CMS zumindest im Backend seine eigene action-Verwaltung hat (Tabelle _prefix_actions), wäre die nachträgliche Integration des MVC "theoretisch" einfach möglich. Vielleicht würde das sogar am gleich Anfang des Projekts auch klappen, der neue Controller müsste dann die action "entgegen nehmen" und die entsprechenden Sourcen includieren. Vorher ein extract($GLOBALS, EXTR_SKIP); damit alle Globalen im aktuellen Scope zur Verfügung stehen...
Hast du da schon in der Richtung was gemacht?

@murat: nein, ich habe mich bislang in meiner suite im wesentlichen auf das frontend beschränkt (mit ausnahme der nested sets, bei dem ich einen backend-patch habe vornehmen müssen).

was mir vorschwebt, ist eine art renovation von contenido. ein aufräumen der gröbsten fehler. das wird sich wohl nicht auf einen schlag machen lassen. aber man könnte es mindestens maksieren, denke ich. mir fällt einfach auf, dass man nur sehr schwer erkennen kann, was in contenido wo geschieht. und side effects sind bei jeder anpassung fast unvermeidlich, so wie es derzeit aussieht.

die bildung einer bootstrap würde zunächst erlauben, dass alle initialisierung nur einmal vorgenommen werden müsste. das erleichtert dann die etablierung einer registry und später die entfernung aller globalen variablen. dann kann ein neues abstractionlayer eingeführt werden, welches zunächst (bis alles ersetzt ist) für alles verwendet werden kann, was bereits umgeschrieben wird (z.b. authentifizierung usw.). ausserdem besteht damit relativ einfach die möglichkeit, die sourcen neu zu ordnen und entweder über das webroot zu legen oder auf eine andere art den zugriff zu begrenzen (z.b. deny from all in einer htaccess). mir geht es dabei insbesondere auch um die initialisierung der autoload-funktionlität von zend (sollten wir uns für dieses fm entscheiden).

bildlich gesprochen, würde ich einfach zunächst ein neues dach über das haus legen, damit die renovation darunter erfolgen kann. ich hatte vielfach das problem, dass ich immer und immer wieder neu meine klassen includieren musste und durchaus nicht immer klar war, welchen weg der code im contenido-dschungel nimmt. mit einer bootstrap erledigt sich schon ein grosser teil dieser probleme: registry ist sicher da, db-abstraction ist etabliert, autoload funktioniert.

ich habe eine vorstellung, wie der umbau an die hand genommen werden kann. ich schätze, in dieser hinsicht hat man sich relativ schnell gefunden, wenn alle anderen fragen geklärt sind.

Nach all der Lacherei, die ich mir im Thread Projektnamen erlaubt habe, mal was sinnvolles gemacht. Der Thread hier hat es in sich. Wenn ihr hier das Paradigmen-Modell auf den Prüfstand legt, dann schlage ich vor, das wir auch die Objektklassen mal einer Prüfung unterziehen.

ok leute. jetzt sind meinungen gefragt. klare statements, wenn möglich. framework: ja oder nein. wenn ja, welche präferenzen bestehen?

falls wir feststellen sollten, dass divergierende meinungen bestehen, sollten wir die diskussion fortführen. falls nicht, könnten wir uns das sparen.

ich spreche jetzt mal zunächst nur für mich: ich votiere klar für die verwendung eines frameworks. und spreche mich dabei für zend aus.

Framework: Zend

bin ich auch für

so hab ich wenigstens endlich mal nen grund mir das gründlich anzugucken :)

Meine Meinung dazu:

Framework verwenden?
ja, nimmt uns viel Arbeit ab

Welches Framework?
Zend, weil a.) Bekannt und beliebt und b.) Komponenten/Klassen einzeln verwendbar, wir können uns raussuchen, was wir davon haben wollen

hat da jemand nen gutet tut?
würd mich da gern so schnell wie möglich mit auseinandersetzen

Auf der Zend-Framework Seite gibt es viele Infos dazu, inkl. einem Quick-Start.

soweit ich das sehe, besteht im wesentlichen einigkeit. ich warte noch einen moment. vielleicht gibt's noch kritische stimmen. ansonsten scheint das soweit klar.

Ich bin auch pro ZF!