Welches Framework als Grundlage für Contao 3?

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.

c ++1

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.

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.

Zitat:

---

Zitat von leo

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.

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 :cool:

Kurz: C wäre meine Wahl.

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)

Zitat:

---

Zitat von leo.unglaub

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?

Zitat:

---

Zitat von lindesbs

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.).

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.

Zitat:

---

Zitat von leo

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.

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.

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.

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.

@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.

Zitat:

---

Zitat von 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.

---

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 :)

@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.

Zitat:

---

Zitat von leo

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. :)

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...

@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.

Zitat:

---

Zitat von Toflar

... 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!

@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).

Zitat:

---

Zitat von leo.unglaub

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! :)

Zitat:

---

Zitat von backbone

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.

@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.

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

HI

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

Sebastian

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...

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 ;).

Zitat:

---

Zitat von Flex

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 ;)

Zitat:

---

Zitat von Toflar

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.

Hallo zusammen,

ich bin für Variante c).

Jan

Hallo Toflar,

Zitat:

---

Zitat von 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

Zitat:

---

Zitat von jan.theofel

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).

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

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.

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.

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

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?

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. :cool:

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 :p

Eigentlich wollte ich mich als 'nicht Entwickler' ja aus dem ganzen raus halten... aber da heute Freitag ist, mach ich doch mal mit ;-)

1. Feststellung: Contao hat den Anspruch ein Enterprise CMS zu sein (oder zu werden).
Das ist seit dem Namenswechsel so und stand meine ich auch mal auf der HP irgendwo. Es ist auf jeden Fall für alle 'die Wert auf eine professionelle Internetpräsenz legen' (Zitat von contao.org).

Über die Jahre habe ich viel mit Entwicklern geredet und einiges mitbekommen.

Es ist Fakt, das Contao einige Stellen hat, wo es einfach nicht wirklich gut voran kommt und wo es Sinn macht, das es neu angegangen wird. Da gibt es einige Punkte, wie Medienverwaltung / Workflow / Rechteverwaltung die noch genauer sein könnte / ne bessere Suche und und und.
Genauer in die Details kann ich da nicht gehen (hab ja keine Ahnung *g*).

2. Feststellung
Leo sagt es selber, wenn wir bei einem Contao Framwork bleiben wird es eh so stark verändert, das es nicht kompatibel sein wird. Logisch, wenn man mal komplett aufräumt (man lernt ja dazu und weiß was man nach ein paar Jahren anders/besser machen würde) um dann auch in ein paar Jahren noch innovationen einbringen zu können ohne an die Grenzen zu stoßen.

Daraus resultiert für mich folgende Überlegung:
Wenn man bie etwas eigenem bleibt, dann kostet das einiges an Zeit, bis man an dem Punkt ist wo die Grundlegenden Dinge funktioniern. Warum dann nicht direkt ein Framework nutzen, was schon weiter fortgeschritten ist und einem dadurch Zeit spart und was auch in Zukunft von mehr als von einer Person weiter entwickelt wird?
Es ist also so oder so auf deuer Kostengünstiger ein Framework zu nutzen, was extern Entwickelt wird. Und das aus den gleichen Gründen, weshalb hier viele ein eigenes CMS fallen gelassen haben und jetzt Contao nutzen. Es sind die selben Gründe die wir allen unseren Kunden erzählen:
- Kostengünstig
- Weiterentwicklung ohne das man selbst was machen MUSS
- Viele Leute die auf Bugs und Sicherheit achten
- Es bringt eine fülle an Dingen mit die nicht erst noch entwickelt werden müssen! (vllt auch mehr als man meint zu brauche... aber mal ernsthaf, wenn ich mir anschaue was die Leute brauchen, dann merk ich, das die Leute irgendwie oft das brauchen was es noch nicht gibt *g*)

Und nun mal aus meiner Sicht als Anwender von Contao und warum ich bei Contao bin (leider kann bei sowas jeder nur für sich selber sprechen, es sei denn man macht eine Umfassende Umfrage etc.):
- Backend ist übersichtlich und für Redaktuere einfach aufgebaut
- Ich kann fast alles über Templates ändern und so anpassen wie ich das haben möchte.
- die Community ist nett, hilft einem, ist aktiv und man kann sich selbst beteiligen
- Contao läuft auf vielen Shared Hostern
- PHP/MySQL
- für kleine bis riesige Seiten alles machbar

Das sind die Punkte die für mich Contao ausmachen. Und genau diese Punkte können auch mit einem exterenen Framework erreicht werden. Das Backend kann praktisch genau so aussehen (wenn man will). Templates kann es so in der Art immer noch genau so geben usw.


Meine 2 Pfennig...

Viele Grüße

PS: doch etwas mehr geworden. und vllt etwas durcheinander... habs noch mal ein wenig sortiert...

Zitat:

---

Zitat von RainerG

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

---

Abhängigkeit von einem Framework ist keinesfalls schlecht. Zumindest nicht, wenn es sich um ein etabliertes Framework handelt.

Am Beispiel von Symfony2 könntest Du z.B. mal gucken wie viele davon abhängig sind, das fast 3000 Entwickler das Projekt beobachten und über 700 Forks existieren um das Ding besser zu machen.

So etwas können wir niemals erreichen. Ein eigenes Framework wird also niemals die Leistung haben, die ein bestehendes bereits hat und es wäre ein immenser Aufwand, wie das Leo auch selber erwähnt hat, das ganze neu zu schreiben.
Zudem, wer schreibt uns eine so umfangreiche Doku?
Antwort: Keiner. Es hat es bisher niemand getan, es wird es in Zukunft niemand tun.

Zitat:

---

Zitat von christian

Eine Neuentwicklung wäre nicht mehr Contao - man sollte sie konsequenterweise auch anders benennen

---

Stimmt doch gar nicht? Contao ist Contao, wegen der Benutzerführung, wegen dem modularen Aufbau, wegen der Community und der Extensions. Aber sicher nicht wegen der API. Es geht ja nur darum, was wir Contao unter die Haube setzen. Ich kann mir nicht vorstellen, dass ein etabliertes, gut dokumentiertes und weit verbreitetes Framework einen Nachteil bezüglich dessen generieren würde. Höchstens Vorteile, weil diejenigen die mit dem Framework schon gearbeitet haben, werden sich in Contao im Nu einlesen können. ;)

Zitat:

---

Zitat von christian

die Extension-Enwicklung bei 0 losgeht

---

Na hoffentlich muss sie das! Es gibt so viele Baustellen, die in Contao einfach schlecht gelöst sind, das muss man einfach komplett anders machen. Contao ist halt gewachsen, das ist ja auch überhaupt kein Vorwurf an Leo, aber man muss echt was machen. Die ganze DataContainer-Geschichte ist nett, aber völlig unflexibel. Die ganze Vererbungshierarchie muss weg. Richtiges MVC muss her. Namespaces müssen rein und, und, und...da kannst Du dich eh drauf einstellen, dass ausnahmslos jede Extension neu geschrieben werden muss. Egal ob nun mit Zend, Yii oder einem eigenen Framework ;)

Zitat:

---

Zitat von christian

dass erst mal ein Riesen-Haufen neue Kinderkrankheiten ausgemerzt werden müsste.

---

Weshalb ich eindeutig für die Verwendung eines Frameworks bin, das sich bereits am Markt etabliert hat.

