Welches Framework als Grundlage für Contao 3?

[leo]

Wir hatten das Thema auf der Contao-Konferenz schon mal angeschnitten und aus zeitlichen Gründen nicht zu Ende diskutieren können. Deshalb würde ich gerne hier noch einmal zur Diskussion aufrufen. Es gibt drei Möglichkeiten (und nur diese drei ):

a) Das Zend-Framework

• Vorteile: Stabiles Framework, sehr gute Doku, viele Entwickler sind damit vertraut, guter Ruf.
• Nachteile: PHP 5.3 wird noch nicht unterstützt, kein Focus auf Performance, über 30 MB an Dateien.

b) Das Yii-Framework

• Vorteile: Performance-optimiertes Framework, konsequente MVC-Unterstützung, gute Doku.
• Nachteile: basiert auf PHP 5.1, weniger Entwickler kennen es.

c) Die Überarbeitung/Umstrukturierung des bestehenden Contao-Frameworks

• Vorteile: Man weiß, was man hat, alle Features von PHP 5.3 nutzbar, konsequente Ausrichtung auf Performance.
• Nachteile: Eigenentwicklungen kostet mehr Zeit, Third-Party-Entwickler müssen es erst lernen, Doku muss geschrieben werden.

[andreas.schempp]

c ++1

[mgco3]

Hallo Leo

Möchte mich hier noch zu Wort melden:

d) Symfony2
Vorteile:
- Stabil
- State of the Art
- PHP 5.3
- Mit Doctrine2 ein super ORM oder ODM im Hintergrund
- Gute Doku
- Grosse Community (z.b. wurden während der Entwicklung, also Preview/Alpha-Phase über 300 Bundles veröffentlicht)
- Gutes Caching (ESI)
- Wenn man mit OO-Entwicklung
- Ausgelegt für TTD


hast du leider vergessen. Sehr schade.

[lindesbs]

a) und b) wird einen kompletten Rewrite von jeglichem Code bedeuten, da NICHTS uebernommen werden kann, ausser der Name Contao

Ich bin fuer c), aus dem Grunde, weil das Framework schon steht. Es sollte nur allgemein gueltiger aufgezogen werden. Sodass es z.B. Klassen gibt, fuer FormularDarstellung, keine festen DC_Table, DC_File usw. Sondern dynamische DC_ so wie mein DC_Memory.

Erweitern auf HilfsKlassen, keinen fixen HTML-Code mehr in den Sourcen. Alles ueber ein sinnvolles Template System, sodass man einfach Daten in einem beliebigen Format erzeugen kann, ohne HTML5 oder XHTML.


Ein abstrakteres Framwork eben.

[schman]

Es gibt drei Möglichkeiten (und nur diese drei ):

@mgco3, wie du siehst stehen nur die drei zur Verfügung

Ich habe bisher noch nicht viel mit dem Framework gemacht, wäre aber auch eher dafür das Contao Framework zu "erneuern".
An zweiter Stelle wäre dann das Zend Framework.
Leo hat die Vorteile und Nachteile ja schon aufgezählt.

[BugBuster]

Hmm,
a) mit ZF habe ich schon gearbeitet, hier wäre die Frage ob man dessen MVC nutzt oder das ZF quasi "nur" als Library, und wieder eine eigenes MVC drüber.
Außerdem benötigt es PDO für die Datenbank. Das ist zwar prinzipiell gut, auch mein genutzter Hoster hat das, aber die Arbeitsweise damit wäre völlig anders als jetzt.
Und, haben "alle" Hoster PDO ?

b) Yii-Framework sagt mir nichts.

c) Hier bräuchte man dann hoffentlich nicht alles über den Haufen schmeißen, also wäre es sicherlich besser für unser Anliegen.
Die Nachteile sehe ich hier weniger, dass hatte ich auch als ich das erste Mal Contao (TL) angesehen hatte, und habs ja grade weil es in PHP5 geschrieben war genommen.
Wenn es nun auf PHP5.3 ausgelegt wird, mit Namespaces usw., dann wäre das wieder ein Grund dabei zu bleiben für mich, weil ich dann wieder an einen praktischem Beispiel lernen kann

