Welches Framework als Grundlage für Contao 3?

[MacKP]

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

[Toflar]

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.

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.

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

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:

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

[dominik.zogg@gmail.com]

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.

[mgco3]

Weil Freitag ist… (Danke lindesbs )

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.

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

ist im Prinzp nichts anderes als

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

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

[backbone]

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

[backbone]

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

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

ist im Prinzp nichts anderes als

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

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.

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)

[mgco3]

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:

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

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.

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:

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)

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.

[leo]

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

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

[backbone]

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.

[Toflar]

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?

[psren]

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.

[Toflar]

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

[tril]

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

[christian]

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

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

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.

[Toflar]

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?

[leo]

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.

[backbone]

@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

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.

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.

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.

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!

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.

[xtra]

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

[fesh]

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.

[backbone]

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:

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

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.

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

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

+ String behandlungs libraries

Eigenentwicklung + PHP Standard sinnvoll

+ Mail sending libraries

Swift mit Contao-spezifischen Helpern

+ Templating engine

Eigenentwicklung sinnvoll

+ Authentification&Authentication Framework.

Eigenentwicklung sinnvoll


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

[backbone]

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)

[grmllin]

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.

[lucina]

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.

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.

[grmllin]

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.

[backbone]

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.

[psren]

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.

[grmllin]

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.

[backbone]

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.

[tlnewbie]

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

[backbone]

Mal für einige die ähnliche Befürchtungen haben wie tlnewbie:
- Es wird sicher weiterhin DCAs geben, oder etwas ähnliches. Durch Verbesserungen in diesem Bereich, können auch Erweiterungen wie der catalog viel mehr Möglichkeiten bieten, die vorher nur mit "nativen" DCAs möglich waren. (Das wär vll jetzt auch schön möglich, aber der Aufwand sogut wie unvertretbar.)
- Es wird sicher weiterhin Module geben und noch besser, es werden vielleicht sogar ALLE Terminologien die sich im Backend finden (Seiten, Layouts, Themes, ...) als Klassen wieder finden, was den programmatischen Umgang mit dem System eigentlichen vereinfachen sollte.

Es wird sicher alles ein bisschen andere Namen tragen, woran man sich gewöhnen muss, aber es wird sicher nix aus Lust & Laune umbenannt, sodern um die Funktion mit dem Namen besser zu treffen.
Es geht hier hauptsächlich darum das der Core (nicht die Core-Contao-Distribution) in sich sehr abgeschlossen und "monolithisch" ist und dass man mit zahlreichen Hooks sich nur in das System einhängen kann, die bei mehreren Erweiterungen dann schnell zu gegenseitiger Inkompatibilität führt.

[christian]

weil ich mit Contao endlich das für mich optimale (= gut handlebare!) System gefunden hatte.
...
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.

Das ist genau der Punkt. Es geht sich für Leute wie mich nicht darum, an alten Strukturen zu kleben, oder Arbeit im Sinne von Umgewöhnung, Neu-Einlesen oder ähnlichem zu vermeiden. Es geht aber sehr wohl darum, das gesamte Handling - und ich meine ausdrücklich nicht die reine Bedienung - einfach, schnell und damit günstig(!) zu halten. Alles erschlagende Boliden und zu reinen "Akademiker-Feten" degenerierte Produkte gibt es satt und genug auf dem Markt.

... obwohl es doch für einen Großteil von Webprojekten mehr als ausreichend ist.

Exakt! Und genau deshalb sehe ich bisher keine Notwendigkeit, alles zu 100% umzukrempeln.



Drei Hoffnungen bleiben mir:
- nichts wird so heiss gegessen, wie es gekocht wird ...
- ggf. findet man ja einen genauso einfach handlebaren Weg wie bisher ...
- oder Leo hat als werdender Vater bald sowieso keine Zeit mehr für sowas

[tlnewbie]

Es geht hier hauptsächlich darum das der Core (nicht die Core-Contao-Distribution) in sich sehr abgeschlossen und "monolithisch" ist und dass man mit zahlreichen Hooks sich nur in das System einhängen kann, die bei mehreren Erweiterungen dann schnell zu gegenseitiger Inkompatibilität führt.

Hallo Backbone, das verstehe ich sogar und bin auch selbst schon an manche Grenzen gestoßen und kann daher gut nachvollziehen, dass das Bedürfnis da ist, das zu verändern & den aktuellen Möglichkeiten und Standards anzupassen.
Trotzdem 'war' (ist) das alte System ein in meinen Augen sehr performantes für viele Anwendungsbereiche überaus gut geeignetes System und es ist einfach schade, es komplett zu 'verwerfen'.
Vielleicht wäre es eine Überlegung wert, es als Fork unter anderem Namen weiterlaufen zu lassen? (Nur so eine nicht bis zum Ende gedachte Idee, schlagt mich bitte nicht ;-)) - nehme ich zurück, ist wohl eher kontraproduktiv & zuviel Aufwand.