Es geht ja wirklich um die Basis. Also um Dinge wie Caching, HTTP-Requests, ORM etc. Contao selbst wird ja dann auch noch quasi ein eigenes Framework bieten müssen, für Contao-eigene Funktionen.

Also wenn wirklich nur die drei Dinge zur Auswahl stehen, dann bin ich wohl für Yii, obwohl ich es schade fände, auf PHP 5.3-Features weiterhin zu verzichten, bis Yii 2 da ist:

Zitat:

---

Our next major release Yii 2.0 will be a complete rewrite of the framework on top of PHP 5.3.0+. It will not be fully compatible with 1.1.x. However, we will try every effort to make the transition as easy as possible.

Note: We are currently actively developing Yii 2.0. The earliest possible 2.0 alpha release may be in December 2011, but we cannot guarantee it.

---

Das tönt für mich auch so, als müsste man einiges wieder umbauen, wenn man mit der 1.1.x anfängt ;)

Übrigens finde ich auch den Ansatz von Tristan gar nicht mal so schlecht. Nehmen wir das beste von allem ;)

Ich arbeite mich gerade in Symfony 2 ein (mein erstes eigenständiges Framework) und denke oft darüber nach, wie sich die Logik (klassisches MVC) mit Contao wie es heute ist verbinden lässt. Ich für mich würde weniger die Frage stellen welches Framework als Basis dient, sondern viel mehr was Entwickler aktuell Contao mögen. Ich gehe nach meiner aktuellen Kenntnis nicht davon aus, dass sich die Philosophie des DCA Arrays mit einem klassischen MVS Framework verbinden lässt und würde trotzdem nach einem Weg dahin suchen. Der Redundante Code den ich selbst bei top aktuellen Frameworks wie Symfony 2 sehe (getter und setter für jede einzelne Eigenschaft eines Models) brauchen nicht nur Zeit in der Entwicklung, sondern müssen bei Aktualisierungen dann auch an X Stellen angepasst werden. Da ist man mit Contao heute einfach schneller.

Weil Freitag ist… (Danke lindesbs ;))

Zitat:

---

Ich gehe nach meiner aktuellen Kenntnis nicht davon aus, dass sich die Philosophie des DCA Arrays mit einem klassischen MVS Framework verbinden lässt und würde trotzdem nach einem Weg dahin suchen.

---

Überlege dir mal genau was das DCA eigentlich ist. Ein Data Container Array. Sprich diese kleinen oder auch grösseren Array's beinhalten nichts anderes als die einzelnen Konfigurationen zu den Feldern/Attributen.
Genau dasselbe was du sonst eigentlich in einem Model hast.

@Toflar… Tut mir leid ich mache es dir nach, und bringe einige Beispiele aus Symfony bzw Doctrine.

Code:

---

    /**
    * @ORM\Column(type="string", length=255)
    */
    protected $headline;

---

ist im Prinzp nichts anderes als

Code:

---

                'headline' => array
                (
                        'inputType'              => 'text',
                        'eval'                    => array('mandatory'=>true, 'maxlength'=>255)
                ),

---

nur hast du bei Contao im Prinzip eine Redundanz mit der database.sql, Und anstatt, dass du deine Business Logik sauber in deinem Model hast, hast du diese hier (bis auf die callbacks) komplett im Controller.

Zitat:

---

Der Redundante Code den ich selbst bei top aktuellen Frameworks wie Symfony 2 sehe (getter und setter für jede einzelne Eigenschaft eines Models) brauchen nicht nur Zeit in der Entwicklung, sondern müssen bei Aktualisierungen dann auch an X Stellen angepasst werden.

---

Ich musste mir einige Zeit überlegen was ich auf die Aussage antworten will. Ich hoffe du weist auf welchen Konzepten symfony aufbaut (OOP, ORM, RAD, DRY, KISS, TDD, YAML, etc). Wenn du dich mit OOP rumschlägst müsstest du wissen wie essenziell Zugriffsfunktionen sind. Wir sind nicht mehr bei Stand PHP4 wo alles "public" ist. Und wenn du mit Software Design Patterns vertraut wärest, würdest du diese auch schätzen.

Zu deiner Aussage, dass diese Zeit brauchen.. Ich weiss nicht wie du deine Objekte schreibst, aber ich lasse mir die in der Regel generieren. Noch weniger weiss ich wo du deine Logik unterbringst oder wie du Unit-Test schreibst...

P.S. MacKP was hast du bloss in diesem Thread verloren ;)

Zitat:

---

Zitat von dominik.zogg@gmail.com

was Entwickler aktuell Contao mögen.

---

Es gibt leider nur eines, was aus Software-Entwickler sicht, wirklich gut gelungen ist:
- FE-Module, CEs: Hier ist Leo, softwaretechnisch, ein guter Wurf gelungen. Es lassen sich einfach eigene komplexe Ausgaben erzeugen, die man auch sehr einfach konfigurierbar machen kann. Hier würde ein aufräumen lediglich etwas Code-Schubsen sein und bisschen Refactoring beinhalten.

Die anderen (zahlreichen!) Meilensteine von Contao sehe ich dann alle in der Anwender-, Webentwickler/designer-, Autoren-, Besucher-Ebene. Ziel eines Contao Rewrites sollte sein, diese Meilensteine besser in der API zu representieren und flexibel einsetzbar zu machen. Beispiel: Layouts existieren als eigene Klasse überhaupt nicht, lediglich eine verarbeitende Methode bekommt ein Layout-Datensatz übergeben. Noch ein Beispiel: Es gibt zwar verschiedene Page-Klassen, aber diese representieren nicht die egtl. Seite sondern nur wie sie gebaut wird. Weiterhin haben die Page-Klassen keinen gemeinsamen Vorfahr "Page".


Außerdem kräftiges +++ für tril und Toflars Beiträge

Ich muss Toflar mal etwas verteidigen, da du hier etwas harsche argumente anbringst, die mMn auf einer fehlinterpretation Toflars post basieren.

Zitat:

---

Zitat von mgco3

Code:

---

    /**
    * @ORM\Column(type="string", length=255)
    */
    protected $headline;

---

ist im Prinzp nichts anderes als

Code:

---

                'headline' => array
                (
                        'inputType'              => 'text',
                        'eval'                    => array('mandatory'=>true, 'maxlength'=>255)
                ),

---

nur hast du bei Contao im Prinzip eine Redundanz mit der database.sql, Und anstatt, dass du deine Business Logik sauber in deinem Model hast, hast du diese hier (bis auf die callbacks) komplett im Controller.

---

Semantisch ist das schon was anderes, das eine Beschreibt eine Datenbank-Spalte, das andere ein Eingabe-Widget. Beide haben durchaus ähnlich Eigenschaften.
Syntaktisch ist die obere Version natürlich wesentlich schöner (ja, subjektiv).

Zitat:

---

Ich musste mir einige Zeit überlegen was ich auf die Aussage antworten will. Ich hoffe du weist auf welchen Konzepten symfony aufbaut (OOP, ORM, RAD, DRY, KISS, TDD, YAML, etc). Wenn du dich mit OOP rumschlägst müsstest du wissen wie essenziell Zugriffsfunktionen sind. Wir sind nicht mehr bei Stand PHP4 wo alles "public" ist. Und wenn du mit Software Design Patterns vertraut wärest, würdest du diese auch schätzen.