Kurz: C wäre meine Wahl.

[Psi]

Ich spreche mich klar gegen Zend aus!
Für mich mein empfinden ist es viel zu performancehungrig.

Yii und Symfony sind mir relativ unbekannt, deshalb tendiere ich zu Option c)

[mgco3]

Uff, das ist eine schwere Frage. Im Gegensatz zu meinen Vorrednern bin ich jedoch für die Verwendung eines externen Frameworks. Ich denke einfach dass mal von vielen Features wie einem detailierteren Caching, ... profitieren würde.

Ob Zend oder Yii ist eine schwierige Frage. Zend ist ein Alleskönner, aber teilweise ohne Grund viel zu kompliziert.Ich würde eher zu Yii oder Symfony2 tendieren.
Viele Grüße
Leo

PS: Von Yii steht eine Version 2 in den Startlöchern die volle php 5.3 Features unterstützen wird.

Ich stimme dir da vollkommen zu. Zusätzlich fällt der Aufwand weg, den man in der Regel hat, um das eigene Framework voranzutreiben, bzw zu bugfixen und testen.
Weisst du zufällig wann Yii in Version 2 erscheinen wird?

[leo]

a) und b) wird einen kompletten Rewrite von jeglichem Code bedeuten, da NICHTS uebernommen werden kann, ausser der Name Contao

Das wir bei c aber nicht viel anders sein. Schon allein wegen der Namespaces und weil wir von der Klassensammlung hin zum MVC-Framework wollen. Die komplette Struktur wäre eine andere (Ordnerstruktur, statische Methoden anstatt z. B. $this->Input->get(), etc.).

[hofff]

Ich halte es wie BugBuster und wäre auch für c)

fg
nicky


---
I am here: http://maps.google.com/maps?ll=51.342593,12.392660
--
von meinem iPad mit Tapatalk gesendet.

[lindesbs]

Schon allein wegen der Namespaces und weil wir von der Klassensammlung hin zum MVC-Framework wollen.

Waere es dann nicht erstmal wichtig zu definieren, WAS wir wollen ? Bevor wir ein Framework aussuchen ?

Wo soll Contao hin ? Was ist der "Zielmarkt" ?
Der kleine Krauter mit privater Webseite ? Die mittelstaendische Firma, mit dynamischen Content, der SocialMedia Quark ? eCommerce ?

Worauf soll das System ausgelegt sein ?
Weil je nach Anwendungsfall ist das Framework dann doch schon sehr wichtig.
So wie BugBuster schon erwaehnte, PDO wird nicht jeder haben, wenngleich ich mir die Vorteile eines ORM sehr Wuensche.

[backbone]

a) dagegen. ich hab, während ich mich mit magento auseinander gesetzt hab, zwangsläufig ein auge auf ZF legen müssen und find es einfach nur schlecht konstruiert in sachen benutzung. zur performance kann ich nix sagen, außer das was man magento sieht (arsch langsam... nur mit viel workarounds nutzbar)

b) noch nicht von gehört, aber kein php 5.3, das fällt für mich durch

c) wär in ordnung, aber bitte mit doctrine DBAL und keine selbst geschusterten database abstractions. auch würd ich dinge wie Swift nicht nochmal extra wrappen, sondern lieber contao-spezifische factorys für anbieten.

zu PDO:
Es ändert sich nicht die komplette vorgehensweise! man kann genau so stinknormale qrys absetzen wie mit mysqli und hat zusätzlich einen OO-QueryBuilder. ich würde aber auf jeden fall Doctrine DBAL verwenden (ist ein wrapper um PDO, der aber auch andere native DB treiber unterstützen kann)

zu Symfony:
Hab ich schon in zusammenhang mit Doctrine von gelesen, aber noch nicht genauer mit beschäftigt. gehe mal von aus das es ein ADF ala Spring (natürlich nicht so mächtig) ist.

