Hi together,
I try to get more overview in Fusion / TypoScript. So I used variables in my scripts. Like in this Post ( Variable in TypoScript 2 )
Most of the time it works with ease. But when I try to define a variable outside of an fusion-path, within I loose the value and maybe the variable too.
#works:
//class has value of testNodeProperty within
prototype(Vendor.Site:TestNode) < prototype(TYPO3.Neos:Content) {
testVari = ${q(node).property('testNodeProperty')}
class = ${this.testVari}
}
```
#does NOT work:
// attributes.class has no value within
prototype(Vendor.Site:TestNode) < prototype(TYPO3.Neos:Content) {
testVari = ${q(node).property(‘testNodeProperty’)}
attributes {
class = ${this.testVari}
}
}
Simple Example: In real there are more calculations, if-then's, preg_replace ... With ${this.testVari} I would win more overview and simplicity.
***How could I use this.-syntax also in encapsulated (path-)situations?***
<small>Or should it work and there must be an error in my script?</small>
this is a reference to the current fusion context-object. In the second example it would address a property testVari inside attributes wich obviously is not there.
By using @context you are really adding a variable that can be used anywere in eel. This is the same mechanism that gives you access to node, documentNode and site . Be aware that this should be used with care since fusion is meant to be as side effect free as possible.
It is good practice to make a prototype rely only on node, documentNode and site in the context but inside your prototype you can do whatever you like with it.
To be honest, I used @context in some nodeTypes a lot.
[thought it is my own simple&dirty solution because of @christianm 's warning ( Typoscript2-Prototype with more then one ancestor? )
But I couldn’t find a solution with «simple property to prevent a huge amount of data into the context» -> thats the reason, why I left @context outside of this Topic.
With this Post I was looking for a solution to script without @context.
But I am glad about your advice!
I like to work with, because of more clarity, good readability, easy reusability and sometimes the heredity from a SuperPrototype to my Child-Prototype … (One more time, not the most proper solution – I guess).
Unfortunately:@context: is a big Question-mark
Maybe someone knows a good documentation or snippets about this topics: Basics of @context-concept, daily usage and deeper knowledge?
What is to do with, should do, or never should do with …
Could I have to clean the amount of data in @context with something like unset() or similar at the end of . Because of «long lifetime», «cache problem» or something else unknown?
Basically all fusion-pathes that are rendered isolated should only rely on the default context (site,documentNode,node).
Maybe an example helps:
You know that neos will rerender content-nodes after some specific inspector properties are changed. In that moment not the whole site is rendered but only the fusion for this single content-node. In that moment only the default context (site,documentNode,node) is available.
If you are running into trouble and have to enforce the rerendering of the whole page on property-change then you are probably doing it wrong and should try to optimize your fusion code.
The expression ${q(node).property('testNodeProperty')} works fine INSIDE of attributes as well, so that could be the way to go:
prototype(Vendor.Site:TestNode) < prototype(TYPO3.Neos:Content) {
attributes {
// Next line is important to not output testVari as attribute
@ignoreProperties = ['testVari']
testVari = ${q(node).property('testNodeProperty')}
class = ${this.testVari}
}
}
Now testVari is clearly scoped to attributes. If you need testVari as well in the prototype you can either repeat the expression or indeed use context. I this case it seems fine to do, I warn only about using it high up in the rendering structure as it will bubble down all the way. But if this prototype represents a content element usually that’s the end point anyway.
@christianm: New Possibilities with @ignoreProperties =[‘testVari’]. Will try with.
And right know, In my case prototypes represents most of the time a ContentElement. So good to know, if this is «the end point», @context is an acceptable opportunity.
It’s there for a reason, which is to solve this use case. My warning is a general one to help people not to “pollute” some up level context with a lot of variables that are then made available pretty much everywhere.