PHP Framework

[BoFiaZ]

Hallo,

ich möchte in Zukunft gerne intensiver mit einem PHP Framework arbeiten, dazu würde ich gerne wissen welche Frameworks Eure Favoriten sind.

Für mich über einen kurzen Erfahrungsbericht sehr freuen...
Danke für Eure Bemühungen...

[onemorenerd]

Mein Favorit ist zur Zeit das Zend Framework. Gut dokumentiert, sehr sauber aufgebaut, weitgehend ohne Zwänge, transparenter Entwicklungsprozess, kaum Systemvoraussetzungen u.v.m. Ich prophezeie ihm eine gesunde Zukunft.

ezComponents ist auch nicht schlecht. Man merkt zwar, dass es nicht auf dem Reißbrett geplant wurde sondern als Basis von ezPublish gewachsen ist und von Kundenbedürfnissen beeinflußt wurde. Aber dafür bietet es eben auch Funktionen, die dem ZF noch fehlen. Die Doku ist ebenfalls gut und wegen der längeren Geschichte gibt es mehr Literatur.

[combie]

Ja, das ZF dürfte das am weitesten fortgeschrittene und das universellste FW sein...

Aber: Wo viel Sonne, da auch viel Schatten!

weitgehend ohne Zwänge

1. Modrewrite steht nicht auf jedem System zur Verfühgung.
2. Nicht jedes System erlaubt include_path Änderungen

Und was ich am "scheußligsten" finde:
Der Autoload wird durch die bergeweise eingestreuten require adabsurdum geführt!

[netsnake]

Gibt es zum Zend Framework denn ein gutes Anfänger-Tutorial? Denn das 30-Minuten-QuickStart von Zend ist unter aller Sau...

[onemorenerd]

Original geschrieben von combie
1. Modrewrite steht nicht auf jedem System zur Verfühgung.
2. Nicht jedes System erlaubt include_path Änderungen

Und was ich am "scheußligsten" finde:
Der Autoload wird durch die bergeweise eingestreuten require adabsurdum geführt!

zu 1: ZF funktioniert auch ohne mod_rewrite. Der Router kommt auch mit URLs in der Form /index.php/module/controller/action klar und alle anderen Komponenten brauchen sowieso kein mod_rewrite. Andere Frameworks können übrigens auch keine 100%igen URLs, wenn der Server nicht mitspielt.
zu 2: Welches System? set_include_path() funktioniert doch immer!?

Autoload ist ein Gimmick für den Anwender. Was das Framework intern macht, kann dir völlig egal sein. Übrigens finde ich es richtig, dass sich das Framework nicht aufs eigene Autoloading verläßt - eine Abhängigkeit weniger.


http://framework.zend.com/manual/de/introduction.html
http://knowfree.net/2008/02/24/zend-...k-in-action.kf
http://www.zftutorials.com/

[combie]

eine Abhängigkeit weniger.

Nee..
Eine mehr.
Autoload und require ist wie gleichzeitig Fahrad und Auto fahren. Eins reicht doch.

set_include_path() funktioniert doch immer!?

Es gibt ja noch die verbotenen Funktionen.
Und http://bugs.php.net/bug.php?id=41561
Dann tuts der set_include_path() auch nicht.
(naja, wer hat schon noch kleiner 5.2.4)

[onemorenerd]

Man kann PHP - gerade über disabled_functions - total verkrüppeln. Aber wer macht das schon? Ich habe noch nie ein System gesehen, bei dem man den include_path nicht frei definieren konnte.

Den Vergleich Autoloading/require mit Auto/Fahrrad verstehe ich nicht. Sehe da keinerlei Parallelen. Kannst du das genauer erklären?

[combie]

Ich habe noch nie ein System gesehen, bei dem man den include_path nicht frei definieren konnte.

Ich schon!
1. wegen dem Bug
2. abgeschaltete ini_set()


Der alte Weg: (das schwergewichtige Auto)
1. Include_Path setzen
2. in jeder Klassendatei alle evtl. irgendwann mal benötigten Interfaces, Exceptions und Sonstigen Parentklassen per require_once "relativerpath"; laden