zu Doctrine:
Ich würde die DBAL Komponente auf jeden fall für jegliche datenbank operationen verwenden, es ist eine sehr saubere architektur (mMn sogar besser als JDBC und soll was heißen) die sehr einfach zu verwenden ist, sowohl als OO-QueryBuilder als auch mit nativen Querys. Ich hab das schema tool von doctrine dbal für das installtool geprototypt und muss sagen es ließ sich relativ einfach integrieren.
Das Doctrine ORM kann man dann ja optional, je nach projekt/erweiterung einsetzen, wenn es für den core nicht genutzt werden soll.

Edit: für leute die im entwickler interna lesen können, verweise ich dort gerne auf meinen projekt einer alternative zu den DC_* treibern zu schaffen.

[andreas.schempp]

Ich finde wir sollten dieses Thema am Contao Camp diskutieren, denn hier kommen wir auf keinen grünen Zweig. Ich gebe allerdings Stefan recht, es hängt sehr vom Zielmarkt ab.

[Dani]

Finde ich genial, dass du dieses Thema anschneidest Leo!

Meine erste Priorität wäre eine Eigenentwicklung, also ein eigenes, gut optimiertes Framework. Da ich weiss, dass du sehr sauber programmierst, denke ich, das wäre die beste Variante. Da dies aber sehr viel Zeit in Anspruch nimmt, würde ich empfehlen das Kernteam von dir Leo auf drei bis vier Personen, denen du vertraust aufzustocken, damit es schneller vorangeht und du nicht die ganze Last zu tragen hast. Natürlich definierst du im Vorhinein gewisse Programmierrichtlinien, welche alle im Team akzeptieren und befolgen müssen, damit dem Contao das "original" nicht verloren geht und damit Third-Party-Entwickler wissen woran sie sind. Ebenso entscheidest du schlussendlich, wie, was und wo gemacht wird.

Meine zweite Priorität wäre das Yii-Framework. Ich denke dies ist gut und sauber programmiert.

[backbone]

@andreas:
Ich finde das gut, dass dies jetzt schon angesprochen wird! eine entscheidung / die finale diskussion sollte dann natürlich aufm CC stattfinden. wenn man das aber nicht jetzt schon vorbringt, dann kommen die leute unvorbereitet für diese diskussion dahin.

[leo]

Ich finde wir sollten dieses Thema am Contao Camp diskutieren, denn hier kommen wir auf keinen grünen Zweig. Ich gebe allerdings Stefan recht, es hängt sehr vom Zielmarkt ab.

Ich würde gerne jetzt schon mal anfangen, damit wir auf dem Camp mehr zu diskutieren haben als nur haufenweise Ideen. Außerdem werden ja auch nicht alle zum Camp kommen, deren Meinung potentiell interessant ist

[andreas.schempp]

@backbone: Damit beschäftigen wir uns doch schon seit Jahren, Leo hat schon auf dem Usertreffen 2008 von Contao 3 (Horst Eugen) gesprochen. Ich glaube damit hatten wir genug Vorbereitungszeit.

[Dani]

Ich würde gerne jetzt schon mal anfangen, damit wir auf dem Camp mehr zu diskutieren haben als nur haufenweise Ideen. Außerdem werden ja auch nicht alle zum Camp kommen, deren Meinung potentiell interessant ist

Sehe ich genau so.

[Toflar]

Um auch noch meinen Senf dazuzugeben:

a) fällt durch weil wir nicht mit Kanonen auf Spatzen schiessen sollten, oder wie das Sprichwort auch immer heisst^^
b) ist super nett, hab ich mir schon mehrmals angeguckt, aber kein PHP 5.3 ist ein no-go als Basis für eine neue Contao-Version
c) würde dann noch übrig bleiben, aber das Rad neu zu erfinden fände ich irgendwie auch unnötig und ich lehne mich mal soweit aus dem Fenster zu behaupten, dass wir niemals etwas besseres produzieren werden. Wir haben schlichtweg nicht die finanziellen, personellen und zeitlichen Ressourcen die andere Frameworks haben und bereits investiert haben.

