Feature #63894
closed
Evaluate reference handling on TS parser level
0%
Description
Currently references in TS only work on Content Element level.
It should be evaluated if it possible to implement references on all levels. This involves changes to the TS parser.
The evaluation must not forget about a possible performance penalty.
Updated by Mathias Schreiber about 6 years ago
I don't understand the ticket description.
Can you provide a bit more detail?
Updated by Riccardo De Contardi about 6 years ago
- Related to Bug #80515: TypoScript references <= not working for PAGE objects added
Updated by Markus Klein about 6 years ago
References are only resolved for Content Objects, otherwise references are not resolved.
Updated by Markus Klein about 6 years ago
This ticket has its origin from #61275.
Updated by Christian Kuhn almost 2 years ago
- Related to Feature #97816: New TypoScript parser added
Updated by Christian Kuhn over 1 year ago
- Status changed from New to Rejected
Hey.
I looked into this with the new TS parser and had code in the main WIP patch to actually implement this on a parser level for a while.
The main problem is that this tends to increase the TS array / object tree a lot, (like more than ten times in size for the bootstrap_package). fluid_styled_content uses this feature by default. In effect, this eats away all performance improvements the new parser brings.
I thus decided to keep the existing strategy of resolving "=<" at a late point in FE rendering for just a couple of cases when really needed. There is a potential improvement to do that only once per match, this can be added later when COR starts using the object based tree. References are now "special" nodes in the object tree, so they can be easily tested for.
We should however improve the documentation for "=<" operator a bit to clarify this is not a language construct. I'll do that when the TS parser dust settles.
Updated by Helmut Hummel over 1 year ago
Hey Christian,
thanks for taking care for the TS Parser
Christian Kuhn wrote in #note-6:
The main problem is that this tends to increase the TS array / object tree a lot, (like more than ten times in size for the bootstrap_package). fluid_styled_content uses this feature by default. In effect, this eats away all performance improvements the new parser brings.
I have zero insights on the state of the parser, but I think this feature could be easily implemented after parsing, when the transformation to an array already happened (I've done exactly the same for my config handling package).
The parser could transform the value to a unique placeholder string that identifies the value as reference (e.g. "%conf(path.that.is.referenced)%", or just keep it like it is now: "<path.that.is.referenced", it is just less unique and could cause issues)
In a last step, the array could be recursively traversed to replace this placeholder with the referenced part of the array (this replacement must also be done recursively with a loop detection though)
Have you considered such approach?
Updated by Christian Kuhn over 1 year ago
hey. thanks for your response.
my implementation was based on this: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74285/72..73/typo3/sysext/core/Classes/TypoScript/AST/AstVisitorResolveReferences.php
a visitor called by a traverser that recursively walks the final ast. so similar to your suggestion, with the difference that i walk the object tree, not the array. i plan to change FE mid-term to work with the object tree directly and not with the array anymore, so doing this on the array doesn't help us with the transition.
i guess we could improve my first shot: When building AST, we could try to create 'source' and 'target' lists, and iterate the target list when main ast finished to safe the recursive tree traversal. so our implementation might improve, even if that strategy is rather complex.
this does not solve the 'usage' issue, though: fluid_styled_content comes with ~20 (?) content elements using TS tt_content.foo =< lib.contentElement, with bootstrap_package it's like 50. a typical page uses only a couple of these, for the rest an up-front search-and-resolve operation is waste of time. i assume kasper realized this back then and then went the 'late resolving when needed' path. guess i agree to that at the moment ;)