Hallo zusammen.
Soweit ich informiert bin ist das in der Tat weggefallen, das zugehörige
Forge-Issue dürfte das hier sein:
https://forge.typo3.org/issues/73514
Ich finde das aber überhaupt nicht unglücklich gelöst in TYPO3.
Und nur zur Untermauerung dieser einen Aussage dient der nachfolgende Block.
Inhaltlich wurde bereits alles gesagt (.
Eine Datei einzubinden die direkt etwas tut will ja ohnehin niemand. Ein
„include“ oder „require“ lässt vielleicht eine Variable im globalen Kontext
zurück, vielleicht sogar eine Konstante oder eine Klasse, und wenn man an zwei
unterschiedlichen Stellen die gleiche Datei einbindet geht die Welt unter. Ein
„require_once“ dagegen wird nur einmal ausgeführt, auch wenn ich den
Code-Schnipsel vielleicht an mehreren Stellen haben will.
Dass der Weg also über ein „require_once“ gehen muss, das eine Klasse
registriert die dann wiederum mehrfach instanziiert werden kann, darüber sind
wir uns ja vermutlich einig. Das hast Du, Peter, ja auch gar nicht anders vor.
Wenn aber der Weg ohnehin eine Klasse ist, dann ist sinnvollste Integration
doch der Autoloader.
http://php.net/autoload
Composer nimmt einem das ab, weil er PSR-0 und PSR-4 unterstützt, und zur Not
noch eine Classmap. Dass Composer auch Einzeldateien unterstützt verscheige ich
hier einfach mal.
https://getcomposer.org/doc/04-schema.md#autoload
Das ist jetzt natürlich nur nochmal wiedergekaut was Helmut Hummel im bereits
von Dir, Alex, verlinkten Blogpost erzählt hat. Allerdings möchte ich
herausheben, dass es eben nicht ein Weg ist den TYPO3 hier entgegen der
sonstigen PHP-Welt einschlägt, sondern dass es nur ein kleines Bisschen TYPO3
um das ansonsten in der PHP-welt etablierte Standardverfahren ist.
Eine gänzlich von TYPO3 losgelöste Variante wäre natürlich, eine komplett
eigene Autload-Funktion zu schreiben die mittels spl_autoload_register()
registriert wird. Das kann ich auch ohne Extension, wenn ich will direkt in der
LocalConfiguration.php oder der AdditionalConfiguration.php.
Der aus meiner Sicht relevante Aspekt dabei ist, dass niemand der nicht ohnehin
Schreibrecht auf die PHP-Files oder composer.json hat neuen PHP-Code einbringen
kann (sprich: Das gilt natürlich nur für den Composer-Mode, nicht für den
Legacy-Mode). Mit der bisherigen Variante war es möglich, dass Administratoren
im Backend eine PHP-Datei in einen Storage gelegt haben, die via IncludeLibs
eingebunden und den zugehörigen PHP-Code dann ausgeführt. Das aktuelle Setup
sollte das unterbinden.
Ganz grundlegend ist es zum Teil auch eine Philosophiefrage. PHP-Code gehört
nicht in den Fileadmin (wo ihn ggf. entsprechend privilegierte Redakteure sehen
und bearbeiten können) sondern in ein Programmcodeverzeichnis. Und wenn er
schon da liegt darf das auch eine Extension sein, dann ist es wenigstens
einheitlich.
Beste Grüße,
Stephan Schuler
Web-Entwickler | netlogix Web Solutions
Telefon: +49 (911) 539909 - 0
E-Mail: stephan.schu...@netlogix.de
Web: websolutions.netlogix.de
Neu: Wir sind Amazon Web Services Partner. Mehr erfahren:
https://websolutions.netlogix.de/technologie/amazon-web-services-aws
netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: i...@netlogix.de | Web: http://www.netlogix.de
netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Matthias Schmidt
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