---

Ich glaube du hast ihm hier nicht ganz verstanden. Er meint höchstwahrscheinlich, dass man eher auf MagicMethods zurückgreifen sollte um den Code etwas zu "verschlanken". Ich persönlich finde MagicMethods nicht besser, lieber 20 Setter/Getter, da man diese besser dokumentieren kann, durch autocompletition unterstützt werden und performanter sind.

Zitat:

---

Zu deiner Aussage, dass diese Zeit brauchen.. Ich weiss nicht wie du deine Objekte schreibst, aber ich lasse mir die in der Regel generieren. Noch weniger weiss ich wo du deine Logik unterbringst oder wie du Unit-Test schreibst...

---

Totschläger Argument, das lediglich den zitierten Autor denunziert. Um das zu ändern, bitte noch folgende Fragen dazu mit beantworten:
Mit welchen Tools lässt du den Code denn generieren? (Btw. mein Tool heißt STRG-C, STRG-V ;)) Welche konkreten Bestandteile einer Klasse lässt du genieren? Hast du schon eine Contao-Extension veröffentlicht, wo man sich solch produzierten Code mal anschauen kann?

(mgco3: nein das ist überhaupt nix persönliches. solches post entstehen natürlich im eifer des gefechts, und man sollte die größe haben, die vermeintlich aggressiveren Teile anders zu representieren und besser zu untermauern)

Zitat:

---

Ich muss Toflar mal etwas verteidigen, da du hier etwas harsche argumente anbringst, die mMn auf einer fehlinterpretation Toflars post basieren.

---

Ich glaube du hast ebenfalls etwas fehlinterpretiert. Ich kritisiere Toflar in keinster Weise. Hier noch ein Zitat von Yannick aus dem IRC:

Zitat:

---

[16:13] <Toflar> mgco3: wieso verteidigt mich Oli im Thread? Du hast doch gar nix gegen mich gesagt, du hast ja nur meine Aussagen untermauert?

---

Natürlich mit dessen Einverständnis hier gepostet.

Zitat:

---

Semantisch ist das schon was anderes, das eine Beschreibt eine Datenbank-Spalte, das andere ein Eingabe-Widget. Beide haben durchaus ähnlich Eigenschaften.

---

Nein, es ist die Deklaration eines Objekt-Attributes. Was ich damit ausdrücken wollte; Das DCA lässt sich nicht eins zu eins in eine MVC-Umgebung implementieren, wohl aber bieten sich andere Wege an für diesen Aufbau die nicht mal sehr weit hergeholt sind.

Zitat:

---

Ich glaube du hast ihm hier nicht ganz verstanden. Er meint höchstwahrscheinlich, dass man eher auf MagicMethods zurückgreifen sollte um den Code etwas zu "verschlanken". Ich persönlich finde MagicMethods nicht besser, lieber 20 Setter/Getter, da man diese besser dokumentieren kann, durch autocompletition unterstützt werden und performanter sind.

---

Dann hat er sich leider etwas unglücklich ausgedrückt.
Symfony 1 erhielt jede Menge "Magie". Diese wurden in Symfony2 entfernt, sprich der Entwickler ist explizit gezwungen seine Getter/Setter sowie '"magicfinders" selbst zu schreiben. Dies hatte unter anderem damit zu tun, dass das ganze zu undurchschaubar wurde.

Auszug von der Symfony Live:

Zitat:

---

Q. "One of the main goals was to reduce the magic. I was in the training yesterday. $this->get('orm.entity_manager') returns something that is not typesafe. I have no idea what it is. It feels like magic. Are there plans to have convenience functions so I have interface-safe methods?"

A. "It's not about magic really, it's about scope. Killing the magic means everything is explicit. We don't use __get, __set. None of that in Symfony 2 because it is a nightmare to debug. When you get the service there is no typing because you can't know what class it is (because the point is to offer multiple implementations)." The controllers use ->get, nothing else has to (?). (Some of this involves issues I haven't really made contact with yet)

---

Q. "One of the main goals was to reduce the magic. I was in the training yesterday. $this->get('orm.entity_manager') returns something that is not typesafe. I have no idea what it is. It feels like magic. Are there plans to have convenience functions so I have interface-safe methods?"

A. "It's not about magic really, it's about scope. Killing the magic means everything is explicit. We don't use __get, __set. None of that in Symfony 2 because it is a nightmare to debug. When you get the service there is no typing because you can't know what class it is (because the point is to offer multiple implementations)." The controllers use ->get, nothing else has to (?). (Some of this involves issues I haven't really made contact with yet)

Zitat:

---

Totschläger Argument, das lediglich den zitierten Autor denunziert. Um das zu ändern, bitte noch folgende Fragen dazu mit beantworten:
Mit welchen Tools lässt du den Code denn generieren? (Btw. mein Tool heißt STRG-C, STRG-V ) Welche konkreten Bestandteile einer Klasse lässt du genieren? Hast du schon eine Contao-Extension veröffentlicht, wo man sich solch produzierten Code mal anschauen kann?

---

Dies war ganz klar auf die Aussage "Der Redundante Code den ich selbst bei top aktuellen Frameworks wie Symfony 2 sehe (getter und setter für jede einzelne Eigenschaft eines Models) brauchen nicht nur Zeit in der Entwicklung, sondern müssen bei Aktualisierungen dann auch an X Stellen angepasst werden." bezogen.
Man kommt in der Objektorientierten Entwicklung nie umher getter und setter anzupassen oder zu ergänzen. Das DoctrineBundle bietet einem hierzu einige Shell-Tools zur Vereinfachung an (https://github.com/symfony/symfony/b...ineCommand.php). Dies meinte ich mit generieren.
Bei symfony1 unterschied sich das, da über das schema.yml Baseklassen erstellt wurden, die erwähnte Funktionalität beinhalteten. Hier nachzulesen: http://www.symfony-project.org/gentl...Layer-Doctrine und man seine Klassen dann davon abgeleitet hat.

Meine Aussage galt lediglich für symfony und nicht für Contao.

Zitat:

---

Zitat von tril

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.

---

Bei allen Überlegungen, welche Funktionalität wir brauchen, sollten wir auch an die Lizenz und die Systemvoraussetzungen denken. Doctrine ist z.B. LGPL 2.1, die bekannter Maßen nicht mit der Version 3 kompatibel ist. Zudem funktioniert die Unicode-Unterstützung erst ab PHP 5.3.6 und über die Verbreitung von PDO wurde ja auch schon etwas gesagt.

Sicherlich sind das lösbare Probleme, aber wir sollten sie beim wilden "ich kenne da auch noch eine Sache"-Posting berücksichtigen :)

Es wird ja langsam unheimlich mit Contao. Aus Kunden- und teilweise auch Agentursicht sehe ich da eine Abkündigung des Produkts Contao kommen. Es wird ein anderes Produkt geben, was man auch Contao nennt, da ist aber nichts updatefähig, die Seiten müssen mit neuem Framework und neuen Erweiterungen neu aufgesetzt werden, wie erkläre ich das den Kunden? Was gibt das für einen Sinn?

Kunden setzen auf ein CMS, weil man dadurch nicht dauernd die Seiten anpassen muss, Updates halten das System aktuell und die Inhalte passen weiterhin (klar, mit kleinen Release-Anpassungen). Contao ist gerade dabei sich in der Welt bekannt zu machen und in dem Moment machen wir einen Schnitt und beginnen von vorn?

Ich bin ganz klar für ein moderates c)

Zitat:

---

Zitat von leo

Zudem funktioniert die Unicode-Unterstützung erst ab PHP 5.3.6 und über die Verbreitung von PDO wurde ja auch schon etwas gesagt.

---

Da steht das PDO bis PHP 5.3.6 ein Sicherheitsproblem mit nicht-ASCII-kompatiblen Charsets hat.
UTF-8 ist kompatibel zu ASCII, von daher würde ich das als Problem bezeichnen was weniger als 1% der Leute haben wird.

Zitat:

---

Zitat von do_while

Es wird ja langsam unheimlich mit Contao. Aus Kunden- und teilweise auch Agentursicht sehe ich da eine Abkündigung des Produkts Contao kommen. Es wird ein anderes Produkt geben, was man auch Contao nennt, da ist aber nichts updatefähig, die Seiten müssen mit neuem Framework und neuen Erweiterungen neu aufgesetzt werden, wie erkläre ich das den Kunden? Was gibt das für einen Sinn?

Kunden setzen auf ein CMS, weil man dadurch nicht dauernd die Seiten anpassen muss, Updates halten das System aktuell und die Inhalte passen weiterhin (klar, mit kleinen Release-Anpassungen). Contao ist gerade dabei sich in der Welt bekannt zu machen und in dem Moment machen wir einen Schnitt und beginnen von vorn?

Ich bin ganz klar für ein moderates c)