Die Vorteile des Autoload: (das leichte, im gedrängel flinke, Fahrrad)
1. es werden nur die wirklich benötigten Klassen geladen
2. Kein include_path nötig
3. keine vorbereiteten require(ausser der eine für den Autoload selber)

Das Fahrrad, kannst du ins Auto stecken, aber umgekehrt wirds sinnfrei.

Im ZFW:
Werden beide Wege benutzt. Die eingestreuten require_once zwingen, völlig unnötig, zum setzen des include_path. Es werden Klassen geladen, welche gar nicht gebraucht werden.

Der Schluß:
Entweder ist das ein historisch gewachsenes System, mit Altlasten am Bein, oder die Zendis haben es einfach nicht geschnallt. Mit einem Wort: Inkonsequent/halbgar. Meiner bescheidenen Meinung nach, sollte man sich auf einen der beiden Wege konzentrieren.

----------
Für den Fall, dass du meinst, ich hätte es nicht geschnallt:
http://combie.de/packages/
Da findest du Links zu modernen Paketen. Das einzige Paket welches diesen Zwitterweg benutzt, ist das ZFW.

Das soll jetzt keine Rede gegen das ZFW gewesen sein. Es legt nur den Finger auf eine Schwachstelle.

[Lennie]

wenn du neu einsteigst und dir das 30 minuten tutorial nicht ausreichend war, dann ist es empfehlenswert sich nochmal mit mvc im allgemeinen zu beschäftigen.

Die restliche Anwendung wird sich denke ich von selbst erklären, das du vor der framework nutzung einmal den weg über oop programmierung gegangen bist, sehe ich jetzt mal als selbstverständlich an.

[netsnake]

Nun ja, bei mir werden die Codebeispiele total versetzt angezeigt, das Prinzip verstehe ich sehr gut und das beste Tutorial zu diesem Thema ist ein Screencast, zu finden auf http://mitchellhashimoto.com/zend-framework-tutorials ich bin sehr begeistert davon, und er erklärt super, wie man alles zum laufen bringt.
Danke @onemorenerd

[onemorenerd]

@combie: Ich kann mich nur wiederholen. Autoloading ist ein Feature für den Programmierer. Er muss weniger Code tippen und sich keine Gedanken über die Verzeichnisstruktur des Frameworks machen.
ZF verläßt sich nicht auf das eigene Autoloading. Du kannst die Klasse Zend_Loader löschen und das ZF funktioniert trotzdem. Das ist doch eindeutig eine Abhängigkeit weniger. Sinnlos, aber wahr.

Autoloading ist nur ein Mechanismus in PHP, der greift, wenn eine Klasse nicht bekannt ist. Statt sofort einen Fehler zu werfen, wird der Autoloader gerufen und hinterher noch einmal geschaut, ob die Klasse nun vorhanden ist.
Also ist Autoloading nur die Reduktion der früher üblichen Folge von Inkludieren und Instanzieren. Das Inkludieren findet aber trotzdem statt, nämlich im Autoloader.
Das Autoloading klappt beim ZF nur, weil der Loader so passend zur Ordnerstruktur geschrieben ist, in der das ZF daher kommt. Bei deinem Paket ist es nicht anders. Wenn ich Ordner umbenenne oder verschiebe, scheitert dein Autoloader wie jeder andere auch.
Fazit: Autoloading funktioniert immer nur aufgrund irgendwelcher Konventionen.

Die Konvention beim ZF ist, dass alles im Ordner "Zend" liegt. Deshalb kann das Framework intern mit require_once "Zend/..." arbeiten. Ist gar kein Unterschied, solange der Ordner "Zend" im include_path ist.
Genau das selbe gilt doch für dein Paket. Wenn ich den Autoloader registriere, aber den Rest des Pakets außerhalb des include_path ablege, geht auch bei dir nichts mehr.

Der Vergleich mit Auto und Fahrrad hinkt übrigens sehr. Autoloading ist langsamer in der Ausführung. Aber im Autoloading steckt ein require. Das wäre ein Auto im Fahrrad ... vergessen wir das lieber.