Von daher würde auch ich trotz der bereits festgelegten Auswahl noch einmal auf Symfony 2 schielen...

[mgco3]

@Andreas
Leider haben einige User nicht and das Contao Camp zu kommen, dem entsprechend, finde ich es wichtig dass man es in der Community diskutiert.

@backbone
Wieso bevorzugst du das den abstraction layer, wenn eigentlich ein orm mehr sinn machen würde?



Schlussendlich muss ich sagen; Wichtig finde ich in erster Linie, dass man Patterns wie DI konsequent einsetzt, und ein sauberes MVC durchzieht. Dies würde auch die Extension-Entwicklung beschleunigen. Sprich hätte man ein konsequentes Model, wäre der Entwickler durchaus sicherzustellen, dass seine Extensions kompatibel zu neuen Versionen sind, alleine durch Unit- und Functional-testing

Ob man sich die Entwicklung eines neuen Frameworks und dessen Maintenance aufbürdet, muss schlussendlich der Hauptentwickler entscheiden. Jedoch ist es schade, bei so vielen _guten_ Frameworks, das Rad neu zu erfinden.

[Dani]

... ich lehne mich mal soweit aus dem Fenster zu behaupten, dass wir niemals etwas besseres produzieren werden. ...

Das sehe ich gar nicht so. Es gibt in vieler Hinsicht Optimierungsmöglichkeiten!

[backbone]

@leo.unglaub: Doctrine DBAL ist PHP5.3 und warum soll ich nicht das DBMS-Interface von Doctrine mit dem von JDBC vergleichen können? Es geht hier schließlich nur um Klassenhierarchien und Signaturen und nicht um Details der Implementierung. Abgesehen davon war das nur eine Randbemerkung, um zu zeigen das sich diese Architektur auch mit "Enterprise"-Frameworks messen kann, was die Bedienung im vergleich zu den Möglichkeiten betrifft.

@mgco3: Das ORM von Doctrine baut auf dem DBAL von Doctrine auf (ist ja logisch). Ich hab nix gegen ORM und finde das gut, aber es hat auch seine Schattenseiten in bestimmten Anwendungsfällen (hoch normalisierte große Datenbanken), da kann im Extremfall ein Entity-Fetch schon mal 100 DB-Abfragen auslösen (trotz LazyLoad).

[Dani]

ohne jemanden hier beleidigen zu wollen, aber gegen SF2 oder ZF kommen wir nicht an. Allein schon weil die bei weitem mehr man-power haben.

Das sage ich auch nicht, aber besser als Contao 2.10.1!

[BugBuster]

zu PDO:
Es ändert sich nicht die komplette vorgehensweise! man kann genau so stinknormale qrys absetzen wie mit mysqli

Ich fange aber mit PDO schon vorher an, beim Create Table Statement, damit ich mir keine Gedanke machen muss, brauche ich nun ein autoincrement oder eine Sequence.
Das mach PDO selbst. Wenn schon PDO dann auch das Feature verschiedene DB Systeme nutzen zu können.

Na klar kann ich ein Select Object nehmen und dann meine eigene Query absetzen, aber dann bin ich wieder in der Gefahr, nicht kompatibel zu sein zu anderen DB Systemen.

[backbone]

@BugBuster:
Natürlich sollte im Core dann die OO-Builder genutzt werden um plattformübergreifend zu sein, aber man ist nicht dazu gezwungen in etwaigen Eigenentwicklungen.
BTW. hat man mit Doctrine DBAL eine komplett abstrahierte Datenbankterminologie, man könnte relativ einfach ein XML-Format definieren, welches sich in diese Objekte übersetzen lässt und anschließend kann man mit den Doctrine SchemaDiffs die DB up- und downgraden. Das würde einem dieses programmatische Vorgehen für die die SDL der DB ersparen.

[backbone]