---

Dann möchtest Du also quasi 2022 mit Contao 2.35.1 arbeiten und deine Kunden niemals von neuen PHP Features profitieren lassen?
Oder steigst Du dann auf ein anderes Produkt um, weil es Contao versäumt hat, am Puls der Zeit zu bleiben?

Zitat:

---

Zitat von do_while

Kunden setzen auf ein CMS, weil man dadurch nicht dauernd die Seiten anpassen muss, Updates halten das System aktuell und die Inhalte passen weiterhin (klar, mit kleinen Release-Anpassungen).

---

Man muss eben für viele viele neue Features oder eine Verbesserung auch Zeit investieren können.
Wenn man dem Kunden klar macht, dass er mit Version 2.X immernoch ein stabiles System besitzt sollte das doch kein unüberwindbares Problem sein. Solange das eben nicht zur Regel wird.

Bei kommerzieller Software muss man ja auch jedes mal investieren wenn ein Update kommt. Ob man Geld oder Zeit für neue Features investiert... man sollte das "ich bekomme alles umsonst" ein wenig anderst sehen.

Darf man noch eine Frage an dich, Leo, persönlich stellen?

Wie bist Du zu den drei Auswahlmöglichkeiten gelangt? Hast Du die irgendwie evaluiert, persönlicher Geschmack oder wie kommt es? :)
Wie stellst Du dir Option c) vor? Bei Null beginnen? Das wäre vielleicht auch noch wichtig für die Diskussionsrunde :)

Ausserdem finde ich es gut, dass sich jemand um die Lizenzfrage kümmert, die geht ja bei uns jeweils ein bisschen vergessen:cool:

Zitat:

---

Zitat von do_while

Es wird ja langsam unheimlich mit Contao. Aus Kunden- und teilweise auch Agentursicht sehe ich da eine Abkündigung des Produkts Contao kommen. Es wird ein anderes Produkt geben, was man auch Contao nennt, da ist aber nichts updatefähig, die Seiten müssen mit neuem Framework und neuen Erweiterungen neu aufgesetzt werden, wie erkläre ich das den Kunden? Was gibt das für einen Sinn?

---

1. Reden wir grade über eine Entwicklung, die für den Kunden imo erst in 1 bis 2 Jahren ein &ldquo;derartiges Problem&ldquo; bedeuten wird. Also ganz locker bleiben ;-)

2. Andere Systeme haben das gleiche Problem. T3 5 bspw. wird ebenfalls nicht Updatefähig sein. Der Update Leitfaden für Joomla 1.5 ist länger als deren Systemdokumentation. Es ist ein typisches Problem von umfassender Modernisierung.

3. Selbst wenn du an diesem Punkt bist, bin ich mir sicher, dass es eine Übergangsphase geben wird und du ohne Probleme bis zum nächsten Redesign mit dem Update warten kannst ;-)

Sent from my GT-P1000 using Tapatalk

Zitat:

---

Zitat von do_while

Contao ist gerade dabei sich in der Welt bekannt zu machen und in dem Moment machen wir einen Schnitt und beginnen von vorn?

---

Genau da sehe ich auch das Problem! Als wenn wir ein schlechtes Produkt oder gerade nichts zu tun hätten...

Zitat:

---

Zitat von Toflar

Dann möchtest Du also quasi 2022 mit Contao 2.35.1 arbeiten und deine Kunden niemals von neuen PHP Features profitieren lassen?
Oder steigst Du dann auf ein anderes Produkt um, weil es Contao versäumt hat, am Puls der Zeit zu bleiben?

---

Das ist doch wohl Unsinn. Ich möchte nur nicht, dass Contao 4 etwas völlig anderes ist als Contao 3, was sich wiederum grundlegend von Contao 2 unterscheidet. Natürlich sollte man - die wichtigsten - Entwicklungen aus dem Markt einfließen lassen. Aber sachte oder in ein neues, anderes Produkt!

Ich möchte jetzt niemandem zu nahe treten - aber für mich hatte sich sowas in der Art schon auf der Entwickler-Konferenz angedeutet: Wir haben mittlerweile einige Leute an Bord, die zwar sicherlich richtig was auf dem Kasten haben, aber die auch für Ihr Leben gerne Dinge verkomplizieren. Und damit - sorry - auf Dauer garantiert so einiges "verschlimmbessern". Auf der besagten Konferenz haben die sich bald selbst weg-abstrahiert...

Ihr werft hier jetzt schon mit derart vielen Begriffen durch die Gegend, dass mir ganz anders wird. Denkt doch bitte auch mal an die Leute, die damit arbeiten (müssen/wollen) und das auch nach aussen vertreten. Die haben nämlich nicht die Zeit, jeder technischen "Innovation" hinterherzulaufen, die brauchen Stabilität.

Contao - so wie es jetzt ist - ist ein prima System, was meiner Menung nach in den nächsten Jahren keinerlei grundsätzliche Änderungen benötigt, geschweige denn verträgt. Schon gar nicht aus Marketing- und Agentursicht! Der Erfolg ist mit Sicherheit zu einem großen Teil der Tatsache geschuldet, dass es eben NICHT nur auf Profi-/Enterprise-/Teilchenbeschleuniger-Entwicklermöglichkeiten ausgerichtet ist. Denkt doch bitte auch mal daran, was so eine Diskussion für eine Aussenwirkung hat. Bei Netscape haben damals 2 "extrem(!) verbesserte und totaaaaaal neue" Versionen das Aus bedeutet, den selben Mist machen die Firefoxleute jetzt auch wieder. Mir wäre es ganz klar am liebsten, diese ganze Diskussion würde so schnell wie möglich begraben. Wieso läuft die überhaupt - habt Ihr Langeweile??

Zitat:

---

