Welches Framework als Grundlage für Contao 3?

[Toflar]

Wenn man eine Erweiterung erstellt oder den Core ansieht ist es verständlich die Logiken zu trennen.
Aber NICHT wenn ich mal eben eine kleine Anpassung für den Kunden mache um das Datum anders zu formatieren. Oder einen zweiten Newsfeed im News-Template darzustellen oder oder oder ... Das sind individuelle Anpassungen die den Kunden glücklich machen und mir paar Minuten Zeit kosten. Anders wenn ich dafür jetzt ne halbe Erweiterung schaffen müsste.

Die gehören aber nicht ins Template. Für Dinge wie Datum anders formatieren etc. könnte Contao eigene Twig-Funktionen bieten und das könntest Du auch mal schnell für den Kunden machen. Ist nicht viel aufwändiger und dafür sauber getrennt und wiederverwendbar für weitere Kunden
http://twig.sensiolabs.org/doc/advanced.html#functions

Können sicher auch andere Template-Engines

Auch wenn’s nicht gefällt, will ich mal noch ein weiteres Framework in die Runde werfen, welches vermutlich sehr gut für Contao 3 geeignet wäre: FLOW3.

Ich weiss, Performance-Tests sind immer so ne Sache. Aber 70x langsamer als SF2? Naja...
Hat btw auch einen Vergleich mit Yii und da kommt SF2 doch schon wesentlich besser weg
http://blog.newitfarmer.com/php/fram...r-performance/

[backbone]

Egtl hörts sich doch jetzt schon fast danach an:
1) Wir nehmen Symfony mehr oder weniger
2) Wir nehmen Leo's Framework

Ich glaube wir sollten uns auf 2 Grundvarianten die auch tatsächlich gewollt werden, reduzieren und bis zum Camp jedes "Lager" etwas zum presentieren hat.
Ich zum Beispiel, find Symfony auch toll, muss aber sagen, das es als Komplettframework vll zuviel des guten ist. Die Leute von Symfony schreiben selbst darüber soetwas wie: Das System besteht aus vielen unabhängigen Teilkomponenten (Twig, Doctrine, und auch einzelne Klassen(gruppen) die kein eigenes Projekt zur Verwaltung haben), die auch Einzeln eingesetzt werden können. Das Komplett Framework bringt aber Glue-Logic mit, die alles unter einen Hut bringt. (zum Beispiel die ganze Config-Methodik.) Deswegen würde ich hier Cherry Picken, hätte aber auch kein Problem mit dem Komplett-FW.

Mit 2. stehen wir nach wie vor so da, dass wir nicht wissen was Leo in seiner "Schublade" hat. Ich weiß nicht, ob er uns überhaupt Einsicht geben lassen will, aber falls doch sollte das vor dem CC empfehlen, denn da wird es sicher brühheiß in einer Presentation getan, sodass man kaum Möglichkeiten hat darüber zu reflektieren. (Bei Symfony schwanke ich zum Bsp zwischen Komplett und Teilweise hinher.)

[Babelfisch]

Ich weiss, Performance-Tests sind immer so ne Sache. Aber 70x langsamer als SF2? Naja...

Performance-Tests von Frameworks sind IMO kaum sinnvoll machbar und kaum aussagekräftig. Außerdem wurde da eine 1.0 Alpha getestet, bei der mit Sicherheit noch keine Optimierungen vorhanden sind. Dann sind bei dem Test wohl so wichtiges Sachen wie Caching und Datenbankzugriff außen vor gelassen worden, womit sich der Test leider selbst disqualifiziert. Was nützt mir ein Test, bei dem die für ein CMS wichtigsten Elemente nicht getestet worden?

FLOW3 war aber halt nur ein Vorschlag. Von Symfony2 habe ich bisher auch schon einiges gutes gehört und das ist sicherlich eine Überlegung wert.

Gruß

[backbone]

In FLOW sehe ich ganz abgesehen davon noch einen strategischen/marketingtechnischen Nachteil:
Es kommt von T3, wenn auch ein eigenes Projekt, kann jeder der sich damit 3 Minuten beschäftigt die Verbindung erkennen.
Man wird wieder stärker in die TYPO"light" Ecke gedrückt.

Natürlich hat es auch den Vorteil, das T3 Entwickler vll auch schneller in Contao reinkommen, aber ich denke der Teil an T3-nutzenden Agenturen wird dann so denken: T3 kann alles, warum sollten sich unsere Entwickler etwas umschulen?

[xunum]

Was spricht gegen eine Lösung a/b + c ?

[backbone]

Was spricht gegen eine Lösung a/b + c ?

Versteh jetz nicht ganz wie das gemeint ist?
ZF/Yii + Leos Schublade?
Was soll das bedeuten?

[christian.kolb]

Was spricht gegen eine Lösung a/b + c ?

Was sollte das bringen? Das wäre doch nur nötig wenn eines der Frameworks etwas nicht enthält was Contao benötigt.

Gruß
Christian

[ApoY2k]

Die Leute von Symfony schreiben selbst darüber soetwas wie: Das System besteht aus vielen unabhängigen Teilkomponenten (Twig, Doctrine, und auch einzelne Klassen(gruppen) die kein eigenes Projekt zur Verwaltung haben), die auch Einzeln eingesetzt werden können. Das Komplett Framework bringt aber Glue-Logic mit, die alles unter einen Hut bringt. (zum Beispiel die ganze Config-Methodik.) Deswegen würde ich hier Cherry Picken, hätte aber auch kein Problem mit dem Komplett-FW.

