Bug #83735
closed
Remove @internal from ClassLoadingInformation
0%
Description
Hello there,
I'm kinda puzzled why this class is annotated for internal use. All other services from Install tool or Extensionmanagement like cache handling or installing are not annotated like that.
In our particular case we're generating some php models on the fly, which cannot be used until class loading information is dumped anew. Right now we decided to just ignore the warning coming from @internal. It seems odd anyway, as the method itself is actually scoped 'public'.
Another suggestion which'd solve our particular case would be adding a new signal parallel to 'afterExtensionInstall', which is called 'beforeExtensionInstall' and is triggered in InstallUtility::install right after enrichExtensionWithDetails was called.
Greetings,
Manuel
Updated by Helmut Hummel almost 7 years ago
- Status changed from New to Rejected
- Priority changed from Should have to -- undefined --
Thanks for reaching out. Although I will reject this bug report, I'll try to give some information about why.
I'm kinda puzzled why this class is annotated for internal use
This class is marked internal because it abstracts the way TYPO3 deals with class loading, when not being install with composer.
Right now we decided to just ignore the warning
Fine. Just be aware that it still isn't a good idea and any code / concept relying on this API being called will NOT work any more when TYPO3 is composer managed (installed with composer, aka composer mode).
In composer mode all class loading is delegated to composer and while calling this API will write some files, these files will never be included in the TYPO3 bootstrap.
It seems odd anyway, as the method itself is actually scoped 'public'
Nothing is odd about this fact. TYPO3 code needs to call it from several places. But third party extensions must not call it. End of story :)
Another suggestion which'd solve our particular case
I can't go into much detail here (I don't know why you did things and also not in detail how), but you should think about solving your use case differently.
I would start questioning that generating model classes is necessary.
If it still is, there are several possibilities to get things working without calling this code.
1. Register your own autoloader
2. Write the generated classes into an extension folder and register class loading for this folder in composer.json/ ext_emconf.php
If you need more support regarding this, feel free to ask on Stackoverflow and/ or in our community Slack channels.
Updated by SICOR KDL GmbH almost 7 years ago
Thanks for your in-depth reply, your answer is well respected.
Our extension generates Models, their TCA, ext_tables.sql and other files dynamically on the fly, as the user can design the data structure they need in the backend. Think mask/dce. Since we already can create those files, we thought to not ship them at all, but create them during the installation process just as well - albeit we figured late in the game that 'afterExtensionInstall' is fired too late.
So far for an explanation of what we're doing. We'll see if we're going the route you suggested now. Another option might be shipping dummy files for the install process. Only that would be totally redundant data we'd probably need to additonally take care of and update in the future.