NextPDF-CodeIgniter: Boot und Discovery

Auf einen Blick

CodeIgniter 4 findet die Services-Klasse, die Helper-Funktionen und den Registrar des Pakets automatisch per Composer-Paket-Discovery. Diese Seite beschreibt die genaue Abfolge und die Konfiguration, die diesen Prozess steuert.

Wie die Services-Discovery von CodeIgniter funktioniert

CodeIgniter 4 löst einen Service auf, indem es jede gefundene Config\Services-Klasse nach einer statischen Methode durchsucht, deren Name zum angeforderten Service passt. Wenn Ihre Anwendung also service('pdf') aufruft, findet das Framework die erste gefundene Services-Klasse, die eine pdf-Methode deklariert, und ruft sie auf.

Die Discovery wird durch Config\Modules gesteuert:

• $enabled — der primäre Schalter für die Auto-Discovery. Standardeinstellung true.
• $discoverInComposer — erweitert die Discovery über Composer-Pakete hinweg. Standardeinstellung true. Dieses Flag ermöglicht es dem Framework, nextpdf/codeigniter zu finden.
• $composerPackages — ein optionaler only- / exclude-Filter für die Menge der Composer-Pakete.
• $aliases — die Elementtypen, die in die Discovery einbezogen werden. Der Framework-Standard umfasst services und registrars, die dieses Paket beide nutzt.

Die Paketklasse ist NextPDF\CodeIgniter\Config\Services. Composer bildet das PSR-4-Präfix NextPDF\CodeIgniter\ auf src/CodeIgniter/ ab. Ein voll qualifizierter Klassenname muss einen Namespace der obersten Ebene haben (PSR-4 §x1.x2.p5, modal MUST). Das Namespace-Präfix wird auf das Basisverzeichnis abgebildet, sodass die Klasse zu ihrer Datei aufgelöst wird (PSR-4 §x1.x3).

Boot-Sequenz

1. Composer-Autoload. Composer registriert die PSR-4-Map sowie die files-Autoload-Einträge. Die Helper-Datei src/CodeIgniter/Helpers/pdf_helper.php wird hier geladen.
2. Framework-Bootstrap. CodeIgniter liest Config\Modules ein. Wenn die Discovery aktiviert ist, baut es die Liste der gefundenen Elemente über alle Composer-Pakete hinweg auf.
3. Registrar-Discovery. Das Framework sammelt Registrar-Klassen. Die Methode Registrar::Autoload() des Pakets meldet den pdf-Helper beim Helper-Loader von CodeIgniter an.
4. Service-Auflösung beim ersten Aufruf. Service-Factories werden lazy ausgeführt. Der erste Aufruf von service('pdf') oder Services::pdf() führt die Factory aus. Gemeinsam genutzte Services werden für die Dauer des Prozesses im Locator zwischengespeichert.

Container-Bindings

CodeIgniter 4 hat keinen PSR-11-Container. Die „Bindings“ sind die statischen Factory-Methoden in der Services-Klasse. Jede Methode akzeptiert einen bool $getShared-Parameter:

Service	Standardmäßig gemeinsam genutzt	Anmerkungen
fontRegistry	ja	Vorgewärmt, dann gesperrt.
imageRegistry	ja	Begrenzter LRU-Cache.
documentFactory	ja	Zustandslos.
pdfDocument	nein	Neu pro Aufruf.
pdf	nein	Neu pro Aufruf.
tsaClient	ja	null, wenn keine TSA-URL vorhanden ist.
pdfSigner	nein	null, wenn die Signierung deaktiviert ist.

Die gemeinsam genutzten Instanzen verbleiben für die Dauer des Prozesses im Instanz-Cache von CodeIgniters BaseService. Das Test-Harness des Frameworks leert diesen Cache über BaseService::reset(), und die funktionalen Tests des Pakets setzen dieses Zurücksetzen zwischen den Testfällen voraus.

Reihenfolge der Konfigurationsauflösung

Die effektive Konfiguration wird in dieser Reihenfolge aufgelöst:

1. Paketstandardwerte in NextPDF\CodeIgniter\Config\NextPdf.
2. Eine Anwendungsklasse Config\NextPdf, die die Paketklasse erweitert, sofern vorhanden. CodeIgniter lädt sie anstelle des Paketstandards.
3. Umgebungs-Overrides, die von BaseConfig angewendet werden, mit dem kleingeschriebenen kurzen Klassennamen nextpdf als Schlüssel (punktgetrennte verschachtelte Schlüssel oder die voll qualifizierte Klassenform).

Die Config-Erweiterungsdatei der Anwendung deklariert eine Klasse und verursacht keine Seiteneffekte. Damit entspricht sie der PSR-1-Erwartung, dass eine Datei entweder Symbole deklariert oder Logik mit Seiteneffekten ausführt, aber nicht beides (PSR-1 §x1.x1.p3). Die Helper-Datei ist bewusst das Gegenstück mit Seiteneffekten. Sie deklariert die globalen Funktionen pdf() und pdf_document(), und jede davon ist durch eine function_exists-Prüfung abgesichert, sodass ein doppeltes Laden unbedenklich ist.

Diagnose

• composer dump-autoload — baut die PSR-4-Map und die files-Autoload-Liste nach einem Upgrade neu auf.
• Am schnellsten prüfen Sie die Discovery mit einem Controller, der Services::pdfDocument(false) aufruft und prüft, dass der Rückgabewert ein Document ist.
• Sehen Sie sich vendor/composer/autoload_files.php an, um zu bestätigen, dass die Helper-Datei registriert ist.
• Siehe /integrations/codeigniter/troubleshooting/ für die Zuordnung von Fehlern zu Ursachen.

Konformität

• Ein voll qualifizierter Klassenname erfordert einen Namespace der obersten Ebene (PSR-4 Autoloader §x1.x2.p5).
• Abbildung des Namespace-Präfixes auf den Klassenpfad im Basisverzeichnis (PSR-4 Autoloader §x1.x3).
• Eine Datei deklariert Symbole oder verursacht Seiteneffekte — das Design der Helper-Datei (PSR-1 Basic Coding Standard §x1.x1.p3).

Siehe auch

• /integrations/codeigniter/integration/ — Referenz zum Wiring und zum Smoke-Test.
• /integrations/codeigniter/install/ — Installation und Verifizierung der Discovery.
• /integrations/codeigniter/overview/ — die vollständige API-Oberfläche.
• /integrations/codeigniter/troubleshooting/ — Fehlermodi der Discovery.