Ich kann hier aus eigener Erfahrung sagen, dass dieses Vorgehen sehr gut funktioniert. Dadurch, dass ALLES in SF2 mit Namespaces versehen ist, lässt sich perfekt modular genau das heraussuchen, was man braucht.

Die Komponenten sind für sich voll funktionsfähig - was SF2 selbst macht, ist wie du schon sagst alles unter einen großen Hut bringen und eben alles so zusammenstellen, dass man eigenständige Projekte damit erstellen kann.

Gerade die Komponenten, die das MVC aufbauen und alles rund um die HTTPFoundation ist extrem nützlich, auch ohne SF2 drum herum.

Durch das "Kompilieren" der Config und Templates ist auch die Performance quasi auf Vanilla-PHP-Niveau...


PS: Egal welches Framework benutzt wird, bitte löscht endlich alle alten Artefakte, die auf TYPOlight hinweise (tl_files, tl_-Präfix in Datenbanken, etc)... ansonsten werden wir immer nur der "kleine Bruder" sein.

[christian.kolb]

Du hast natürlich Recht, Symfony stand nie zur Auswahl. Falls es zur Auswahl hinzugezogen werden würde, wäre ich auf jeden Fall für Symfony.
@leo: Was spricht eigentlich gegen Symfony?

Ansonsten klar für Yii. Das Zend Framework ist zwar mächtig, aber auch einfach der totale Overkill. 30MB allein für's Framework sind einfach zu viel, vorallem wenn man nur einen Bruchteil davon nutzt.

Gruß
Christian

[backbone]

Aktuell ist das Zend Framework oder Yii Framework. Ich glaube das Leo Feyer die Auswahl aus folgendem Grund festgelegt hat. Wenn man die beiden Möglichkeiten BSP mit SF2 vergleicht fallen doch deutliche Unterschiede auf. Wenn man sich anschaut, was den Contao Stil an nähsten kommt, dann ist das Zend. Von den verfügbaren Klassen und der Art der Verwendung. SF2 hat da zum Teil doch deutlich andere Ansätze. (Achtung, ich sagte anders, nicht schlechter)

Deswegen hab ich die Alternative für Option c) mit externen "Basis"-Frameworks zu verwenden eingebracht. Und da sich schon so viele gegen ZF ausgesprochen haben, bleibt effektiv nur b) oder c), wenn leo das Grundlegende nicht schon für sich entschieden hat (die Befürchtung hab ich leider).

Du hast natürlich Recht, Symfony stand nie zur Auswahl. Falls es zur Auswahl hinzugezogen werden würde, wäre ich auf jeden Fall für Symfony.
@leo: Was spricht eigentlich gegen Symfony?

Die Hoffnung stirbt zuletzt...

[BugBuster]

Also wenn ich zwischen Yii und ZF (ZF2) wählen muss, dann klar für Zend.
Und was die Größe angeht, andere Probleme habt ihr nicht? Das wird doch nicht alles mit einem Mal included...
Ich war damals mit der 1.0.x sehr erstaunt, das meine recht einfache MVC basierte InventarDB die ich damals damit bastelte weitaus schneller lief als meine eigene Entwicklung zuvor, obwohl ZF ca. 10 mal mehr Dateien verwendete.

Füher konnte man noch zwischen "mit" und "ohne" Dojo wählen, dann wurde das schon mal kleiner.

Interessant wirds, wann denn nun endlich die Version 2 von ZF kommt. Bisher gibt es ja "nur" ein drittes Developer Release wenn ich das grad richtig gelesen habe.

Und Zend Framework mit Zend Server und Zend Studio, da kommt Freude auf.

[christian.kolb]

Sorry, hab mich undeutlich ausgedrückt, mit Overkill meine ich das System an sich. Ich habe bereits damit gearbeitet und bin der Meinung das es (für Contao) zu Komplex ist. Nicht für Hauptberufliche PHP Entwickler, sondern für die Entwickler die mal hier und dort ein Feld hinzufügen möchten oder eine kleine Erweiterung schreiben möchten, für die Leute durch die Contao groß geworden ist. Im Moment ist der Einstieg in die Erweiterungsentwicklung auch für nicht Profis leicht, klar steigt die Komplexität mit einem Framework eh, aber ich lehne mich sicher nicht weit aus dem Fenster wenn ich sage, dass das Zend Framework wohl zu einer der komplexeren gehört. Und wenn wir da an die Zielgruppe denken die nicht nur programmiert, dann scheidet das meiner Meinung nach einfach aus.

Gruß
Christian

[BugBuster]

Aber schau die mal an was da mit kommt. Für Contao sicherlich zu viel, aber einige Erweiterungen kannst dir schenken, weil es das Framework schon mitbringt. Das hat doch auch was.

[xunum]

Deswegen hab ich die Alternative für Option c) mit externen "Basis"-Frameworks zu verwenden eingebracht. Und da sich schon so viele gegen ZF ausgesprochen haben, bleibt effektiv nur b) oder c), wenn leo das Grundlegende nicht schon für sich entschieden hat (die Befürchtung hab ich leider)...

= a/b + c (a oder b und c)