Zitat von tril

1. Reden wir grade über eine Entwicklung, die für den Kunden imo erst in 1 bis 2 Jahren ein derartiges Problem bedeuten wird.

---

1 bis 2 Jahre sind verdammt kurz. Wenn ich nur so kurzfristig denken und in diesen Abständen meine Firma umkrempeln würde, wäre ich schon lange pleite.

Zitat:

---

Zitat von christian

Das ist doch wohl Unsinn. Ich möchte nur nicht, dass Contao 4 etwas völlig anderes ist als Contao 3, was sich wiederum grundlegend von Contao 2 unterscheidet. Natürlich sollte man - die wichtigsten - Entwicklungen aus dem Markt einfließen lassen. Aber sachte oder in ein neues, anderes Produkt!

---

Es will doch auch niemand das Prinzip von Contao verändern? Es geht doch um das Framework unter der Haube. Contao kommt bei den Endbenutzern super an, weil es einfach und verständlich ist. Das will ich auch um keinen Preis hergeben. Aber davon war doch auch nie die Rede?
Meinen Kunden ist es egal, was da drunter läuft. Hauptsache die Benutzerführung ist nett und das wollen wir nicht kippen, sondern verbessern.
Aber das hat doch nix mit dem Framework zu tun? :)

Zitat:

---

Zitat von Toflar

Wie stellst Du dir Option c) vor? Bei Null beginnen? Das wäre vielleicht auch noch wichtig für die Diskussionsrunde :)

---

Ich habe ein eigenes MVC-Framework in der Schublade liegen, dass auf den Konzepten des Contao-Frameworks basiert und echten MySQL- und Oracle-Support bietet (DBAL). Dieses müsste man auf PHP 5.3 portieren, konsequent auf Performance trimmen und die Ajax-Unterstützung überarbeiten. Darauf basierend würde ich dann eine Sammlung von Widgets programmieren und schließlich Contao portieren.

Hierzu ist anzumerken, dass wir natürlich nicht mit jeder neuen Major ein neues Framework verwenden und die API komplett umschmeißen wollen! Aber ich denke wir sind uns einig, dass Contao einmalig auf echte "MVC-Beine" gestellt und mit einer vernünftigen API ausgestattet werden muss, oder? Von diesem Punkt aus wird das Framework dann nur noch weiter entwickelt.

@mgco3:
Mit der Codegeneration dachte ich du meinst jetzigen Contao-Entwicklungs-Workflow, weil du zu Toflar sinngemäß sagtest "Du schreibst deine Klassen noch selber?". Missverständnis geklärt.
Trotzdem hatte der Post einen, für mich, zu aggresiven Grundton, aber ist ja alles kein Problem. Toflar kommt damit klar, ich würde es auch tun, aber es gibt auch Leute die man damit sehr schnell "abwürgt", deswegen wollt ich da etwas einschreiten. In diesem Sinne nehm ich alle nicht-inhaltlichen Äußerungen zurück und behaupte das Gegenteil ;)

@christian

Zitat:

---

Zitat von christian

Genau da sehe ich auch das Problem! Als wenn wir ein schlechtes Produkt oder gerade nichts zu tun hätten...

---

Aus Sicht eines Software-Architekten ist Contao kein sehr gutes Produkt. Klingt hart, ist aber so. Dafür hat Contao andere Stärken, wie ich weiter oben schon bemerkte. Und Ziel dieser Modernisierung ist es nicht Contao seiner Stärken zu berauben, sondern die Schwächen zu entfernen und vll sogar auch in eine Stärke umzuwandeln! Und eine saubere Architektur ist nun mal Grundlage dafür, dass Contao für mehr als "nur" kleine bis mittlere Websiten oder designerisch anspruchsvolle Websiten (die auch noch gut zu pflegen sind) verwendet wird.

Zitat:

---

Ich möchte jetzt niemandem zu nahe treten - aber für mich hatte sich sowas in der Art schon auf der Entwickler-Konferenz angedeutet: Wir haben mittlerweile einige Leute an Bord, die zwar sicherlich richtig was auf dem Kasten haben, aber die auch für Ihr Leben gerne Dinge verkomplizieren. Und damit - sorry - auf Dauer garantiert so einiges "verschlimmbessern". Auf der besagten Konferenz haben die sich bald selbst weg-abstrahiert...

Ihr werft hier jetzt schon mit derart vielen Begriffen durch die Gegend, dass mir ganz anders wird. Denkt doch bitte auch mal an die Leute, die damit arbeiten (müssen/wollen) und das auch nach aussen vertreten. Die haben nämlich nicht die Zeit, jeder technischen "Innovation" hinterherzulaufen, die brauchen Stabilität.

---

Die Theorie von den meisten dieser "technischen Innovationen" stammen aus den 80er/90ern und ist spätestens seit Java und .NET Standard in der Entwicklung von mittlerer bis größerer Software. Nicht falsch verstehen: Dafür das der Contao-Core ein Ein-Mann-Projekt ist, sind die gebotenen Anwenderfunktionen genial. Nur halt eben nicht, was den Entwicklern geboten wird. Ich behaupte einfach mal das Dinge wie Avisota, Catalog und Isotope noch viel weiter wären, wenn man ein sauberes, besseres, architekturiertes Framework unter Contao hätte.

Zitat:

---

Contao - so wie es jetzt ist - ist ein prima System, was meiner Menung nach in den nächsten Jahren keinerlei grundsätzliche Änderungen benötigt, geschweige denn verträgt.

---

Da stimme ich dir nur zu, wenn du von den Anwenderfunktionen sprichst, nicht jedoch wenn du dich damit auf das "Framework" beziehst. Bei den Anwenderfunktionen würden Contao lediglich ein paar Comfortfunktionen mehr gut stehen.

Zitat:

---

Schon gar nicht aus Marketing- und Agentursicht! Der Erfolg ist mit Sicherheit zu einem großen Teil der Tatsache geschuldet, dass es eben NICHT nur auf Profi-/Enterprise-/Teilchenbeschleuniger-Entwicklermöglichkeiten ausgerichtet ist. Denkt doch bitte auch mal daran, was so eine Diskussion für eine Aussenwirkung hat.

---

Die Auswirkungen für den Anwender, wären egtl "nur" das er für die ersten 6-18 Monate auf einige alt-gediente Erweiterungen verzichten müsste. Aber ich zweifle keine Sekunde daran, das jede gute Extension für das jetzige Contao innerhalb von 0,5-2 Jahren angepasst wäre und vll anschließend sogar noch besser ist!

Zitat:

---

1 bis 2 Jahre sind verdammt kurz. Wenn ich nur so kurzfristig denken und in diesen Abständen meine Firma umkrempeln würde, wäre ich schon lange pleite.

---

Contao gibt es seit über 5 Jahren. Zum Zeitpunkt wo die Modernisierung einen RC Status erreicht, wird Contao sicher 7 Jahre auf dem Buckel haben. Langfristig Planung, OK, aber das Contao modernisiert werden sollte steht auch schon seit 2 Jahren "fest". Irgendwann muss man damit anfangen und diese Diskussion ist der logische erste Schritt.

Mhhh... hitzig hitzig hier... und das bei einer schwere Thematik.
Ich rede ja schon seit Jahren davon, dass wir die API einiges verschlanken bzw. restrukturieren sollen.
Auf der Konferenz kamen wir, soweit ich mich erinnere, jedoch schon soweit, dass wir kein neues Framework wollen aud dem wir basieren (alles auf Null reset quasi).

