Epic #103035
openHandle EXT syntax more flexible
0%
Description
Currently, TYPO3 comes with a logic to put all in an extension which can be referenced via "EXT:", this goes for language files, public assets, private templates, configuration files. PHP is usually done via autoloading, so this is not considered here anymore.
However, TYPO3 bases most of the logic on a few super-god methods:- GeneralUtility::getAbsFileName()
- PathUtility::getAbsoluteWebPath() in order to get the path to a public file
And then, it deals with public assets such as images in a bad way, when it comes to image processing.
This is bad architecture design and part of our legacy.
What we're lacking is:- A flexible way to reference the files, and read / write through them than to deal with absolute or relative paths to files
- A better way to deal with public assets from extensions in FAL, VHs, TypoScript
- A better way to reference translation labels instead of hard-coded paths (Resources/Private/Language) and template paths
In an ideal world, these paths can be overridden by the local project, instead of setting up a path repository, a site extension and replicate the base structure, just in order to change a template.
Ideally, the package manager allows to fetch files from packages by utilizing a PackageFileResolver, so e.g. paths inside the package do not matter anymore. Instead, they could be changed to whatever location ext authors like. We could introduce a typo3.json file, and finally get rid of ext_emconf.php. typo3.json could be optional, but contains the paths / locations to the files. Actually, in composer mode projects, the root project is already the "root" extension, but it would feel awkward to reference files like "EXT:root" right?
Files should be modelled a "PackageFile" object instead of a string, and can build a URI with "getUri($request): Uri" if they are allowed to be accessed from the outside.
Updated by David Bruchmann 7 months ago
I don't see a real benefit from a packageManager yet, as "Convention over Configuration" is quite useful and like you wrote also used in core and even composer packages or other external tools.
It's quite possible though that I'm missing the point and a good example would change my mind.
Updated by Benni Mack about 1 month ago
- Target version changed from 13.3 to Candidate for Major Version