Ein Basis-Framework nimmt einem vieles ab. Entsprechend kann man es dann aber auch abspecken, wenn man einen großen Teil selbst implementiert. Wobei ich diesen großen Teil sogar klein halten würde. Für mich bildet sich Contao weniger aus der verwendeten Basis, als aus dem Workflow zum erstellen eines Layouts und zum erstellen des Contents. Prinzipiell könnte es auch alles in Python neugebastelt werden und würde einen großen der Benutzer nicht stören.
Das dies nicht auf Plugin-Entwickler zutrifft ist klar. Aber gerade die werden sich über sauber umgesetztes MVC freuen. Der Einsatz eines großen bekannten Frameworks ruft außerdem eine ganze Reihe fähiger Entwickler auf den Plan, die bisher den Aufwand sich in Contao einzuarbeiten gescheut haben.

[christian.kolb]

Aber schau die mal an was da mit kommt. Für Contao sicherlich zu viel, aber einige Erweiterungen kannst dir schenken, weil es das Framework schon mitbringt. Das hat doch auch was.

Sorry aber das ist doch kein Argument. Es ist ja schön wenn wir uns ein paar Erweiterungen schenken können, aber wenn dann viele keine Lust mehr haben selbst welche zu schreiben weil es zu kompliziert ist und die "Nicht-Programmierer" keine Möglichkeit haben mal schnell ein Feld einzufügen ohne sich in das Zend Framework einzuarbeiten dann Gute Nacht. Wie xtra schon angemerkt hat, wir hießen mal TYPOlight.

@xunum: Ich kann mir nicht vorstellen das es fähige Zend Entwickler gibt die Angst vor der Contao API haben.

Gruß
Christian

[BugBuster]

Also mit der Einstellung brauchen wir dann auch keine PHP5.3 Features.
Ich denke ihr wollt in größere Riegen mitspielen? Dann braucht es auch ein größeres im Sinne von "kann mehr" Framework.

Und wer mit ZF schon mal gearbeitet hat weiß, dass Änderungen da wesendlich einfacher sind als jetzt.
Eine Umstellung wird es für alle, keine Fragem, egal welches Framework. ZF ist, nach etwas steilem Einstieg, eigendlich ganz gut lernbar.
ZF2 soll da ja, so das Ziel, einfacher werden.

[xunum]

@xunum: Ich kann mir nicht vorstellen das es fähige Zend Entwickler gibt die Angst vor der Contao API haben.

Du hast mich falsch verstanden. Es hat nichts mit Angst zu tun, sondern mit einer Abwägung des Aufwandes. Schreibe ich ein Plugin, dann wähle ich das Framework mit dem ich am meisten vertraut bin. Suche ich nach einem CMS, werde ich auch eines wählen dessen Basis ich gut kenne. Da entscheidet nicht die Angst, sondern die Überlegung dem Kunden 2 Stunden Aufwand für Programmierung oder für Einarbeitung und zusätzliche Programmierung in Rechnung zu stellen. Schnöder Mammon also.

[backbone]

Du hast mich falsch verstanden. Es hat nichts mit Angst zu tun, sondern mit einer Abwägung des Aufwandes. Schreibe ich ein Plugin, dann wähle ich das Framework mit dem ich am meisten vertraut bin. Suche ich nach einem CMS, werde ich auch eines wählen dessen Basis ich gut kenne. Da entscheidet nicht die Angst, sondern die Überlegung dem Kunden 2 Stunden Aufwand für Programmierung oder für Einarbeitung und zusätzliche Programmierung in Rechnung zu stellen. Schnöder Mammon also.

Du hattest aber nun mal gesagt "Angst" und nicht "Vermeidung von Mehraufwand" :P aber das ist ja jetzt geklärt...

@leo.unglaub:
Ob SF oder ZF einfacher ist kommt auf den Betrachtungswinkel an. Ich kann mich mit SF sehr viel schneller zurechtfinden, da es einiges ähnlich wie J2EE macht.
Weiterhin fand ich die Anwendung des ZF in Magento schlecht. Weiß jetzt nicht ob es an den Zend Leuten liegt oder an den Magento Typen...

Aber um nochmal (abgesehen von komplex oder einfach) auf die Performancegeschichte zurück zu kommen:
Toflar hatte da ein Link gepostet, wo das ZF min. 60fach hinter SF zurück lag... keine Ahnung, ich hätte ja jetzt bei 2-5fach noch "ok" gesagt, aber 60 fach? Das bekommt man mit keiner Abspechung, selbst wenn man den Test da zum ungunsten von ZF auslegt...

Und ganz ehrlich, leo will (wir wollen?) ja anscheinend noch dieses Jahr mit entwickeln anfangen, da können wir auch nicht auf ein ZF2 warten...

[Flex]

Magento ist leider kein besonders schönes Exemplar einer ZF Applikation, so bekannt es auch ist...

[xunum]

Du hattest aber nun mal gesagt "Angst" und nicht "Vermeidung von Mehraufwand" :P aber das ist ja jetzt geklärt...

Genaugenommen hab ich geschrieben:

Der Einsatz eines großen bekannten Frameworks ruft außerdem eine ganze Reihe fähiger Entwickler auf den Plan, die bisher den Aufwand sich in Contao einzuarbeiten gescheut haben.

"Angst" ist doch eine sehr interpretative Auslegung.

Aber um nochmal (abgesehen von komplex oder einfach) auf die Performancegeschichte zurück zu kommen:
Toflar hatte da ein Link gepostet, wo das ZF min. 60fach hinter SF zurück lag... keine Ahnung, ich hätte ja jetzt bei 2-5fach noch "ok" gesagt, aber 60 fach? Das bekommt man mit keiner Abspechung, selbst wenn man den Test da zum ungunsten von ZF auslegt...