Ich schlage daher vor, dass wir unseren bisherigen Weg weiter verfolgen und unser eigenes Framework strukturieren.
Hierbei sollten (myssen) wir definitiv auf andere Bestandteile zuryckgreifen, welche wir integrieren (ORM => Doctrine und Konsorten, JSlib => mootools und jQuery, Swift, FPDF, ...).
Diese sollten dann jedoch dahingehend angepasst werden, dass sie in unser Framework passen.
Vorteil: "Code&Feel" von Contao bleibt weitestgehend erhalten, schnell zu guten Ergebnissen zu kommen.
Nachteil, man muss eben diese benutzten Libraries anpassen und selbst up to date halten.

Einen wesentlichen Fokus sollten wir IMO aber dann auf Modularitaet legen. Strikt alles von einander trennen und exakte Schnittstellen zwischen Bibliotheken definieren.
Etliche koennen davon dann auch ins ER wandern und als Basis fyr Extensions dienen. KISS to the max im Endeffekt.

Ich bin strikt dagegen Zend zu nehmen, welches 30 MB Ballast bringt von dem wir dann 0.5% verwenden werden bzw. wirklich brauchen (hiessen wir nicht mal TYPOlight? Ich assozieierte den Namen damals fyr mich zu einem guten Teil mit "lightweight API" und somit das Gegenteil von bloated - Warum sollte dann Contao eine fette Sau werden).
Dieses Risiko des Ballastes tragen wir mit egal welchem externen Framework, es sei denn wir splitten es auf und stellen es dann via ER als splitup zur Verfygung.

Vollkommen richtig ist, dass wir zunaechst die Ziele definieren myssen, wo Contao hin soll.
Meiner Meinung nach: "Weltherrschaft" :)
Genauer:

Aus Anwendersicht:

• Das Beste System zu sein, mit dem man (ein bisschen Einarbeitungszeit vorausgesetzt, eben wie bisher) nach kurzer Zeit zu guten Ergebnissen kommt.
• Eine Aktive Community besitzen.
• Extensions weiterhin per ER installieren (saubere Paketverwaltung)

Aus Entwicklersicht:

• Das System muss sauber erweiterbar sein, auch (und das fehlt uns bisher) in Bereichen des Kerns (HOOKs schoen und gut, aber man muss eben gelegentlich auch Teile des Kerns updatesafe aendern koennen).
• Weitere Frameworks sollten bei Bedarf einbindbar sein (siehe obige Anmerkung betr. ER und libraries, ich hab mir den autoloader z.B. schon mal um einen PEAR handler erweitert, damit ich PEAR klassen verwenden kann).
• Schlanker Kern und Performance orientiert.

Allgemein finde ich das Konzept/Grundprinzip in der Art von PEAR klassen sehr interessant (ich will damit in keinster Weise nun PEAR reinbringen, bitte nicht falsch verstehen). Jeder hat abgekapselte Teilbereiche und entwickelt darin seinen Teil.
Wenn man das nun als Grundlage des Contao Frameworks umsetzen wyrde, haetten wir endlich eine strenge Trennung von allen Teilbereichen, welche dennoch genau auf unsere Anforderungen zugeschnitten sind.

Ich votiere also dazu, dass wir beim eigenen Framework bleiben, dieses jedoch massiv unters Messer nehmen und auseinanderrupfen, sortieren und dann modular wieder zusammenstecken.
Man kann ggf. sogar noch bei den kritischen Elementen einen Wrapper bereitstellen, welcher die bisherige Database Klasse z.B. simuliert (sollte z.B. nicht das grosse Thema sein).
Auf diese Weise kann man alte Erweiterungen zum Grossteil noch ein wenig mitschleppen, die noch nicht (komplett) umgestellt sind.

Ich habe auch grosse Bedenken, wie do_while, dass wir durch einen kompletten Neuanfang einen Grossteil der userbase verlieren. Doch dies laesst sich theorethisch vermeiden.

Egal fyr welchen Weg man sich nun entscheidet, ich lege nochmals grossen Wert auf eine staerkere Modularisierung und dann ggf. maintainability. Von mir aus analog des von leo-unglaub so geliebten Debian mit apt, wo es saubere "provides und conflicts" Definitionen bei Paketen gibt (wir sollten das conflicts jedoch mal auf ein minimum reduzieren).
Eine solche Modularisierung ist meiner Meinung nach mit der Benutzung "EINES" Frameworks nicht mehr gegeben, da hat man automatisch dann Ballast und ggf. einen "Wust an Verflechtungen".

Im Endeffekt sollten wir uns da als Entwickler mal richtig bewusst werden was der Core eigentlich ist. Hierbei explizit als Entwickler und nicht als Anwender/Marketing manager, welche das Auslieferungspaket mit zig Extensions meinen.

Der Core ist fyr mich nichts anderes als das Framework, welches es mir erlaubt Inhalte zu erfassen, zu bearbeiten und auszugeben.
Keine News, kein Newsletter, keine FAQ, Glossar, Backend Aufgabenverwaltung... und was wir alles so haben.
Das sind alles schon wieder konkrete Anwenungen/Extensions, welche auf den Core zur Erledigung ihrer Aufgaben zuryckgreifen.

Streichen wir also zusammen was der Core letztendlich braucht:
Datenbankanbindung (mit ORM und vorzugsweise multi engine faehig).
+ String behandlungs libraries
+ Mail sending libraries
+ Templating engine
+ Authentification&Authentication Framework.
=========
Contao Core

Alles Weitere sollte man als "Ausserhalb des Core" betrachten.
Wie man den Weg dann konkret aus Implementierungssicht beschreitet kann man leider schlecht sagen, daher ist die Wahl eines "Frameworks" hierbei auch nicht einfach zu beantworten.

Mir ist es relativ egal, solange obige Grundvoraussetzungen erfyllt werden.

Gruss
Chris

ich wäre auch für Variante C

oder mann kombiniert und lässt dem Nutzer die auswahl ob er ZEND nimmt oder Contao, so können alle eingefleischten Contao Fans weiter damit arbeiten und neue oder alte Hasen die gern mit Zend arbeiten sich dies zu nutze machen und wählen, aber Variante C würd ich auf jeden Fall mit dabei haben wollen. Ich denk so wird man mit der Zeit schon mitbekommen welches besser ist.

Zitat:

---

Zitat von xtra

Ich schlage daher vor, dass wir unseren bisherigen Weg weiter verfolgen und unser eigenes Framework strukturieren.
Hierbei sollten (myssen) wir definitiv auf andere Bestandteile zuryckgreifen, welche wir integrieren (ORM => Doctrine und Konsorten, JSlib => mootools und jQuery, Swift, FPDF, ...).
Diese sollten dann jedoch dahingehend angepasst werden, dass sie in unser Framework passen.
Vorteil: "Code&Feel" von Contao bleibt weitestgehend erhalten, schnell zu guten Ergebnissen zu kommen.
Nachteil, man muss eben diese benutzten Libraries anpassen und selbst up to date halten.

---