zu Yii: ich muss sagen ein erster blick ist nicht negativ aufgefallen, wenn es wirklich fullfeatured für PHP 5.3 kommt, muss man sich das auch mal genauer anschauen

[Sebastian]

HI

Ich bin für c) mit MVC (bei Zend abschauen) plus ORM (Doctrine).

Sebastian

[Flex]

Ich vote für Yii weil ich es für ein schönes Framework halte...

Zend hat mir ein Projekt gereicht, ich möchte keine Tausendzeichen Klassen haben

Das jetzige Contao Framework ist nett, keine Frage, aber ich denke man kann sich auf mehr Sachen konzentrieren, wenn man hier auf ein bestehendes Produkt aufbaut... Es ist einfach zusätzliche Entwicklungskraft für Contao. Noch dazu wäre es ein Wechseln von mootools zu jQuery, den ich auch nur befürworten kann...

Frühst möglicher Alpha Termin für Yii 2.0 wäre Dezember 2011... Ich fände die Wartezeit okay... Ein ORM wäre für mich kein Muss, wenn ich ehrlich bin...

[FloB]

a) dürfte nicht für unsere Bedürfnisse optimiert sein, und Kanonen und Spatzen und so.
b) kenn ich nicht, aber IMO nicht vor einer PHP5.3-Version einsetzen.
c) wäre auch mein Favorit. Ja, es wird wohl trotzdem zu großen Rewrites der Erweiterungen kommen, aber so einige Grundideen werden wohl erhalten bleiben, sodass der Aufwand nicht übermäßig groß wird. Es muss halt erstmal aufgeräumt und die ganzen Ablaufprozesse sauber durchdacht werden, sowie nützliche Funktionen bereitgestellt werden. Manches (an Verhalten und API usw.) sollte sich wahrscheinlich auch komplett ändern. Ob das jetzt ein Refactoring oder ein Rewrite ist, wird dann wohl Definitionssache bleiben .

[Toflar]

Noch dazu wäre es ein Wechseln von mootools zu jQuery, den ich auch nur befürworten kann...

Jaaaa nicht! In meiner Vorstellung eines guten Frameworks kann ich als Entwickler selbst entscheiden, mit welchem JS-Framework ich arbeiten will

[backbone]

Jaaaa nicht! In meiner Vorstellung eines guten Frameworks kann ich als Entwickler selbst entscheiden, mit welchem JS-Framework ich arbeiten will

Was das FE betrifft bin ich der gleichen Meinung! Sehe aber bisher keinen Lösungsansatz alle Funktionalitäten anzubieten, wenn man sich im FE für EINS der Frameworks entscheiden müsste... Also alle Core FE-Skripte in MooTools und jQuery Ausfertigung anzubieten finde ich HÖCHST unpraktikabel und übertrieben. Außer beide Frameworks zusammen einzusetzen, wenn benötigt, sehe ich keine Alternative.

Im BE würd ich auf jeden Fall bei MooTools bleiben, da sich durch die Objektorientierung viele Dinge viel schöner lösen lassen.

Letzteres impliziert natürlich, das im FE auch MooTools zum Einsatz kommt, insofern man zum Beispiel Widgets wiederverwenden möchte. Mit einer sauberen Architektur, könnten aber Thrid-Party-Extension auch jQuery Versionen aller (Core-)Widgets anbieten, indem Sie einfach eine Subklasse ableiten.

[jan.theofel]

Hallo zusammen,

ich bin für Variante c).

Jan

[jan.theofel]

Hallo Toflar,

Jaaaa nicht! In meiner Vorstellung eines guten Frameworks kann ich als Entwickler selbst entscheiden, mit welchem JS-Framework ich arbeiten will

Auf keinen Fall. Hier muss die klare Entscheidung für ein JS-Framework aus dem Contao Core kommen. Sonst hast du danach 10 Extensions die Mootools brauchen, 5 die jQuery und 5 weitere noch was ganz anderes. Die Lade- und Ausführungszeit der Webseite dankt - wenn das überhaupt noch lauffähig sein sollte.