Und ganz ehrlich, leo will (wir wollen?) ja anscheinend noch dieses Jahr mit entwickeln anfangen, da können wir auch nicht auf ein ZF2 warten...

Auch das ist nicht korrekt. Laut Link ist SF2 3,5 bis 3 mal schneller als ZF. Bisschen Scrollen vorm Posten erspart viele Missverständnisse!

[xunum]

Super kein Bearbeiten Button.

Solche Performance Tests muss man relativ sehen. Je nach Einsatz und "Kur" stimmen die Zahlen da schon gar nicht mehr. Das ist keineswegs eine Referenz

[backbone]

"Angst" ist doch eine sehr interpretative Auslegung.

Ich nehme alles zurück und behaupte das Gegenteil Nicht richtig nachgelesen :/

Solche Statistiken sind bei einstelligen Multiplikatoren jetzt nicht SOO bedeutend, aber wenns dann schon in die mittleren bis hohen zweistelligen geht (was bei ZF ja nicht der Fall ist) sollte man schon vorsichtig sein.

[BugBuster]

ZF2 soll 2-3 mal schneller werden als ZF1, ich habe damals nichts davon gemerkt das ZF1 langsam wäre.
Das dritte Entwickler Release läßt hoffen, dass ZF2 noch dieses Jahr kommt, es sollte ja schon soweit sein.
Leo hat ja kein Termin gesetzt, oder doch?, aber vor dem Camp wird doch sicherlich noch nicht entschieden werden.

[BugBuster]

Yeah! Das ist auch so ein Feature was ich gern hätte.
Ich habe zwar auch schon unter Contao eine Erweiterung damit im Test, aber ebend alles wieder selbst gebaut. (__autoload Umgehung usw.)

[ApoY2k]

Also UnitTesting kannst du mit jedem Framework machen... was bringt dir es denn für Vorteile, dafür einen Wrapper von ZF zu benutzen?

UnitTests sind vom Framework unabhängig - die müssen so oder so geschrieben werden, damit Continuous Integration funktioniert. (Symfony benutzt CI übrigens sehr intensiv für so ziemlich alle Komponenten, d.h. auch dort gibts Wrapper dafür)

[smung0r]

Hi,
ich bin auch fürs Zend Framework.
Ob es jetzt besonders schnell oder langsam ist kommt auch auf die Programmierung an. Wenn man Ajax Requests losschickt und den ganzen Frontcontroller durchläuft dauerts halt etwas länger als nen eigenes Miniscript. Aber ansonsten find ich das Framework total geil. Es ist Contao meiner Ansicht nauch sehr ähnlich und bringt einfach total viele Features mit.

Wenn ich nicht gerade denke das eine Webseite mit Contao programmiert werden kann nehme ich am liebsten ZF da dort schon so vieles fertig ist. Die Programmierung ähnelt sich ja sogar.

Und alle nicht benötigten Funktionalitäten kann man auch rauslassen. Dann ist das Paket auch nicht mehr 30 MB gross sondern nur noch 5MB. Ich glaube Piwik basiert auch auf Zend und das ist ziemlich klein.

Die Doku ist auch super.

[christian.kolb]

Sorry, aber jetzt muss ich echt bezweifeln, dass du dir den Code der beiden mal angeschaut hast. Denn das SF2 ist um NICHTS "simpler" als Zend. Das sind beides hoch komplexe Systeme von denen Sogar eher Zend leichter zu verwenden ist, da du eine Menge an Klassen direkt verwenden kannst.

Klar ist keines davon einfach, aber Symfony ist die modernere Variante. Natürlich kann ich nichts zu der Version 2 von Zend sagen. Um ehrlich zu sein ist es inzwischen wahrscheinlich schon 3 Jahre her seit dem ich mich mit Zend beschäftigt habe, mein Know-How von PHP war damals auch noch nicht das von heute.

Ich werde es mir mal nochmal genau anschauen. Bis dahin - ignoriert meine Beiträge erstmal

Gruß
Christian

[christian]

Weiterhin fand ich die Anwendung des ZF in Magento schlecht.

Leider war eben Magento mein erster Kontakt mir dem ZF - und war mir viel zu unübersichtlich. Reingeguckt, 'nen Tag lang damit gespielt und auf die lange Bank geschoben.

Genau daraus resultiert meine Befürchtung, dass sowas für Contao schlicht zu oversized ist und eher in in eine Richtung zeigt, in die Typo"light" früher halt gerade nicht wollte. Und ich eben auch nicht.

Klar ist, wenn es hier genügend Leute gibt, die für Ihre Projekte ein Framework brauchen, das deutlich weiter geht als das existierende, darf das nicht ignoriert werden. Sonst sind sie nämlich weg. Ich fände es allerdings genauso schade, wenn diejenigen weg wären, denen das Ganze dann zu kompliziert wird.

Für mich bildet sich Contao weniger aus der verwendeten Basis, als aus dem Workflow zum erstellen eines Layouts und zum erstellen des Contents. Prinzipiell könnte es auch alles in Python neugebastelt werden und würde einen großen der Benutzer nicht stören.

Das zum Beispiel würde ich nicht unterschreiben. Für die Agentur, deren Webworker mit den Contao-Bordmitteln ein Projekt baut und durch Redakteure oder den Kunden befüllen lässt, stimmt das ganz bestimmt. Diese Gruppe dürfte auch nicht eben klein sein, würde aber auch - ggf. mit Abstrichen - mit einem der vielen anderen CMS gut klarkommen.