Andere "kleinere" Frameworks, ja! Diese "Anpassen", nein! Soetwas wie Doctrine, Mootools oder Swift passt man ich "mal eben" an, oder aktualisiert es "mal eben", wenn da eine neue Version kommt.
Beispiel: Ich persönlich finde den Contao-Wrapper um die Swift-Lib unnötig. Da er die Swift-Lib komplett versteckt.
Wenn du damit meinst, das man die Erweiterungsmöglichkeiten der Frameworks nutzt um Contao-spezfische Dinge umzusetzen, dann natürlich dickes JA. Auch eine sehr effektive Methode wären Factorys, zum Beispiel für Swift:

PHP-Code:

---

$objMail = ContaoMailFactory::createMail($recipient, $subject, $text); // gibt eine echtes Swift-Objekt zurück
ContaoMailTransport::sendMail($objMail); // wählt anhand der Contao konfiguration den richtigen Swift_Transport aus und sendet die Mail über diesen. 


---

Zitat:

---

Aus Anwendersicht:

• Das Beste System zu sein, mit dem man (ein bisschen Einarbeitungszeit vorausgesetzt, eben wie bisher) nach kurzer Zeit zu guten Ergebnissen kommt.
• Eine Aktive Community besitzen.
• Extensions weiterhin per ER installieren (saubere Paketverwaltung)

---

+++

Zitat:

---

Aus Entwicklersicht:

• Das System muss sauber erweiterbar sein, auch (und das fehlt uns bisher) in Bereichen des Kerns (HOOKs schoen und gut, aber man muss eben gelegentlich auch Teile des Kerns updatesafe aendern koennen).
• Weitere Frameworks sollten bei Bedarf einbindbar sein (siehe obige Anmerkung betr. ER und libraries, ich hab mir den autoloader z.B. schon mal um einen PEAR handler erweitert, damit ich PEAR klassen verwenden kann).
• Schlanker Kern und Performance orientiert.

---

+++++++++++++++++++++++++++++++++++

Zitat:

---

Streichen wir also zusammen was der Core letztendlich braucht:
+ Datenbankanbindung (mit ORM und vorzugsweise multi engine faehig).

---

Eigenentwicklung NICHT sinnvoll, PDO/Doctrine DBAL sind allrounder und gut architekturiert in diesem bereich. Im Doctrine Falle kann man das ORM sogar optional machen

Zitat:

---

+ String behandlungs libraries

---

Eigenentwicklung + PHP Standard sinnvoll

Zitat:

---

+ Mail sending libraries

---

Swift mit Contao-spezifischen Helpern

Zitat:

---

+ Templating engine

---

Eigenentwicklung sinnvoll

Zitat:

---

+ Authentification&Authentication Framework.

---

Eigenentwicklung sinnvoll


Punkte die meiner Meinung nach fehlen:
+ Form library Eigenentwicklung sinnvoll
+ Extension Packet Format Eigenentwicklung sinnvoll

Zitat:

---

Zitat von leo

Ich habe ein eigenes MVC-Framework in der Schublade liegen, dass auf den Konzepten des Contao-Frameworks basiert und echten MySQL- und Oracle-Support bietet (DBAL). Dieses müsste man auf PHP 5.3 portieren, konsequent auf Performance trimmen und die Ajax-Unterstützung überarbeiten. Darauf basierend würde ich dann eine Sammlung von Widgets programmieren und schließlich Contao portieren.

Hierzu ist anzumerken, dass wir natürlich nicht mit jeder neuen Major ein neues Framework verwenden und die API komplett umschmeißen wollen! Aber ich denke wir sind uns einig, dass Contao einmalig auf echte "MVC-Beine" gestellt und mit einer vernünftigen API ausgestattet werden muss, oder? Von diesem Punkt aus wird das Framework dann nur noch weiter entwickelt.

---

Was ich hierzu noch sagen wollte: Damit wäre Option c) eine Art die Katze im Sack zu kaufen. Bei dem "vorherigen" Punkt c) gehen die meisten sicher von aus, das sie die Grundentwicklungen mit beeinflussen können. Nach deiner Aussage kann ich mich nicht für c) entscheiden, da ich nicht weiß was dahinter steht. Ein Beispiel wie dieses "ominöse" Framework aus der Schublade anzuwendern wäre oder noch besser Möglichkeiten den Code zu sehen, wären natürlich besser. (Das sind keine Forderungen, nur Hinweise)

Zitat:

---

Zitat von Toflar

Es will doch auch niemand das Prinzip von Contao verändern? Es geht doch um das Framework unter der Haube. Contao kommt bei den Endbenutzern super an, weil es einfach und verständlich ist. Das will ich auch um keinen Preis hergeben. Aber davon war doch auch nie die Rede?
Meinen Kunden ist es egal, was da drunter läuft. Hauptsache die Benutzerführung ist nett und das wollen wir nicht kippen, sondern verbessern.
Aber das hat doch nix mit dem Framework zu tun? :)

---

Nun aus meiner Sicht gehört aber eben auch dazu, dass bestehende Extensions weiter verwendet werden können, und nicht komplett überarbeitet werden müssen. Darüber hinaus muss ein Update in einer vertretbaren Zeit durchgeführt werden können und eben nicht eine komplette neu Installation bedeuten.

Warum also nicht zukunftsfähige Schnittstellen entwerfen, die dem Funktionsumfang des heutigen Standes entsprechen. Diese Schnittstellen können dann auf dem aktuellen Kern umgesetzt und veröffentlicht werden und bieten so die Möglichkeit Erweiterung frühzeitig auf die neue Architektur vorzubereiten. Wenn die Schnittstellen stehen kann dann der "neue" Kern entwickelt werden.

Sicherlich bedeutet dieses Vorgehen eine gewissen Mehraufwand - gibt aber dafür allen Beteiligten genügend Zeit langsam um zu steigen.

Zitat:

---

Zitat von grmllin

Nun aus meiner Sicht gehört aber eben auch dazu, dass bestehende Extensions weiter verwendet werden können, und nicht komplett überarbeitet werden müssen. Darüber hinaus muss ein Update in einer vertretbaren Zeit durchgeführt werden können und eben nicht eine komplette neu Installation bedeuten.

---

Erstens ist es den Extensions egal, was hinter Contao als Framework läuft. Und zweitens möchte wohl niemand im Jahr 2016 mit Erweiterungen arbeiten, die im Kern den Stand des Jahres 2006 repräsentieren. Auch Du surfst heute nicht mehr mit Netscape.

Zitat:

---

Zitat von grmllin

Warum also nicht zukunftsfähige Schnittstellen entwerfen, die dem Funktionsumfang des heutigen Standes entsprechen. Diese Schnittstellen können dann auf dem aktuellen Kern umgesetzt und veröffentlicht werden und bieten so die Möglichkeit Erweiterung frühzeitig auf die neue Architektur vorzubereiten. Wenn die Schnittstellen stehen kann dann der "neue" Kern entwickelt werden.

---

Die Schnittstellen sind der neue Kern.

Carolina.

Zitat:

---

Zitat von lucina

Die Schnittstellen sind der neue Kern.

---

Für mich sind Schnittstellen nichts weiter als Interfaces - Vereinbarung wie z.B. Extensions mit dem Core kommunizieren können.
Darum sehe ich das eben nicht so - ich denke man sollte die neuen Schnittstellen über den aktuellen Kern legen. Extensions können nun wahlweise die Alte oder die Neue Variante benutzen.