Im ZFW:
Werden beide Wege benutzt. Die eingestreuten require_once zwingen, völlig unnötig, zum setzen des include_path.

AFAIK wird nur require benutzt. Autoloading ist für den Anwender gedacht, ZF selbst benutzt es nicht. (Jetzt wiederhole ich mich schon wieder, sorry.)
Wenn du den include_path nicht setzen kannst, musst du den Ordner "Zend" eben in den include_path verschieben oder chdir()'en. Das selbe gilt für dein Paket. Aber dieser Fall ist wirklich praxisfremd. Mag sein, dass es möglich ist, aber mir ist noch kein System unter gekommen, bei dem der include_path nicht veränderbar war.

Es werden Klassen geladen, welche gar nicht gebraucht werden.

Wirklich? Wo denn? Und könnte man es vermeiden? Dann weise doch bitte die Entwickler darauf hin. Ich bin sicher, dass es keine Absicht ist.

Der Schluß: ... Mit einem Wort: Inkonsequent/halbgar. Meiner bescheidenen Meinung nach, sollte man sich auf einen der beiden Wege konzentrieren.

Wird doch gemacht. Man "konzentriert" sich auf require. Punkt.
Außerdem stellt man einen Autoloader zu Verfügung. Wenn sich der Anwendungsentwickler also lieber auf den anderen Weg konzentrieren möchte, kann er das tun. Beides funktioniert problemlos zusammen, require innerhalb des ZF (wo alles in einem Ordner liegt) und Autoloading in der Anwendung (wenn sich der Entwickler an die Konventionen hält).

Das soll übrigens auch keine Rede pro ZF sein. Es hat auch seine Schwächen.

[combie]

Wirklich? Wo denn? Und könnte man es vermeiden?

Mit Autoload!

Pdf.php wird Zend/Memory.php geladen, obwohl nicht unbedingt benötigt.


Mail.php
Eine der require Kaskaden. Wobei einem da auffällt, dass sie von ihren sonstigen Prinzip abweichen.

z.B. in der loader.php kommt 10mal (ohne gezählt zu haben) require_once 'Zend/Exception.php'; vor. Das ist mindestens redundant aber sicherlich unschön.
Das findet sich vergleichbar an 1000 Ecken in der Klassensammlung so.

Die Abweichung:
Teilweise: (Mail.php)
Ettliche male:

  require_once 'Zend/Mail/Exception.php';
            throw new Zend_Mail_Exception('Return-Path Header set twice'); 

Aber in public function setDate($date = null) wird KEIN require vor der dem throw gesetzt.
Warum wird da abgewichen und damit der Autoload genutzt?

Auch findet sich in Mail.php ein doppeltes require_once 'Zend/Mail/Transport/Abstract.php';


In Memory.php wird dann die Exception in der require Kaskade geladen. Also wieder ein Abweichen vom Prinzip.
Und dieses sieht aus wie im Kindergarten: (factory Methode)

require_once str_replace('_', DIRECTORY_SEPARATOR, $backendClass) . '.php'; 

-----------
Weg 1: in einer require Kaskade alle evtl. benötigten Klassen laden
Weg 2: Ein require an dem Punkt, wo die Klasse benötigt wird
Weg 3: es dem autolader überlassen, den Kram ranzuschaffen

Und was machen die ZFWler?
Die mischen die drei Wege nach belieben, so dass kein System mehr zu erkennen ist.

----------
Nee....
Unausgegoren
teilweise fehlerhaft
redundant und damit fehlerträchtig

Die können sich selbst nicht an ihre eigenen Prinzipien halten.

-----------

Autoloading ist langsamer in der Ausführung.

In der absoluten Aussage, ist es schlicht falsch!
Die ganzen eingestreuten require fressen Parsezeit und Rechenzeit. Wie schnell require ist, hängt auch von der Anzahl Pfade im includepath ab.

[netsnake]

jetzt kloppen sich die pros... ^^ olé!

[combie]

Das ist noch lange kein kloppen!!
Evtl. Haarspaltereien, auch ein Kopf vor Kopf stehen, aber kein kloppen...
Das geht anders!

[netsnake]

Beispiel? Link? *lechz*