Wenn es aber darum geht, kleinere bis mittlere Anpassungen machen zu müssen - nicht nur ein paar Templates durchmischen, sondern schon neue Felder, aus anderen Funktionen befüllte Optionen etc. -, dann sehe ich schon einen Riesen-Unterschied zwischen "jetzt muss ich mich erst mal in die XYZ-Logik einarbeiten" und "oh ja, kenne ich". Ich kann nicht abschätzen, wie groß die zweite Gruppe von Anwendern ist, aber ein Großteil meiner Aufträge sind solche Anpassungen für Agenturen und Freelancer. Von daher ist genau die bisherige Flexibilität gepaart mit einer kräftigen Portion "einfachem Code" für mich essentiell und exakt das, was Contao vom Rest bisher unterscheidet.

Und ja Toflar, dazu gehört auch, mal eben was im Template anpassen zu können - und zwar in allen Ausgabetemplates. Solange das gegeben ist, wäre es mit sonst ziemlich schnuppe, ob eine Template-Engine eingesetzt wird oder nicht.

Was soll ein Contao 3.0 zu einem Contao machen: Frontend und Backend, Workflow zur Seitengestaltung oder die Logik hinter dem ganzen?

Für mich, in durchaus wertender Reihenfolge:
- Backend
- fexible, einfache Erweiterbarkeit
- Frontend (im Sinne von stimmigen Einzeltemplates)
- Workflow zur Seitengestaltung
- Out-of-the-box Features
- viele gute Extensions
- tbc

Punkt 2 und 3 sind für mich die neuralgischen, wenn es um die Wahl des Frameworks dahinter geht. Womit die Logik leider auch dazu gehört. Ich persönlich brauche kein neues Framework, wenn aber andere eins brauchen, dann bitteschön ein genauso nutzerfreundliches.

Ich werde es mir mal nochmal genau anschauen. Bis dahin - ignoriert meine Beiträge erstmal

Lol - sowas ähnliches ist mir auch gerade durch den Kopf gegangen.

[tril]

Wenn man eine Erweiterung erstellt oder den Core ansieht ist es verständlich die Logiken zu trennen.
Aber NICHT wenn ich mal eben eine kleine Anpassung für den Kunden mache um das Datum anders zu formatieren. Oder einen zweiten Newsfeed im News-Template darzustellen oder oder oder ... Das sind individuelle Anpassungen die den Kunden glücklich machen und mir paar Minuten Zeit kosten. Anders wenn ich dafür jetzt ne halbe Erweiterung schaffen müsste.

Also in Smarty ist es überhaupt kein Problem auch komplexe Logik ohne die Verwendung eines externen Moduls zu schreiben. Dir stehen die wesentlichen PHP Funktionen und Kontrollstrukturen zur Verfügung und noch ein paar Smarty spezifische Funktionen. Ein großer Vorteil (einer Template Engine) ist vor allem, dass du dich nicht mehr um die Frage "Objekt oder Array?" kümmern musst. Diese Frage nervt mich am meisten, immer dieses ['xyz'] geschreibse.
Diesbezüglich brauchst du keine Angst haben, wenn es (von Contao Seiten) richtig gemacht ist, dann hast du überhaupt keine Einschränkungen in Bezug auf Zugriff auf Daten usw. Du kannst auch vorhandene Funktionen bequem aufrufen ohne Probleme. Und auch Daten umtransformieren, um sie dann anders auszugeben.
Und selbst wenn du mal gezwungen bist, die Funktionalität auszulagern, dann kann ich dir jetzt schon sagen, ist die Funktionalität sowieso so groß, das du es freiwillig in eine eigene PHP Datei auslagerst. Außerdem hat das noch einen Vorteil: Es ist wiederverwertbar!

Ich glaube wir sollten uns auf 2 Grundvarianten die auch tatsächlich gewollt werden, reduzieren und bis zum Camp jedes "Lager" etwas zum presentieren hat.

+1 wobei ich es nicht auf 2 Varianten beschränken würde, mich würde ein direkter Vergleich von Leo's-FW, Yii, SF2 und ZF schon interessieren.

Ich zum Beispiel, find Symfony auch toll, muss aber sagen, das es als Komplettframework vll zuviel des guten ist. Die Leute von Symfony schreiben selbst darüber soetwas wie: Das System besteht aus vielen unabhängigen Teilkomponenten (Twig, Doctrine, und auch einzelne Klassen(gruppen) die kein eigenes Projekt zur Verwaltung haben), die auch Einzeln eingesetzt werden können. Das Komplett Framework bringt aber Glue-Logic mit, die alles unter einen Hut bringt. (zum Beispiel die ganze Config-Methodik.) Deswegen würde ich hier Cherry Picken, hätte aber auch kein Problem mit dem Komplett-FW.

Vorschlag (lässt sich übrigens auch auf ZF übertragen):
Wir packen nur das, was der Core wirklich benötigt in den Core hinein. Der Rest des Frameworks lagern wir in Lib-Extensions aus, die nach Bedarf von den Erweiterungen als Abhängigkeit deklariert werden können. Das Prinzip wendet eigentlich jeder Distributor an. Und dann haben wir einen schmalen Core, der lediglich noch das nötigste beinhaltet und wir ergänzen das Framework nach bedarf?!

Hi,
ich bin auch fürs Zend Framework.
Ob es jetzt besonders schnell oder langsam ist kommt auch auf die Programmierung an. Wenn man Ajax Requests losschickt und den ganzen Frontcontroller durchläuft dauerts halt etwas länger als nen eigenes Miniscript. Aber ansonsten find ich das Framework total geil. Es ist Contao meiner Ansicht nauch sehr ähnlich und bringt einfach total viele Features mit.