Jan

[backbone]

Hallo Toflar,



Auf keinen Fall. Hier muss die klare Entscheidung für ein JS-Framework aus dem Contao Core kommen. Sonst hast du danach 10 Extensions die Mootools brauchen, 5 die jQuery und 5 weitere noch was ganz anderes. Die Lade- und Ausführungszeit der Webseite dankt - wenn das überhaupt noch lauffähig sein sollte.

Jan

Zumindest MooTools und jQuery kann man ohne Probleme nebeneinander einsetzen und wurde auch schon auf einer Tagung von einem MooTools-Entwickler (David Walsh wars glaube) anhand eines Use-Cases propagiert. Sofern man beide Frameworks über die google API bezieht und einen ausreichend schnellen PC hat, sollte das auch performance-mäßig iO sein.

Der Core selbst sollte sich natürlich auf ein Framework festlegen, aber Erweiterungen können durchaus Andere einsetzen, sofern diese zu dem im Core genutzen Framework konfliktfrei sind. Inwieweit dann Inkompatibilitäten zwischen den anderen Frameworks und Performanceprobleme entstehen, wenn man aus 10 Extensions 5 verschiedene Frameworks nutzt, obliegt im Zweifelsfall dem Seitenadministrator. Und wenn man den "Markt" der JS-Frameworks betrachtet, gibt es da egtl. nur MooTools und jQuery, was die "Otto-Normal"-Website angeht, für etwas größere oder speziellere Sachen dann vielleicht noch Sencha oder Dojo. Da MooTools und jQuery ohne Probleme miteinander können und es bei den meisten sich dann eh zwischen den beiden entscheidet, sehe ich hier keine Probleme, wenn man im FE auch andere Frameworks zulässt oder Thrid-Party-Entwickler jQuery-Alternativen zu den MooTools Core-Skripten schaffen (oder anders herum, je nachdem was eingesetzt wird).

[andreas.schempp]

Auf jeden Fall Mootools! http://jqueryvsmootools.com/

[Flex]

Also einen Vergleich von 2009 anzuführen, finde ich etwas irreführend, weil jQuery gerade in den letzten 2 Jahren extrem viel gemacht hat und imho ein schönes Framework ist...
Besonders durch die starke Verbreitung, der standardmäßige Einsatz in MediaWiki und die Menge an Plugins (gut, ich möchte nicht alle davon bewerten müssen) finde ich jQuery attraktiver als Mootools...

Und jQuery ist im Yii Core eben eingebaut.

[christian]

Ich bin für c).

Warum?
Weil es sich bewährt hat, gut funktioniert, immer weniger Bugs hat, auch für einen autodidaktischen Entwickler leicht nutzbar ist, exakt auf das passt, was man mit Contao machen kann und nicht zuletzt genau das ist, was Contao bekannt und beliebt gemacht hat.

Warum muss man immer auf irgendwelche neuen Züge aufspringen, nur weil es gerade en vogue ist oder man sich wieder ein Quentchen Verbesserung davon verspricht?

Eine Mega-Baustelle würde ich in einer kompletten Neuentwicklung sehen - das sage ich aber auch schon seit 3 Jahren...
Eine Neuentwicklung wäre nicht mehr Contao - man sollte sie konsequenterweise auch anders benennen - und wird garantiert erst mal dazu führen, dass nicht nur die Extension-Enwicklung bei 0 losgeht, sondern auch dazu, dass erst mal ein Riesen-Haufen neue Kinderkrankheiten ausgemerzt werden müsste.

Sprich: Bis das Ding die Reputation bei den Agenturen hätte, die Contao mittlerweile hat, gingen so einige Tage ins Land.

Von daher rate ich dazu, so was parallel und unabhängig zu entwickeln - wenn man die Zeit "übrig" hat.

Grüße,

Christian



PS: Ich weiss, das klingt konservativ, borniert und total unmodern. Aber ich habe seit der Dotcom-Blase (und davor) schon viele Pferde kotzen und einige Systeme kommen und gehen gesehen.