Wäre aber schön, die Entscheidung zu erfahren, sobald sie gefallen ist.
Grüße.

[dominik.zogg@gmail.com]

Zur Templating Engine:

Ich habe früher oft mit Smarty gearbeitet (noch in der Version 2) und hatte meine Freude daran. Durch die Einarbeitung in Symfony 2 habe ich aktuell mit Twig zu tun und muss sagen, das vorallem die Blocks eien Funktionalität zur Verfügung stellt, welche sich mit PHP Templates meines Erachtens nicht professionell umsetzen lässt und eine richtige Bereicherung ist.

Egal ob man Templateengines mag, doch zwei Dinge finde ich sehr wichtig, Templateegnines erlernen sich schneller als PHP und beinhalten alles was ein reiner Umsetzer braucht, der nicht entwickelt und die Lesbarkeit ist Qualitätssicherung Meilen höher.

Vom Mehrwert der Qualitätsicherung, welcher sich zwingend ergibt (ja ich kann damit wirklich nicht auf die Datenbank zugreifen, wie es in Contao aktuell problemlos geht mit dem klassichen mysql Treiber .... und ja so ein mit Verlaub gesagt "Scheiss" musste ich schon lesen), ganz zu schweigen.

[backbone]

Ich hab in Symfony noch nicht reingeschaut, aber ich geh mal davon aus, das die die Templates durch ein XSLT oder ähnliches jagen und man im Prinzip neue Tags hat (wie bei ASP, JSP)? Bin ich in der Annahme richtig?

[Toflar]

http://twig.sensiolabs.org/

Kannst aber auch plain PHP nutzen. Aber BTT

[pinball]

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?

Erstens ist 2022 in zehn Jahren. Zweitens ist nicht alles (für Leute wenigstens meiner Generation, die seit 1985 PC's besitzen, schone einiges kommen und eben so schnell wieder verschwinden sahen) was Du am Puls der Zeit nennst, besser oder vernünftiger. Ich bin für die Variante c und kann do_while und auch Christian (der wird jetzt staunen) nur zustimmen.
Gruss pinball

[backbone]

Habt ihr das auch schon mal aus dieser Richtung gesehen:
Wenn Contao nicht für Entwickler attraktiv bleibt / attraktiver wird, dann werden einige der (guten) Entwickler vielleicht mittelfristig weniger Arbeit in die Extensionentwicklung legen bzw. sich langfristig anderweitig weiterentwickeln / umorientieren. Und Contao kann sicher noch nicht von sich behaupten, sich im professionellen Agenturgeschäft auf der breiten Masse durchgesetzt zu haben. (Belehrt mich eines besseren, aber ich sehe einen Großteil der Agenturen noch auf TYPO3 und Wordpress rumreiten, wenn es um OS CMS geht...)



Andere Sache: Twig sieht auch sehr gut aus und durch das precompiling auch sehr performant, wäre meiner Meinung nach, nachdem ich auch die (überschaubaren) Sourcen überblickt hatte, eine Option für ein Contao3.

[Toflar]

Erstens: Danke, Zählen hab ich auch mal gelernt Und was willst Du mir damit sagen?
Zweitens: Mensch, wie oft ist es jetzt erwähnt worden? c) bedeutet ebenfalls Umstellung des Frameworks. Also ich sag es gerne noch einmal: EGAL für welche Variante wir uns entscheiden, es gibt ein neues Framework Umstellung und Inkompatibilität der Erweiterungen sind also gegeben, darüber brauchen wir gar nicht zu diskutieren??

Ausserdem wird PHP 5.2 nicht mehr unterstützt, also MÜSSEN wir zu PHP 5.3 weiter gehen. Dann können wir uns doch auch gleich die neuen Features zu Nutze machen?

Ich versteh nicht, warum sich alle so gegen Änderungen aussprechen. Ist ja alles unter der Haube. Frontendmodule, Inhaltselemente...all das darf und soll sehr gerne bleiben

[andreas.schempp]

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

Ich bin GEGEN eine eine nicht-abwärtskompatible Modernisierung. Glaub(t) mir, ich hab sehr viel besseres bei Isotope zu tun als alles auf ein neues Framework umzuschreiben...

Ich schliesse mich do_while und christian an. Sanfte Überarbeitung, aber kein umkrempeln.