Wenn ich nicht gerade denke das eine Webseite mit Contao programmiert werden kann nehme ich am liebsten ZF da dort schon so vieles fertig ist. Die Programmierung ähnelt sich ja sogar.

Und alle nicht benötigten Funktionalitäten kann man auch rauslassen. Dann ist das Paket auch nicht mehr 30 MB gross sondern nur noch 5MB. Ich glaube Piwik basiert auch auf Zend und das ist ziemlich klein.

Die Doku ist auch super.

Also ich habe weder Zend noch SF2 bisher benutzt, ich kenne beide nur aus der Doku und da bekommt SF2 definitiv das +1 für die Doku und Zend ein -1. Beide Dokus sind schon sehr gut, aber die Zend Doku ist für mich als "Einsteiger" unübersichtlich(er als die von SF2). Piwik ist übrigens etwas über 20MB groß, ich verstehe nicht, was daran "ziemlich klein" ist, das ist genau so groß wie Contao
Du darfst aber auch nicht vergessen, Piwik ist ziemlich speziell und das wollen wir bei Contao nicht. Wir wollen Flexibilität und um so höher die Flexibilität um so geringer ist die Möglichkeit der Optimierung. Und von dem was ich bisher gelesen habe, ist ZF1 da sehr schnell ein Ressourcenfresser. ZF2 soll ja deutlich besser sein und mehrfach schneller und Ressourcenschonender sein als ZF1. Und das habe ich jetzt nicht hier aus der Community, sondern aus den etlichen Fachartikeln die ich regelmäßig lese
Natürlich ist praktische Erfahrung durch keine Literatur zu ersetzen, aber allein wenn ich bedenke, dass ZF2 in den Startlöchern steht und ZF1 so alt ist, halte ich es für nicht zielführend jetzt auf einen "einfahrenden" Zug ZF1 aufzuspringen. Auch wenn das ZF1 sicher noch ein paar Jahre gepflegt wird, weil es einfach sehr viele benutzen, der Zug wird früher anhalten, als uns lieb ist. Dieses Problem haben wir bei ZF2 und SF2 nicht.

[ApoY2k]

Wir packen nur das, was der Core wirklich benötigt in den Core hinein. Der Rest des Frameworks lagern wir in Lib-Extensions aus, die nach Bedarf von den Erweiterungen als Abhängigkeit deklariert werden können. Das Prinzip wendet eigentlich jeder Distributor an. Und dann haben wir einen schmalen Core, der lediglich noch das nötigste beinhaltet und wir ergänzen das Framework nach bedarf?

Auf jeden Fall die sinnvollste Variante. Komponenten aus den Frameworks schnappen die man braucht und diese benutzen. Am besten alles mit hübshen 5.3.8 Namespaces und jeder modulliebende Programmierer ist glücklich.

Vor allem die ganzen Design Pattern, die sich über die letzten Jahre entwickelt haben, sollten unbedingt zu exzessivem Einsatz kommen: Dependency Injection, Servicebasierte Handler, Observer, DBAL & ORM usw.

Natürlich ist praktische Erfahrung durch keine Literatur zu ersetzen, aber allein wenn ich bedenke, dass ZF2 in den Startlöchern steht und ZF1 so alt ist, halte ich es für nicht zielführend jetzt auf einen "einfahrenden" Zug ZF1 aufzuspringen. Auch wenn das ZF1 sicher noch ein paar Jahre gepflegt wird, weil es einfach sehr viele benutzen, der Zug wird früher anhalten, als uns lieb ist. Dieses Problem haben wir bei ZF2 und SF2 nicht.

Wie weit steht denn ZF2 vom Release weg? Oder andersrum gefragt: Wann soll mit C3 begonnen werden?

[Psi]

Ich möchte nochmal auf den Aufwand und die damit verbundenen Sorgen zwischen eigenem FW und fertiger Lösung kommen.
Für mich als Entwickler ist die Einarbeitung in SF2 oder Zend oder Yii oder wwi bestimmt leichter als sich mit den ganzen Anpassungen an Contao-eigenem FW rumzuschlagen, denn hierfür gibt es nunmal Doku, Tuts, Screencasts usw. Eine Lernkurve wird es in jedem Fall geben, ansonsten fallen die Änderungen so gering aus, dass wir es uns gleich sparen können.

[xunum]

Wenn es aber darum geht, kleinere bis mittlere Anpassungen machen zu müssen - nicht nur ein paar Templates durchmischen, sondern schon neue Felder, aus anderen Funktionen befüllte Optionen etc. -, dann sehe ich schon einen Riesen-Unterschied zwischen "jetzt muss ich mich erst mal in die XYZ-Logik einarbeiten" und "oh ja, kenne ich". Ich kann nicht abschätzen, wie groß die zweite Gruppe von Anwendern ist, aber ein Großteil meiner Aufträge sind solche Anpassungen für Agenturen und Freelancer. Von daher ist genau die bisherige Flexibilität gepaart mit einer kräftigen Portion "einfachem Code" für mich essentiell und exakt das, was Contao vom Rest bisher unterscheidet.