Als nächster logischer Schritt folgt dann die Überarbeitung des eigentlichen Kerns und mit der Veröffentlichung dieses Kerns fällt die alte Methode weg. Wenn ich mal von den oben genannten Zahlen von 1 bis 2 Jahren Entwicklungszeit ausgehe wird es so wahrscheinlich 1,5 bis 2,5 Jahre dauern. Dafür kann man dann aber einen vernünftigen Schnitt machen und alle Erweiterungen haben mindestens 1 Jahr Zeit sich anzupassen.

Ich zweifle stark daran, dass man einfach so die bestehenden Core-Funktionen durch komplett andere Interface drücken kann. Dafür bräuchte man sicher soviel Glue-Code, wie man für eine Neuentwicklung bräuchte... und selbst, wenn man diesen zusammen bekäme, würden sich sicher enorme Einschnitte in Sachen Performance ergeben.

Außerdem: Solange die alten Möglichkeiten bestehen bleiben, werden diese auch weiterhin verwendet werden... vgl. Browser-Update-Problem

Weiterhin ist so ein Designen wesentlich aufwendiger, da man nicht einfach mal so Interfaces designt, die im Alltag auch gut, einfach und sauber Anzuwenden sind. Dazu gibt es Prototyping und diesen enormen Mehraufwand wird sich hier keiner Antun, da es einfach nicht bezahlt wird.
Nochmal: Niemand bezahlt Leo oder Extension-Entwickler für irgendeine Art von SLA oder Wartungsvertrag... Das heißt ich persönlich habe kein Problem damit Anwendern meiner (freien) Erweiterungen zu sagen: Ja, die Erweiterung funktioniert nicht mehr und ich werde sie auch erst updaten, wenn ich Sie selbst brauche oder ich mal Lust dazu habe. Wenn jemand eine Erweiterung brauch, dann wird er sie für Geld IMMER bekommen.

Zitat:

---

Zitat von xtra

Der Core ist fyr mich nichts anderes als das Framework, welches es mir erlaubt Inhalte zu erfassen, zu bearbeiten und auszugeben.
Keine News, kein Newsletter, keine FAQ, Glossar, Backend Aufgabenverwaltung... und was wir alles so haben.
Das sind alles schon wieder konkrete Anwenungen/Extensions, welche auf den Core zur Erledigung ihrer Aufgaben zuryckgreifen.

---

(+1)

Das Argument "viele Funktionen out of the box" kann ja trotzdem beibehalten werden, wenn eben diese Erweiterungen weiter vom Core-Team gepflegt und erweitert werden.
So kann man Contao auch optimal anpassen bzw. hat immer die optimale Installation. Weil z.B. das Newsletter-Modul benötigen viele nicht. Wer es benötigt kann es trotzdem einfach übers ER installieren.

Du hast recht - es ist sicher kein Kinderspiel!!!

Aber:

1. Ich bin gerne bereit bei derartigen Arbeiten zu unterstützen
2. Währe Contao nicht das erste Produkt welches aufgrund Fehlender Migrationsstrategien vom Markt verschwinden würde
3. Ist mein Post ledeglich eine erste Idee in Richtung Migrationsstrategie nicht eine perfekte Lösung

Mein Befürchtung ist einfach die, dass Contao3 komplett ohne passende Erweiterungen da steht bzw. alle Systeme die den Versionssprung mit machen wollen - neu aufgesetzt werden müssen und dementsprechend auf Version 2.xxxxx stehen bleiben. Beides sind für mich k.o. Kritierien und bedeuten letzten Endes das all die Arbeit die in Version 3.0 gesteckt wurde für die Katz war.

Es muss etwas passieren, aber bevor alles umstrukturiert wird müssen die Grundlagen für eine spätere Migration geschaffen werden.

Zu Erweiterungen hab ich weiter oben schon was gesagt. Es gibt so viele aktive Entwickler und viele Entwickler der größten Erweiterungen (isotope, catalog, avisota) befürworten hier auch mehr oder weniger eine nicht zwangsläufig abwärtskompatible Modernisierung. Effektiv können die meisten der Entwickler sicher schon 6 Monate vor Release eines RC mit den Erweiterungen anfangen. Also wird es sicher nicht dazu kommen, dass es gar keine Erweiterungen mit einem stable Release gibt...
Für die Grundfunktionen sehe ich Contao ziemlich Feature-Complete. Wie gesagt Comfortfunktionen hier und da, sind sicher noch nett. Also muss man auch nicht zwangsläufig updaten. Außer Theme+ fällt mir jetzt auch keine Must-Have Erweiterung ein, die in den letzten 6 Monaten veröffentlicht wurde (korrigiert mich da bitte).

Es gibt btw. auch genug Produkte die sich erst durch einen Rewrite richtig durchgesetzt haben. Genau soviele Produkte gibt es, die ewig auf alten Prinzipien rumgeritten sind und einfach von neuen innovativen Dingen abgelöst wurden. Niemand kann in die Zukunft sehen, also zählen solche Hypothesen nicht viel.

Edit: Ziel solch einer Modernisierung ist es übrigens auch nicht jedem Contao 2.x User die Möglichkeit zu "Press one Button and get shiny new Website" zu geben.

Liebe Entwickler,
ich als NON-(SEMI-Beginner-)Professional kann Eurer fachlichen Begründung zwar nicht überall folgen, bin aber dafür relativ geschockt, dass das bisherige Framework, das ja selbst hier als in sich genial bezeichnet wurde, in Zukunft einfach 'verschrottet' werden soll, obwohl es doch für einen Großteil von Webprojekten mehr als ausreichend ist.

Ganz persönlich frage ich mich nun, ob es mir auch in Zukunft möglich sein wird, relativ einfach kleinere und größere projektspezifische Anpassungen mit dem (welchem auch immer) neuen Framework umzusetzen. Ich hatte in der Vergangenheit wie sicher viele hier ansonsten mal mit TYPO3 und mit Joomla gearbeitet und beide eigentlich endgültig hinter mir gelassen, weil ich mit Contao endlich das für mich optimale (= gut handlebare!) System gefunden hatte. Nun bin ich mir nicht mehr sicher, ob das in Zukunft auch so sein wird. Ich möchte daher zu bedenken geben, dass nicht alle Nutzer, die mehr machen als fertige Module per Klick zu installieren, automatisch Vollblut-Informatiker sind und dass für diese der Reiz bei Contao eben auch in der Einfachheit des bisherigen Frameworks liegt.

Aber dieser Punkt scheint schon längst beschlossen und soll daher wohl nicht mehr zur Diskussion stehen. Nun verstehe ich auch, dass Contao definitiv nicht mehr TYPOlight sein soll. Schade.
Ich gehe aber zunächst einfach mal davon aus (=hoffe inständig), dass die 2er und 3er-Version noch eine ganze Weile nebeneinander bestehen werden.

Ansonsten finde ich die geplanten Neuerungen fernab der Frage der Notwendigkeit aber auch nicht unspannend und vote für B (Bloß kein Zend, viel zu komplex & wenn schon aktuelles MVC-etc-Framework, dann bitte auch eins, was bereits existiert & sich bewährt hat & wo sich die Einarbeitung dann ggf. auch außerhalb von Contao lohnt, meinetwegen auch ein anderes wie z.B. Symfony).

B++