Welches Framework als Grundlage für Contao 3?

[tril]

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.

Typisches Softwareprojekt Problem, es liegt aber in der Regel an der Planung.

Außerdem muss das daraus entstehende Contao ja nicht unbedingt schwieriger für Webworker zu verstehen sein. Das was die meisten Webworker an Arbeit leisten, wird vermutlich kaum "schwerer" sein, nur "anders".

[xunum]

Typisches Softwareprojekt Problem, es liegt aber in der Regel an der Planung.

Außerdem muss das daraus entstehende Contao ja nicht unbedingt schwieriger für Webworker zu verstehen sein. Das was die meisten Webworker an Arbeit leisten, wird vermutlich kaum "schwerer" sein, nur "anders".

Es macht aber einen unterschied, ob ich mich in ein Projekt einarbeiter, bei dem ich mit Programmierer-Allgemeinwissen das meiste verstehe oder bei dem ich erst durch die spezifische Lösung durchsteigen muss. Wenn Contao jetzt von einem Team von 200 Leuten gebaut wird, die entsprechend an alles Denken, Dokumentieren und auch die entsprechenden Lösungen Implementieren, würde ich da kein Problem sehen. Bei einem kleinen Team, dass quasi nebenbei so etwas entwickelt, mit ein oder zwei Hauptamtlichen (oder wie man das ausdrücken möchte), sehe ich die Gefahr, dass man eben sehr spezifischen Code erhält als deutlich höher gegeben an.

[christian.kolb]

Ich kann Toflar mal wieder nur zustimmen.

Es ist seit Themenstart so viel geschrieben worden, wir bräuchten mal wieder eine Meldung von leo.

Gruß
Christian

[backbone]

@christian:
Eben grade so meinte ich das, Magento war (bis gestern) auch mein erster Einblick in ZF und damals hat es mich einfach nur abgeschreckt, wie schlecht Magento zu erweitern war und das habe ich, da alle von "Magento basiert auf ZF" gesprochen haben, auf ZF zurückgeführt. Was anscheinend falsch war. Habs gestern nochmal überflogen und es ist doch schon nicht soo schlecht. Aber dann stehen immer noch die Geschichte Performance und Komplexität auf dem Programm.
Bsp: HTTP handling in ZF: Es gibt eine Request-Klasse die sowohl zum versenden von Requests als auch zur Representation von eingehenden Requests verwendet wird (ich hab zumindest keine 2 unterschiedlichen gefunden). Das ist vll sehr schön, da man theoretisch einen Request einfach "forwarden kann". Aber sonst bringt einem das nix, außer das die Bedienung in beiden Fällen gleich ist. (Wobei man ja bei den 2 Einsätzen egtl komplett unterschiedliche Methoden nimmt: Request bearbeiten -> lesen ; Request senden -> schreiben). Naja ist vll auch doch eher nen schlechtes Bsp. keine Ahnung. Aber mir persönlich gefällt der "Stil" von SF besser Zumindest einzelner Komponenten.



@all:
Optimalerweise sollten Forms aus beliebigen Konfigurationsquellen erstellt werden können, seis nun DCA, XML, DB (catalog) oder sonst woher. Ich hab übrigens im Entwickler-Interna einen Thread für eine Form-Lib eröffnet (schon vor diesem hier), da wird unter anderem Aufgezählt was ich mir von einem "High-End"-Form-Builder erwarte:
- Vollständig OO/Funktional und Modular
- API Driven
- DCAs oder andere Konfigurationsmethoden (XML, SQL Datensätze, JSON, ...) werden durch Factorys umgesetzt, somit kennt ein Form Objekt nichts von einem DCA oder sonstigem. Dies bietet die Möglichkeit Forms aus nahezu beliebigen Datenquellen zu konstruieren und verhindert das mühesame erstellen eines DCAs. Somit kann die Syntax von den Konfigurationsplänen eher geändert werden ohne Abwärtskompatibilität zu verlieren, indem man die Konfigurationssprache versioniert.
- Forms wissen nichts von Datensenken. Wohin eine Form gespeichert wird oder ob sie überhaupt gespeichert wird übernehmen Controller.
- Es gibt keine "ein Template pro Typ" Politik. Alle Form bezogenen Objekte haben kein Standard-Template. (Natürlich kann man Standard-Templates über die Factory festlegen.) Außerdem wird keine einzige Zeile HTML Code außerhalb der Templates verwendet!
- Übersetzung von Forms wird ebenfalls auf Factory-Ebene umgesetzt.
- Forms sollen serialisierbar sein (und somit cachebar).
- Datenlistings werden vollständig separiert von den Forms
- Neue Widgets mit modularen serverseitigen und, je nach Implementierung, !clientseitigen! Validatoren & Transformatoren (Theoretisch kann jeder Validator & Transformator über eine JS/PHP Bridge via AJAX clientseitig ausgeführt werden)
- FormValidators welche die komplette Formulareingabe validieren (wiederrum serverseitig und clientseitig)
- Paletten-Systen (bietet bisher keiner der Form-Generatoren die ich gesehen habe, hab in ZF aber noch nicht rein geschaut und bei SF nur die Doku etwas gelesen) ist Condition-basiert. Conditions können beliebig komplexe Auswertungen vornehmen.
- Verschiedene FormActions
- ALLE Ausgaben werden veränderbar, Forms representieren ausschließlich die clientseitig Funktionalität und die serverseitige Entgegennahme und Auswertung.

[Dani]

Ich habe das Gefühl, dass das Yii-Framework ein bisschen ausser Acht gelassen wird.

Ich habe mal ein Paar Links gesammelt (natürlich ein bisschen pro Yii):
http://stackoverflow.com/questions/6...mework-and-yii
http://www.phpframeworks.com/top-10-php-frameworks/

Ich denke, dass wir Yii besser mit Contao verbinden können als mit Zend, da es auch eher "light" ist.

[christian.kolb]

Wir sollten jetzt echt nicht mehr Typefreeze machen, oder noch besser, kann einer der Moderatoren das Thema sperren?

PS: @Dani: Zu deinem 2. Link. 121 Votes sind schon extrem aussagekräftig

Gruß
Christian

[xchs]

...oder noch besser, kann einer der Moderatoren das Thema sperren?

Wenn das mehrheitlich gewünscht wird, kann ich das gerne machen. Leo hat ja dann die Möglichkeit, den Thread ggf. selbst wieder weiterzuführen.

[ApoY2k]

http://www.phpframeworks.com/top-10-php-frameworks/

Mit den paar Votes, die da abgegeben wurde, kann man wohl kaum eine wirkliche Aussage treffen, die Gewicht hat. Mal abgesehen davon, dass dort von SF1 die Rede ist.

SF1 und SF2 sind grundlegend verschiedene Frameworks, die sogar nach Aussage der Entwickler selbst bis auf einige Konfigurationsprozesse und die Workflows nichts gemein haben.