Ich weiß von einigen Freelancern und auch Agenturen, die ebenfalls Contao einsetzen, dass eine ganze Reihe Programmierer beschäftigt werden um Teile von Contao anzupassen. Und das in einem Umfang, bei dem ich mir denke, dass die Wahl eines anderen CMS da deutlich besser wäre. Wenn man von der gelernten Sichtweise an Contao herangeht, dann ist Contao auch nicht umgedingt simpel. Man merkt einfach das es ein gewachsenes und kein geplantes Projekt ist - bevor man mich jetzt steinigt: Geplant soll heißen, man setzt sich zusammen, entwickelt das CMS und Implementiert es dann.

Die von ApoY2k erwähnten Designpattern gibt es nicht umsonst. Am Ende ermöglichen genau diese Pattern, dass jemand der Erfahrung hat sich in vielen Frameworks einfach zurecht findet. Das macht nicht nur die Einarbeitung sondern auch die Wartung leichter. Um dann den Aufwand ins Spiel zu bringen: Wenn man ein FW selbst baut, dann müsste man eben diese Pattern auch verfolgen, schließlich will man ja ein modernes Framework haben. Am Ende landet man bei einer ähnlichen Implementierung, wie die bereits vorhandenen Frameworks bereits anbieten, denn so übermäßig viele unterschiedliche Wege gibt es da nicht.

Die Frage ist aber immer noch, was soll Contao ausmachen. Nehme ich diese Liste von christian, dann kann man sich das überlegen fast sparen.

- Backend -> ist eine GUI die mit jedem Framework umgesetzt werden kann

- fexible, einfache Erweiterbarkeit <- wird durch ein umfangreiches Framework noch gesteigert, zu mal man durch die Wahl eingebundener Komponenten eine viel höhere Flexibilität erhält

- Frontend (im Sinne von stimmigen Einzeltemplates) <- Mächtige Templateengines gibt es viele, man könnte sogar viele so hinbiegen, die Contao Templates zu fressen

- Workflow zur Seitengestaltung <- der hängt nicht vom verwendeten Framework ab

Es lässt sich eigentlich auf die Frage reduzieren ob die Zahl der Mannstunden die man braucht um etwas eigenes Fertig zu implementieren kleiner ist, als die Mannstunden die man braucht ein Framework zu benutzen, bzw. ob das in einem Zusammenhang steht.

[christian]

... ist die Einarbeitung in SF2 oder Zend oder Yii oder wwi bestimmt leichter als sich mit den ganzen Anpassungen an Contao-eigenem FW rumzuschlagen, denn hierfür gibt es nunmal Doku, Tuts, Screencasts usw. Eine Lernkurve wird es in jedem Fall geben, ansonsten fallen die Änderungen so gering aus, dass wir es uns gleich sparen können.

Da muss ich Dir schweren Herzens allerdings auch recht geben. Dokus etc. sind hier bisher ein Schwachpunkt und würden es dann bei einer Weiterentwicklung der Eigenkreation wohl auch bleiben.

[christian]

Man merkt einfach das es ein gewachsenes und kein geplantes Projekt ist - bevor man mich jetzt steinigt: Geplant soll heißen, man setzt sich zusammen, entwickelt das CMS und Implementiert es dann.

Nö, nö - damit hast Du durchaus recht. Was im übrigen auch für viele der Erweiterungen im ER gilt.

- Backend -> ist eine GUI die mit jedem Framework umgesetzt werden kann

+1

- fexible, einfache Erweiterbarkeit <- wird durch ein umfangreiches Framework noch gesteigert, zu mal man durch die Wahl eingebundener Komponenten eine viel höhere Flexibilität erhält

Das kommt wahrscheinlich sehr auf das Framework und dessen Implementierung an. Magento-like wäre es ein fataler Rückschritt.

- Workflow zur Seitengestaltung <- der hängt nicht vom verwendeten Framework ab

+1 (und ist eh noch eine Baustelle bei Contao)

...ob die Zahl der Mannstunden die man braucht um etwas eigenes Fertig zu implementieren kleiner ist, als die Mannstunden die man braucht ein Framework zu benutzen...

... und welches Framework am bedien-/nutz-/durchschaubarsten ist. Und zwar nicht für die "lebende Leiterplatte", sondern für den gut qualifizierten (ggf. aber nicht studierten) Webworker.

[aaronl]

Ich arbeite zwar nicht Hauptberuflich mit Contao, habe aber schon ein paar Kundenspezifische Erweiterungen umgesetzt.

Entweder habe ich es überlesen, oder es wurde wirklich noch nicht explizit thematisiert.
Eine der feinen Dinge an Contao ist mMn die Möglichkeit das Verhalten bei Feldern (Regexp, mandatory, etc), vor allem jetzt im Backend, durch ein Überschreiben der DCAs zu verändern. Wenn man das System einmal durchschaut hat ist es wunderbar einfach so auf gewisse Anforderungen schnell zu reagieren.

Wie sieht es da bei den vorgeschlagenen Frameworks aus? Kann man das ähnlich einfach oder ist das dann doch eine Frage der implementation und nicht des Frameworks an sich?
Gleiches gilt auch für die Sprachen Arrays.

Prinzipiell bin ich für ein fertiges Framework, vor allem wenn es gute Doku gibt . Momentan muss man sich die ganzen Infos doch mühsam zusammensuchen, vor allem wenn man nur sehr unregelmäßig für Contao etwas Programmieren muss darf.

Aus mangel an Erfahrungen kann ich keine Präferenzen für ein Framework abliefern.

[Toflar]