[andreas.schempp]

Danke Christian, genau meine Meinung (obwohl ich die DotCom-Blase nicht erleben musste )

[RainerG]

Die Methode C bietet weitestgehende Unabhängigkeit, bei den anderen beiden Möglichkeiten 'erkauft' man sich eine recht hohe Abhängigkeit.

Die Frage ist ja auch, wie weit ist der derzeitige Stand in Contao von dem gewünschten Zielbild entfernt?

[tril]

So, da ich jetzt erst die Zeit gefunden habe und quasi zu jeden 2. Beitrag hätte zitieren können, lasse ich es mal und versuche das Pferd anders aufzuziehen.

A. Macht es mehr Sinn ein Framework zu verwenden oder ein eigenes zu entwickeln?

Es macht definitiv mehr Sinn, eines oder mehrere vorhandene Frameworks zu verwenden. Das machen wir übrigens jetzt schon im großen Stil, Swift, Mootools, Mediabox, sind alles kleine Frameworks die zum Einsatz kommen.
Frameworks sorgen dafür, dass man sich mit verschiedenen Problematiken nicht mehr auseinander setzen muss und sich auf das wesentliche Konzentrieren kann!

B. Was für ein Framework brauchen wir?

Es ist nicht die Frage "Was für ein Framework...", sondern "Welche Funktion brauchen wir?"!

Als Softwareentwickler sehe ich einige Nachteile im aktuellen System.
Es gibt kein wirkliches MVC, weil ...
es gibt keine ausreichende Datenbankabstraktion (weder als Abstraction Layer, noch als Persistence Layer (ORM)) gibt.
es gibt kein umfangreiches Funktions-Toolkit (API) gibt, sondern eine Klassenhierarchie, aus der man nicht oder nur schwer ausbrechen kann.
es gibt keine transparente Verknüpfung zwischen Anzeige, Bearbeitung und Speicherung von Datensätzen gibt. (Dabei ziele ich vor allem auf die DCAs ab)
Außerdem gibt es kein gutes Template System.

Es geht also um den Kern von Contao. Zu behaupten, "man setzt ZF2 oder ähnliches ein und dann kommt da ein Contao raus, was lediglich noch den Namen Contao trägt" halte ich für übertrieben. Contao besteht aus mehr als nur dem Kern. Contao ist ein System, ein Zusammenspiel von Funktionen. Dieses Zusammenspiel und wie Contao grundsätzlich Funktioniert wird Contao beibehalten. Das ist es was Contao aus macht. Ich kann verstehen, dass Web-Entwickler eher ein Problem mit "Enterprise"-Patterns haben. Für Softwareentwickler sind sie imo ein muss, wenn man effektiv bleiben will. Das hat nix mit "auf den nächstbesten Zug aufspringen" zu tun. Diese Design und Software Patterns gibt es bereits seit vielen Jahren und sie haben sich bewehrt. In der Java Enterprise Welt geht ohne diese Patterns überhaupt nichts und Frameworks wie ZF2 holen diese Patterns teilweise gut, teilweise eher schlecht als recht in die PHP Welt, wo sie überhaupt nicht existieren.
Design Pattern erlauben es ein langfristig pflegbares, erweiterbares, modulares System zu entwickeln.
Aber ich glaube ich schweife ab, aber ich wollte einfach untermauern, dass ich definitiv dafür bin, das sich am Kern von Contao viel tun sollte, wenn wir mit den großen Fischen mithalten wollen.

C. Na, welches Framework denn jetzt?

Ganz einfach, ich würde eine Mischung anstreben.
Wir brauchen etwas, mit dem wir die folgenden Komponenten Abdecken können:
- DBAL, ORM, DAO
Dafür kommen aktuell scheinbar ZF2, Yii oder Doctrine in Frage.

