Matti Mäkitalo: DOMDocument und PHP5

Beitrag lesen

Hi Felix,

Composer [...] generiert dir einen Autoloader.

Und was ist mit meinen eigenen Klassen?

Molily hat dir bereits einen Link gegeben zu PSR-0 bzw. dessen Nachfolger PSR-4. Lass dich von der Sprache nicht abschrecken, das Prinzip ist auch hier recht einfach.

PSR-0 (und PSR-4) gehen davon aus, dass es eine Übereinstimmung gibt zwischen Klassennamen (inkl. Namespace) und dem physischen Ort der Klasse. Wichtig: eine Klasse pro Datei.

Nehmen wir mal an, deine PHP-Dateien liegen alle unterhalb von src, einem gängigen Standard (davon ausgenommen natürlich dein Front-Controller, aber der wird ja auch nicht autoloaded).
Hast du bspw. eine Klasse Felix\DeinProjekt\MegaKlasse, dann sollte diese in der Datei src/Felix/DeinProjekt/MegaKlasse.php zu finden sein.

Solltest du keine Namespaces nutzen, sondern _ als Quasi-Namespaces nutzen (pre-5.3-style), dann kannst du das auch tun. Felix_DeinProjekt_MegaKlasse sollte dann ebenfalls am genannten Ort sein. Allerdings ist das nur PSR-0 - IMHO erlaubt PSR-4 diesen Stil nicht mehr. Im unten genannten Composer-Eintrag ist es mit PSR-0 aufgeführt.

Füge in die composer.json noch folgenden Eintrag ein:
"autoload": { "psr-0": { "": "src/" } }
Danach rufst du composer nochmal auf mit composer install (dadurch werden neue Packages installiert, falls du welche in require definiert hast, und der Autoloader wird neu geschrieben; wichtig: es werden keine Pakete aktualisiert).
Der Eintrag bewirkt, dass der Autoloader Klassen, deren Namespace mit "" beginnt, auch unterhalb von src sucht. Falls deine PHP-Dateien anderswo liegen, dann passt du das natürlich an.

Die vendor/autoload.php ist ja hoffentlich durch deine index.php eingebunden. Du kannst dann jederzeit auf jede beliebige Klasse zugreifen. Der Autoloader findet sie aufgrund der Konvention "Klassenname <-> physischer Ort der Datei" und bindet sie automatisch ein. Und das gilt eben auch für deinen Code. Das (entschuldige den Ausdruck) Geraffel mit dem Zusammenscannen des Projektbaums kannst du dir dann sparen.

Wie verhält es sich mit meinen eigenen Klassen, die ich als Helfer-Objekte definiert habe? Aktuell inkludiere ich die brav der Reihe nach. Eine Funktion filtert den Dateibaum nach "*.lib.php", um diese Dateien per "include" einzubinden. In jeder dieser "*.lib.php" wird jeweils eine Klasse definiert, die für sich alleine stehen kann. Untereinander gibt es keine Abhängigkeiten.

Das geht IMHO nicht mit PSR-0/4 zusammen. So flexibel ist PSR-0/4 nicht, dass dies erlaubt wäre - es ist auch gar nicht erwünscht, dass das geht. Man hat halt oben genannte Konvention festgelegt, und eigentlich halten sich die meisten halt daran. Vielleicht solltest du da auch irgendwann umsteigen?

Von __autoload habe ich schon gelesen... mehr aber auch nicht. Warum sollte das für mein Projekt sinnvoll sein? Ich habe eine Methode "load_libraries" in meiner Singleton-Klasse (index.php), die oben genanntes Vorgehen umsetzt. Sollte ich das durch einen composer ersetzen? Wieviele MB an Script-Dateien soll mein Projekt denn am Ende groß sein? Ich hatte in meiner naiven Einfalt etwas um die 5MB erwartet...

Die Nutzung von composer und einem Autoloader sind zwei verschiedene Dinge. Composer selber ist erstmal nur der Dependency/Package Manager und liefert einen Autoloader mit. Nutzen musst du diesen nicht.

__autoload solltest du dir wieder aus dem Kopf schlagen, das ist schon wieder veraltet. Das Problem mit __autoload war, dass man nur einen autoloader definieren durfte. Der Nachfolger ist spl_autoload_register. Das tolle ist nun, dass du mehrere definieren kannst - für Fremdbibliotheken den composer-Autoloader und zusätzlich deinen eigenen.

Willst du die Abhängigkeit irgendwann mal aktualisieren, dann tippe ein "composer update".

Und ich muss mir sicher sein, dass die jeweiligen Paket-Informationen des Composers einerseits topaktuell sind, die tatsächlichen PHP-Dateien aus den originalen Quellen bezieht und dass nebenbei keine Malware mit hineininjiziert wird...?

composer-update holt sich jeweils die aktuellen Versionen der Bibliotheken von packagist (oder einem anderen Paketserver - du kannst auch eigene definieren). Für das zweite gibt es keine fertige Lösung. IMHO gibt es noch keinen Signatur-Mechanismus auf packagist. Da hilft es dir nur, in die Quellen hineinzuschauen.

Für mein Hobby-Projekt vielleicht totaler Overkill, vielleicht aber auch "best practice" (falls mal jemand neues übernehmen muss) - ich werde mir das einfach einmal genauer anschauen.

Die Einstiegshürde ist recht niedrig. Einfach die composer.json anlegen, composer herunterladen und schon kannst du die einzelnen Komponenten nutzen. Und es beisst sich auch nichts, wenn du deinen Code anders strukturierst - du kannst halt nur den composer-autoloader nicht für deinen Nicht-PSR-0-Code nutzen.

Im Netz gibt es unzählige Blogeinträge zum Thema PSR-0/4 und composer. Schau dich da mal um. Die Erklärungen sind sicherlich besser, als jede, die ich beim ESC schauen auf der Couch abgeben könnte. :)

Bis die Tage,
Matti