Also, mal ehrlich, eigentlich wollen wir doch alle das gleiche, oder?
Es soll weitergehen mit Contao, aber wir wollen halt nicht die Einfachheit verlieren, die wir bis jetzt geniessen konnten und immer noch geniessen
Zudem hat sich jetzt eine Mehrheit der Entwickler gegen die Variante c) ausgesprochen, weil

• ...wir wissen nicht, was das in der Schublade ist
• ...wieso noch einmal das Rad neu erfinden?
• ...wir nicht die Ressourcen dazu haben, noch einmal ein Framework zu entwickeln

Aus dem Thread geht hervor, dass sich viele Entwickler wünschen, dass Leo Symfony2 auch noch evaluiert.
Leo, ich denke Du solltest wirklich mal deine Evaluationskriterien veröffentlichen

Ich denke wir müssten wirklich irgendwie Reviews sammeln, von Leuten die objektive Berichte geschrieben haben und mit den Frameworks gearbeitet haben.

[MacKP]

Ich misch mich auch noch mal ein:

Ich habe ja die Hoffnung, das viele Erweiterungen unnötig werden. Mir schwebt da sowas vor wie im Catalog. Einfach über eigene Definitionen Felder hinzufügen können und ausgeben lassen. Egal wo. Ob bei Mitgliedern, Events, Seiten oder was auch immer. Einen Grundstock der von Anfang an da ist und dann im Backend erweiterbar ohne etwas Programmieren zu müssen.
Dadurch würden dann schon mal hunderte Erweiterungen nicht mehr nötig sein (die dann eh nur ein oder zwei Felder ergänzt haben).
Das ganze dann auch noch weiter verarbeiten können wäre auch noch was... aber dafür kann es dann ja auch wieder Erweiterungen geben ;-)

Templating: php und sowas wie Twig nutzen können wäre mein Traum ^^ (hät ich für den catalog auch jetzt schon gerne *g*)

Größe vom Paket: Bin sicher, das man das über Erweiterungen machen kann mit einem kleinen Kern. Ansonsten find ich 20MB oder mehr überhaupt nicht schlimm. Das was wirklich alle Hoster haben ist Platz ;-)

Viele Grüße

[Psi]

Entweder habe ich es überlesen, oder es wurde wirklich noch nicht explizit thematisiert.
Eine der feinen Dinge an Contao ist mMn die Möglichkeit das Verhalten bei Feldern (Regexp, mandatory, etc), vor allem jetzt im Backend, durch ein Überschreiben der DCAs zu verändern. Wenn man das System einmal durchschaut hat ist es wunderbar einfach so auf gewisse Anforderungen schnell zu reagieren.

Wie sieht es da bei den vorgeschlagenen Frameworks aus? Kann man das ähnlich einfach oder ist das dann doch eine Frage der implementation und nicht des Frameworks an sich?
Gleiches gilt auch für die Sprachen Arrays.

Kein Framework hindert uns daran diese Möglichkeit wieder zu schaffen. Das DCA-Konzapt würde ich keinesfalls verwerfen nur eben im Sinne des eigensetzten FWs umsetzen. Ob es bei PHP-Arrays oder XML oder sonst was bleibt sei mal dahingestellt.

[xunum]

... und welches Framework am bedien-/nutz-/durchschaubarsten ist. Und zwar nicht für die "lebende Leiterplatte", sondern für den gut qualifizierten (ggf. aber nicht studierten) Webworker.

Naja es spricht ja nichts dagegen, dass ein Webworker in der Einarbeitung auch allgemeines dazu lernt. Als Beispiel sei mal das Dependency Injection genannt, da lernt man schon eine ganze Menge wenn man sich einfach nur anschaut wie das Pattern funktioniert. Und gerade wenn man Erfahrung mit PHP hat (die man als Webworker gesammelt haben sollte) und vor allen Dingen mit OOP in PHP dann kann man die dazugehörigen Informationen sehr gut verstehen. Dazu kommt dann, dass es bei den meisten Frameworks umfassende Doku gibt.
Im Gegensatz dazu hat man bei einer Contao spezifischen Lösung nur die Dokumentation und das Forum zur Hand. Im Zweifelsfall ist die Doku aber wieder unzureichend denn, sein wir mal ehrlich, wenn man unter Druck steht mit der Entwicklung bleibt am Ende die Doku auf der Strecke.

[tril]

Ich habe ja die Hoffnung, das viele Erweiterungen unnötig werden. Mir schwebt da sowas vor wie im Catalog. Einfach über eigene Definitionen Felder hinzufügen können und ausgeben lassen. Egal wo. Ob bei Mitgliedern, Events, Seiten oder was auch immer. Einen Grundstock der von Anfang an da ist und dann im Backend erweiterbar ohne etwas Programmieren zu müssen.

Dieser "Catalog"-Ansatz hat sich bereits in CakePHP bewehrt und soweit ich es der Doku entnehmen kann, ist er Teil des Yii Frameworks. Mit ZF und SF2 lässt sich das ebenfalls realisieren. Man wird zwar nicht auf Annotationebene (wie in Doctrine 2) die Elemente definieren können, aber mittels integriertem Editor bspw. in einer XML Datei, aus der man dann das Schema erstellen kann, was mit Doctrine super einfach geht und dazu auch noch DB Unabhängig! http://www.doctrine-project.org/docs...sentation.html
Dieses Prinzip findet sich übrigens auch in großen CMS wie OpenCMS wieder, da habe ich es das erste mal kennen gelernt und habe ein "loses" Model auch schon auf der DevCon propagiert.
Aber wir schweifen ab, wollte trotzdem mal was dazu gesagt haben