Die Klassen in Fuel
Fuel hat, wie die meisten Frameworks eine Vielzahl verschiedener Klassen zu bieten. Dabei geht das Ganze von Datenbankanbindungen über Arrays, Dateien, FTP, Sprachen, Strings, Pagination bis zu einer Klasse für MongoDB. Natürlich gibt es auch sicherheitsrelevante Klassen und Klassen für die Arbeit mit Datum und Formularen.
Fuel bietet somit eigentlich für jeden genügend Klassen, die man natürlich auch beliebig erweitern kann.
Sicherheit bei Fuel
Gegen Gefahren wie SQL-Injections, XSS oder CSRF ist man mit Fuel gewappnet. Standardmäßig werden alle Anforderungen an die Datenbank-Klasse nach schadhaften Code gefiltert. Außerdem besteht die Möglichkeit, auf simple Art und Weise einen Token-Key anzulegen um sich gegen CSRF zu schützen. Das Filtern von XSS übernimmt die Library HTMLawed.
Standardmäßig deaktiviert ist die Filterung aller Input-Felder, die keine Anfrage an die Datenbank stellen. Das lässt sich aber mit einer Zeile Code in einer zentralen Config-Datei aktivieren.
Das Framework Fuel erweitern
Fuel kann neben dem Anlegen eigener Klassen auch durch das Entwickeln von Modulen und Packages erweitert werden. Diese sind dann applikationsunabhängig und man kann sie somit in anderen Fuel-Projekten weiterverwenden.
Und dann gibt es da noch „Oil“: Mit Hilfe von Oil können per Shell-Befehle neue Packages installiert werden. Fuel gibt zum Beispiel mit dem AUTH-Package ein wenig Starthilfe und erstellt auf Wunsch automatisch ein Interface mit User-Login, das beliebig erweitert werden kann. Mit Hilfe von Oil können zum Beispiel auch neue Klassen, die man selber angelegt hat auf der Konsole getestet werden.
Fazit zu Fuel
Macht Fuel nun wirklich vieles besser? Auf jeden Fall macht es vieles gut und übersichtlich. Der Funktions- und Klassenumfang ist gut, aber nicht riesig. Das kann aber wiederum auch für Fuel sprechen, da es dadurch etwas schlanker ist. Fuel ist außerdem relativ fix installiert und bietet gute und bewährte Funktionen, die die Sicherheit gewährleisten. Ob Fuel aber nun tatsächlich den erhofften Leistungsschub bringt, bleibt abzuwarten, da sich das Framework noch nicht wirklich ausgebreitet hat und somit der Leistungstest in großen Projekten unter realen Bedingungen fehlt. Kritik gibt es unter anderem an der statischen Umsetzung mancher Klassen, die aber den Vorteil bieten, dass Fuel dadurch weniger Speicher nutzt.
Ich persönlich werde es mir einmal genauer ansehen und schauen, was Fuel mir in der Praxis bietet. Was denkt ihr? Ist Fuel eine Alternative und würdet ihr es gerne nutzen?
Links zum Thema
- Fuel PHP-Framework - fuelphp.com
- Fuel Dokumentation - fuelphp.com
16 Answers
von milkstyle 05.09.2011 (12:43Uhr) 1.
Beim Öffnen des Artikels schoß mir eigentlich nur ein "Mal wieder ein neues Framework" durch den Kopf. Die Ansätze sind bei den meisten Frameworks gut, zeigen aber unter realen Bedingungen dann doch ihre Schwächen.Bevor kein großes Projekt auf Basis von Fuel entwickelt wurde, dürfte die Akzeptanz noch auf sich warten lassen...
von Hotte 05.09.2011 (13:10Uhr) 2.
Hmm, ich finde den Artikel etwas "zu mau" formuliert. Selbstverständlich zeichnet sich ein Framework in erster Linie auch durch seinen Klassenumfang aus; hierbei sollte allerdings erwähnt werden, dass FUEL erst seit wenigen Monaten public ist, eine Erweiterung des Sortiments also fortwährend anläuft. Vielmehr hätte mich als Leser auch interessiert: Wer steckt hinter diesem Projekt, was ist seine Intention (Auflösung wäre nämlich dieser nette Herr, seines Zeichens ehemaliger Entwickler bei CodeIgniter), etc....
Zudem wäre ein Blick auf die Syntax mit Hilfe eines Code-Snippets interessant; an was soll ich denn sonst festmachen, was mich als Entwickler erwartet.
Bspw. will FUEL Vorteile anderer bewährter Frameworks nutzen und daraus einen individuellen Ansatz herleiten.
von tron 05.09.2011 (13:21Uhr) 3.
Also wenn ich mir die Fuel-Dokumentation zu REST anschaue, kommen mir so meine Zweifel, ob die irgendwas besser machen, was es nicht schon gibt. Die HTTP-Methoden POST & PUT werden nämlich falsch erklärt: http://fuelphp.com/docs/general/controllers/rest.html
von Emanuel 05.09.2011 (13:21Uhr) 4.
eine einschätzung zur dokumentation wäre auch gut gewesen. schließlich bringt mir das tollste framework nichts, wenn ich es dank unzureichender dokumentation nicht erlernen kann.
von Sven Schannak 05.09.2011 (13:28Uhr) 5.
@ Hotte
Na gut, ich hätte natürlich etwas über die Leute erwähnen können, doch den Meisten werden diese Namen leider nichts sagen und die Leistung eines Frameworks sollte auch nicht unbedingt im direkten Zusammenhang mit den Leuten dahinter stehen. Aber du hast recht, natürlich sagt das auch etwas über die Zukunft des Frameworks aus, bzw. die Zuverlässigkeit.
Zum Code-Snippet: Meinst du, man kann die Nutzbarkeit eines Frameworks auf ein Code-Snippet herunterbrechen ? Ist bestimmt möglich, aber bedenklich.
@Emanuel
So weit ich es richtig verstanden habe ist die Dokumentation noch in Arbeit, daher wollte ich noch nicht näher drauf eingehen, denn im Moment ist sie noch relativ bescheiden.
Sollte euch das Thema Fuel interessieren, würde ich gerne noch einen Artikel schreiben, der mehr die technischen Aspekte beleuchtet.
von Rob de Bert via facebook 05.09.2011 (13:31Uhr) 6.
Ist das nicht dasselbe was alle anderen Frameworks vorher auch schon als Ziel hatten? Also ich fahre mit CodeIgniter bisher am Besten.
von Torsten Deppe via facebook 05.09.2011 (13:34Uhr) 7.
Ist doch wenn ich mich nicht täusche wie kohana nen CI Fork ...
von Kevin Haferkamp via facebook 05.09.2011 (13:53Uhr) 8.
Sehe ich genauso, scheint ein CI Fork zu sein, nur dass man hier MVC strikt einhalten muss, was ja in CI nicht so ist. Also ich hatte da mehr erwartet, vor allem etwas, das an Modularität wie in Symfony erinnert. Oder den Umfang an Features wie Zend hat.
Die Idee, simple wie CodeIgniter zu sein, ist auf keinen Fall verkehrt, aber ich sehe den speziellen Anreiz nicht, ausgerechnet nun dieses Framework zu nehmen, wenn ich doch mit CI zufrieden bin :)
von René 05.09.2011 (14:34Uhr) 9.
Ich brauchte den Artikel nur überfliegen und beim ersten Screen der Welcomemessage und deren Strukturen dachte ich, hey, CI Fork XY … ist zwar schön, dass wenn man CI verstanden hat, gleich mit x anderen Frameworks arbeiten kann und so sein "Skill"-Portfolio erweitern kann ohne Gefahr zu laufen, groß falsch zu liegen aber was soll man groß damit anfangen, was CI nicht kann?
@Sven … mich würde, im Hinblick der technischen Aspekte schon interessieren, was Fuel besser als Kohana oder gerade das an vielen Ecken der Community bemängelte CI machen will. Also quasi die USPs nicht nur ggü. symfony (vorallem die 2er), Zend und Cake oder gar Flow.
von Christian Peters via facebook 05.09.2011 (15:28Uhr) 10.
Das einzige was mich vom Zend Framework wegbringen könnte ist Flow.
von Bodo Eichstädt 05.09.2011 (18:52Uhr) 11.
Danke für die Kommentare bzgl. CI Ursprung etc. Ich finde, das fehlt dem Artikel u.a. für das Prädikat gut recherchiert, Prädikat nützlich.
von Sebastian Diedrich via facebook 05.09.2011 (19:03Uhr) 12.
Bitte nicht noch ein Framework.
von Sven 06.09.2011 (10:16Uhr) 13.
Ich verfolge das Projekt seit einigen Monaten und bin beeindruckt wie viel Effektivität und Begeisterung das Team ein neues Framework aus dem Boden stampfen. Der Vorwurf es sei neben CI und Kohana nur ein weiterer Fork ist ein häufiger Vorwurf, den ich aber so nicht nachvollziehen kann. Die Entwickler argumentieren an diesem Punkt auch freundschaftlich und respektvoll gegenüber den anderen Frameworks (links siehe unten). Das fuelphp Team kommt eben von Kohana und vor allem CI und überlegt sich sehr genau wo die Stärken und Schwächen älterer Projekte liegen - Phil Sturgeon hat fuelphp maßgeblich mitgestaltet und ist bis heute aktives Mitglied und Contributor im CI Projekt.
Dieser Artikel ist leider sehr oberflächlich gehalten und drückt nur aus, was man in 60 Min googeln auch selbst herausfindet. Warum gibt es denn nun Fuel? Was macht fuel anders? Welche Ideen wurden von wo übernommen und wie ist die qualitative Umsetzung? Das Oil sich an Ruby's cmdline tool anlehnt wird nicht mal erwähnt. Dass Kohanas Cascading Filesystem anfangs 1:1 übernommen wurde, weil es einfach genial ist, ist ein Detail dass zeigt: Fuel will nicht das Rad neu erfinden, sondern tolle Ideen zusammenführen und steht z.B. mit Kohana Core Entwicklern in freundschaftlichem Austausch.
Lesenswerte Links:
http://fuelphp.com/blog/2011/05/why-did-you-do-that
In den Comments des folgenden Links gehen die Entwickler auf die auch hier genannten Kritikpunkte ein:
http://net.tutsplus.com/tutorials/php/getting-started-with-the-fuel-php-framework/
von manuw 06.09.2011 (13:49Uhr) 14.
Was macht es denn nun besser als alle andere? Finde CI recht praktisch für kleinere Projekte.
von Bastian 06.09.2011 (15:47Uhr) 15.
Hallo zusammen,
also zunächst einmal hat Dan Horrigan FuelPHP ins Leben gerufen und nicht Phil Sturgeon. Er kam erst später dazu - obgleich er viele wichtige Erfahrungen durch seine Erfahrungen bei EllisLab (CodeIgniter) eingebracht hat.
Und die wesentlichen Vorteile von Fuel sind eigentlich recht simpel:
- HVMC
- alle Vorteile von PHP 5.3
- extrem kleiner Footprint (mein Benchmark: 5x weniger Speicher-Allocation als CI)
- statische Methoden und Eigenschaften (keine Super-Objekt-Instanz $this mehr)
- extrem kompaktes und gutes ORM
- Namespaces
Ich kenne beide Frameworks (CI & FuelPHP) nun ziemlich gut und ich bin z.B. gerade dabei, ein bestehendes großes CI Projekt auf FuelPHP zu portieren. Mir gefällt die Verwendung der statischen Methoden und Eigenschaften sehr gut und außerdem die Vorteile, die man durch PHP 5.3 erhält.
Grüße,
Bastian
von Sven 07.09.2011 (00:36Uhr) 16.
Ich habe nicht behauptet, dass Sturgeon fuelphp gegründet hat. Was ich sagen möchte ist, dass Fuel ein kooperatives Projekt ist und eine sinnvolle und einander helfenden Koexistenz mit den anderen Frameworks eingeht. Darum für mich kein Projekt, dass die vielen Flames verdient hat.