Facebook
Twitter
Google+
Kommentare
10

Automatischer Autoload – der Weg bis zu PHPAB

Erinnert ihr euch eigentlich noch an die „__autoload()“ Funktion? Endlich konnte man diese doofen require statements weglassen ! Wenn man nur einen Autoloader für das ganze Projekt hatte… und auch keinen in Fremdcode mit __autoload benutzt hat… und der Mond richtig stand… irgendwie so war das früher.

Die meisten von uns leben zum Glück im schönen sonnigen Heute ( PHP 5.3 ), oder zumindest im trockenen Gestern ( PHP 5.2 ) und können sich an „spl_autoload_register()“ erfreuen.

Endlich war es möglich mehrere autoloader zu definieren und somit konnte es einem egal sein ob sie schon irgendeinem Fremdcode benutzt wird.

Damit ist also das größte Problem mit autoloading gelöst worden. Jetzt war es nur noch nötig von einem Klassennamen auf den Pfad zu der Datei, die die Klasse beinhaltet, schließen zu können. Zwei Ansätze habe ich häufiger gesehen:

Der Erste hat eine Namenskonvention definiert und alle Klassen hießen dann „Langer_Pfad_Zur_Klasse„. Macht nicht zwingend Spaß zu lesen und haben wir nicht genau dafür namespaces bekommen um das nicht mehr machen zu müssen? Nur ohne einen „voll qualifizierten Klassennamen“ muss ein anderer Weg gefunden werden wenn wir uns der require statements entledigen wollen.

Eine andere Option war es, eine „lookup“ Tabelle, wie z.B. ein einfaches Array, zu definieren in der jede Klasse und jedes Interface aufgelöst werden kann. Mit dieser Lösung muss man sich keinem starren Namensschema unterwerfen, aber ggf. eine Liste von Hand pflegen. Ohne hier werten zu wollen, ob das gut oder schlecht ist. Kein großes Problem, aber nervtötend.

Will man eine große, unstrukturierte legacy Anwendung mit tausenden Klassen von „require_once“ auf „__autoload“ umstellen, z.B. um unnötige require Aufrufe einzusparen, wird das eine sehr langweilige Aufgabe.

Um nach sieben Absätzen und der ‚Vorgeschichte‘ jetzt auf den Titel des Artikels zu kommen: phpab der „PHP Autoload Builder“ von Arne Blankerts macht uns das Leben mit Autoloadern einfacher. Über einen einfachen Kommandozeilenaufruf kann man sich eine fertige, anpassbare, php Datei erzeugen lassen die man nur noch in seinen bootstrap einbinden muss. Der Aufruf:

phpab -o src/autoload.inc.php src

scannt den kompletten „src“ Order nach Klassen und Interfaces und legt das Ergebnis am gewünschten Ort ab. In der Datei wird eine anonyme Funktion definiert und als Autoloader registiert. Wenn man PHP 5.2 kompatibel sein will kann man das mit dem -c switch erreichen. Das ist im Moment wohl nicht auf der Github-Seite dokumentiert, geht aber trotzdem ;).

Etwas lang geworden aber hoffentlich hilfreich. Zum Abschluss noch die Frage: Haltet ihr das für eine gute Idee ? Benutzt ihr Autoloader? Wenn nein, was spricht dagegen?

Über den Autor

Volker Dusch

Kommentare

10 Comments

  1. Guten Morgen!
    Ich steh total auf Autoloader für ’namegespacte‘ Klassen mit kurzen Namen. Für alles Neue, was ich schreibe, finde ich die register_autoload-Funktion ungeheuer hilfreich. Und alle alten Biblioteheken haben im Idealfall sowieso ihre eigenen autoload-includes mitgebracht, vgl. den typischen Satz aus einem Howto: “Usage: include ‚library-autoload.php‘ – that’s it”). Und wenn kein Autoload-Include dabei war, schrieb man sich eins. Das war früher nicht zuviel verlangt, und ist es heute auch nicht. – Ich finde, in Anlehnung an “Don’t fight the framework” soll man alten Code auch auf die alte Art einbinden. Dann weiß man schon beim Lesen, wo man noch alten Code rumfliegen hat. So einen Autoload-Builder halte ich daher eher für eine akademische Lösung, über die man sich ganz sicher in Spezialfällen freut.
    Viele Grüße, Carsten.

    Reply
  2. Mein Autoloader funkioniert ähnlich wie phpab, erstellt einen Index über das Projekt (oder definierte Ordner) und Cachet diesen in ein File (Pfade, Ordner und Cachetime können natürlich von aussen gesetzt oder als Config mitgegeben werden).
    Der Autoloader wird meist über einen Hook initialisiert und bei spl_autoload registriert. Ausserdem lassen sich Klassen (File muss gleich benannt sein) auch manuell laden. Sobald mehr Hoster auf 5.3 umgestiegen sind werd ich mich dann mal um den Namespace Support kümmern. Erzeugt sicher alles etwas Overhead, aber das ists wert.
    Fänds allerdings auch sinnvoll wenn einzelne Module selbst ihre Abhängigkeiten auflösen.

    Reply
  3. hi,

    ich mache es meistens über eine Klassenname-zu-Pfad-Tabelle, die aber automatisch vom Auto-Loader verwaltet wird. Wenn nach einer Klasse gefragt wird, die nicht in der Tabelle auftaucht oder sich nicht in dem dort angegebenen Pfad befindet sucht der Auto-Loader selbstständig im src-Verzeichnis nach der Klasse und ergänzt bzw. korrigiert die Tabelle sobald er sie gefunden hat. Ist lediglich eine einmalige Performance-Bremse wenn während der Entwicklung eine Klasse gesucht wird, danach rennt das System wieder als wäre nichts gewesen.

    So wird es auch vollkommen irrelevant wo eine Klasse liegt, ich kann sie sogar von einem Ordner in einen anderen verschieben und es arbeitet trotzdem alles problemlos weiter. Neue Klassen muss ich auch nur irgendwo im src-Verzeichnis ablegen und kann sie sofort benutzen.
    Sehr angenehm das ganze.

    MfG
    Addiks

    Reply
  4. Ich benutze ein klassenseitig verwaltetes Array mit einer statischen Zugriffsfunktion. Ein zentraler Autoloader greift dann darauf zu und wirft im Fehlerfall eine Exception.

    Dies bietet zwei Vorteile
    – die Autoloads können auch zur Laufzeit noch ergänzt werden, bspw. wenn ein Modul einer eigebundenen Seite weitere Objektkomponenten benötigt
    – die Autoload-Settings können sogar überschrieben werden (solange das Objekt noch nicht instanziiert wurde). In Ausnahmefällen kann dies sehr praktisch sein.

    Reply
  5. ich machs genauso wie addiks: der autoloader sucht sich selber die angeforderte klasse in den projektverzeichnissen und ergänzt sie notfalls in der conf, wo ein simples array die klasse auf einen pfad mappt… dadurch können meine klassen irgendwie heissen und irgendwo rumliegen…. sehr entspanntes arbeiten 🙂

    Reply
  6. Kann phpab nur empfehlen ist eine supper sache, arbeite seit neuem bei der Arbeit damit und finde es echt praktisch.

    Gruss Samuel

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen