[TYPO3-english] Conditioanl constants in setup conditions

[Stephan Schuler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hey there.


I just discovered something that costs me some CPU cycles. It’s related to having conditions in both, constants and setup that are tied closely.


Let me show a short example:

> Constants:
>>   [globalVar = GP:L = 0]
>>      config.language = en
>>   [globalVar = GP:L = 1]
>>      config.language = de
>>   [GLOBAL]
>>
> Setup:
>>   [LIT:{$config.language} = de|en$/]
>>      // Something that only is available for a configured set of languages, e.g. enabled solr cores.
>>   [GLOBAL]


I think my use case is valid. See the TypoScript reference, pretty much at the end of "globalVar" examples.
http://docs.typo3.org/typo3cms/TyposcriptReference/Conditions/Reference/Index.html#condition-globalvar

There it says:
> If the constant {$constant_to_turnSomethingOn} is "1" then this matches:
>> [globalVar = LIT:1 = {$constant_to_turnSomethingOn}]


The problem is rather complex, so I'm not going to explain what happened in detail. I will do that in a forge ticket if somebody else agrees to this being a bug.


I tried to make heavy use of this "config.language" thing through my latest setup, because I consider lots of condition like "[globalVar = GP:L=1]" inside of the backend TypoScript object browser pretty confusing.
That's ok for like two or three languages, but my latest projects turned out to have at least 20 different languages, some have even more.
Having "[LIT:{$config.language} = de]" right at the TypoScript object browser available is much clearer.


The effect being caused by this situation is:
* The very first rendering process of a certain page id makes up a cache value (inside of cf_cache_pagesection, as well as another one inside of cf_cache_hash).
* Second clicks on the same page id with the same language is very fast, since everything is cached nicely.
* Second clicks on the same page id with different language parameters cannot reuse one of those caches and trigger rerendering of TypoScript.
* Third clicks on the same page with the same language as the second click cannot reuse one of those caches, too.

Having a site with 20 languages results in
* Having a random one of those 20 languages being fast since it's the first click.
* Having the other 19 languages being slow because they need to rerendre TypoScript on every click.

This appears to me as a huge performance loss, which even down-scales linearly with the number of used languages.

The very same goes when using e.g. [PIDinRootline = {page.contact.form}]. But it's completely hidden and non-destructive there because those kind of conditions usually don't rely on other parameters than the page it itself, so the effect is never triggered. But in general it's a misconception in TypoScript caching, imho.


Currently the only way I see to work around this is not using "dynamic constants" in setup conditions. It all boils down to string compare operations failing.
Instead, I could introduce userFuncs (like "[userFunc = user_restrict_to_language(de)]") doing the exact same thing I do inside of those conditions currently. This would make the string compare operations work properly.


Any thoughts on this? Should I create a bug on forge?
I decided to start with an email here because I feel this should be discussed publicly, where forge and Gerrit tend to lead to hidden discussion in small circles.


So, any thoughts on this?
Well, I just thought about the sheet of paper my colleagues print out and pin right next to my desk every now and then, quoting "complexity kills". Did I just explain a situation nobody else ever encounters because of the complexity of its setup?


Kind regards,
Stephan.

Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Website: media.netlogix.de



- --
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Internet: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt




-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.3.0 (Build 9307)
Charset: utf-8

wpUDBQFSg5EBpp0IwsibV8MBCPQoA/kBgKJ3i5W5CWV5UmsTZ/lXFqnMpai0oPHJ
UHzGi44ZsENCTsGEAeOSw5MUXZjCDncv1q0In/dbNH4UPfwNvA4jiZgzC6sASM2i
+SogIwMjolS/hZSpEl15BwkVRdxOhnqsf8wV0eCgj7ekWfu7sp3Rxg5ONXGX9B4E
OpycDIFr9Q==
=cbpg
-----END PGP SIGNATURE-----