- Funktion Toolkit
Das beste Funktion Toolkit ist PHP selbst. PHP5.3 ist noch mehr Objektorientiert aufgebaut und immer mehr Funktionen wandern in Klassen. (Stichwort: SPL). Hier kann ich nur folgendes sagen: Was wir von PHP (oder einem passenden Framework) bekommen, nutzen wir. Den Rest müssen wir sowieso selbst entwickeln. Aber dann bitte ohne Klassenhierarchie, statt dessen ausgegliedert in entsprechende Klassen.

- Transparente Verknüpfung zwischen Anzeige, Bearbeitung und Speicherung
Vermutlich haben sich die meisten schon gefragt, was ich damit meine. Ich kenne es aus CakePHP, das Bearbeitungsmasken automatisch erstellt. Diese Masken sind sogar ohne wenig Aufwand stark individualisierbar, obwohl sie automatisch generiert sind. Wir haben sowas aktuell mit den DCAs, doch die DCAs haben folgendes Problem. Die Datenbarbeitung und Datenstruktur sind voneinander getrennt, dadurch entsteht doppelter Aufwand. Warum nicht ähnlich wie bei CakePHP eine Datenstruktur definieren und im gleichen Zug, bspw. mittels Annotations (das würde dann Richtung Doctrine gehen) den DCA dynamisch konfigurieren. Andersrum könnte man auch sagen, wir haben schon den DCA, wieso muss ich die database.sql noch selber schreiben?

- Template System
Zu guter letzt, wieso ein Template System, wenn PHP doch selbst eines ist?
Antwort: Um dem MVC Pattern gerecht zu werden. Wer Smarty kennt wird wissen, dass Smarty mehr ist als einfach nur ein paar Variablen in eine HTML Dateien einzusetzen ist. Smarty ist selbst ein Abstraktionsframework, ich kann Funktionen in PHP definieren, die mir im Template zur Verfügung stehen. Ich kann mich durch ein ordentliches Template System auf den View konzentrieren, kann die Business Logik ohne großen Aufwand extrahieren und habe so gleich 2 Gewinne: 1. ist mein Template übersichtlicher, 2. ist meine Business Logik übersichtlicher, weil ich diese in einer PHP Klasse "ordentlich" niederschreiben kann.
Ich habe sehr oft den Fall, dass ich im Template nochmal Datenbankabfragen mache und viel Business Logik rein packe. Smarty bietet mir eine einfache, verständliche und komfortable Möglichkeit, diese zu extrahieren.

D. Mein Schlusswort

Um es in einem Satz nieder zu schreiben: Wir sollten uns nicht allen Möglichen Scheiß rein holen (in Anlehnung an die Eierlegendewollmilchsau ZF), aber wir sollten auch nicht immer das Rad "rudimentär" neu erfinden (Contao DBAL). Profitieren können wir natürlich von allen Frameworks. Für das Contao Camp halte ich es für Sinnvoll, wenn wir zusammen tragen, welche Vorteile welche Frameworks haben. Eventuell auch andere (kleinere) Frameworks in Betracht ziehen. Dann Redundanzen analysieren und am Ende alle Frameworks einander gegenüber stellen.
Das bzw. die Vorbereitung dahin sollte der Inhalt dieser Diskussion sein und nicht "Ja, ich will ein Framework", "Nein, ich will kein Framework" oder gar "Lass mich in Ruhe, ich bin zufrieden und brauche keine Verbesserung".
Zugegeben, ich kann mit Pro-/Kontra-Argumenten grade nur mit theoretischen Betrachtungen mithalten, weil ich die bisher genannten Frameworks entweder nur im Ansatz, oder aus der Dokumentation kenne. Frameworks mit denen ich früher gearbeitet habe sind bspw. CakePHP und Smarty. Aber auch wenn ich es eher theoretisch Betrachte, so denke ich, dass wir genug mit Praktischer Erfahrung in den verschiedenen Frameworks haben, dass die Mischung aus all dem uns zum Ziel führen wird.

MfG Tristan, der pseudo Theoretiker

@LeoUnglaub: Ich kann ja nicht die ganze Zeit ruhig zusehen