Bug #50788
closed
Fluid Content Object does not configure object manager
0%
Description
If some TS defines "register implementation" like:
config.tx_extbase {
objects {
# Register 'fx' as default namespace and allow if condition string comparison
TYPO3\CMS\Fluid\Core\Parser\TemplateParser {
className = Enet\FxLibrary\Core\Parser\TemplateParser
}
}
}
Then, this class "override" is not done if a Fluid template content object is rendered. The reason for this is, that usually extbase Bootstrap.php method "configureObjectManager" takes care of looping through "objects" framework definition and pushed registered implementations to the object manager. But this bootstrap is NOT done in fluid content object context.
Possible solution: probably "copy" the method "configureObjectManager" from extabse bootstrap to ext:frontend FluidTemplateContentObject?!
Updated by Christian Kuhn over 11 years ago
- Project changed from TYPO3 Core to 2559
Updated by Danilo Bürger about 11 years ago
You could just do the following in your extensions ext_localconf.php:
$container = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Extbase\\Object\\Container\\Container');
$container->registerImplementation('TYPO3\\CMS\\Fluid\\Core\\Parser\\TemplateParser', 'Enet\\FxLibrary\\Core\\Parser\\TemplateParser');
Updated by Alexander Opitz about 10 years ago
- Project changed from 2559 to TYPO3 Core
- Category set to Fluid
- TYPO3 Version set to 6.2
- PHP Version set to 5.3
- Is Regression set to No
Updated by Vitoandre D'Oria about 10 years ago
Danilo's workaround will influence all other extensions as well?!
What about the plugin.tx_my.objects feature?
Updated by Claus Due about 9 years ago
I'm not sure we want to solve this one by additional bootstrapping this way. Danilo's suggestions is the low-level method of doing this implementation registration and it works just fine. The other way to achieve the same would be to add ext_typoscript_setup.txt (but I don't recommend that; it's extremely inflexible) or use the addTypoScript() method from ext_localconf.php to make sure that this TS is loaded without consulting the DB.
Don't forget that there are numerous pitfalls with pageUid resolving in these "detached" contexts so low-level methods of adding the TS are naturally more compatible. A full bootstrapping is usually avoided intentionally and turning it into a full bootstrapping defeats the purpose of the detached context.
The other thing is... I really wouldn't override the template parser class. I would "do the hard thing" and register the namespace and make a custom ViewHelper for the condition stuff if needed. That would also work in your Fluid content object rendering regardless of context ;)
My advise is to close this one and stick within API.
Updated by Claus Due almost 9 years ago
- Status changed from New to Closed
@Christian I'll take a chance and close this one. Essentially, the argument is: FLUIDTEMPLATE is not an Extbase context - object implementations registration is an Extbase context feature.
A bit expanded: the argument can also be made that with standalone Fluid arriving, the view used in this particular object is even less of an Extbase context. It basically will run entirely off of Fluid's View that knows nothing about Extbase even existing (nor should it, nor should Fluid in general in the TYPO3 flavor, but that's another discussion for another time). Also: once standalone Fluid becomes our base we will automatically be getting a lot of new ways to replace these API classes of Fluid, per instance of Views. Among other things you can replace the template parser class that gets used. It would require some additional configuration (like for example passing an "implementations" array as part of the FLUIDTEMPLATE configuration array...) but it would do the trick and be quite a lot more flexible than triggering global Extbase implementations registering.
That being said I do think we need some way of affecting these implementations (on a per-extension/package level). Perhaps you will be inspired by https://github.com/FluidTYPO3/flux/pull/1038 and agree we should create a similar pattern for TYPO3 itself (only speaking of the "implementations" part of the linked pull request, but I would suggest wrapping it in a class that can be detected by convention and basing it on a manifest of sorts - not the "extra" section of composer.json but an actual TYPO3 package manifest). I would also consider adopting the CompatibilityRegistry - I'll be proposing that in a coming merge request. And after all that I would begin replacing as many current usages of ext_typoscript_setup.txt as possible with package implementations. IMHO it would be quite nice indeed to be able to declare a manifest of implementations you want to use and even define those in a "when TYPO3 version is at least X use my Y implementation" way.