[TYPO3-core] Conditions for Extbase Backend Module TS-Configuration really needed?

[Philipp Gampe]

Hi Helmut,

Helmut Hummel wrote:

> My question basically is: Did anybody use TS conditions to configure
> Extbase BE-Modules dynamically? Do we desperately need something like
> this?

Yes, I used it once to dynamically change settings for a specific domain. 
You can also filter by IP addresses, etc. (see at the end for details).

> I'm not saying that it might not be useful for some edge case, but the
> cost for that is very high performance wise.

Well, every condition costs performance :D I think it is one of the strength 
of the TYPO3 CMS project, that you can always add little configuration to 
solve some strange/complex requirements without having to recode all the 
time.

----
Your answer from the change request
----

> Regarding PageTS, UserTS, BackendLayouts: this is a totally different
> story.

Not really. We have exactly the the same (performance/caching) problem too.

For page TS, you can even give on own rootline that might have nothing to do 
with the actual rootline of the page. Those kind of "features" make caching 
very hard. The simple solution here is to only cache the common case (normal 
rootline) and recalculate whenever a custom rootline is given.

The same is true for backend layouts. The first concept for the new backend 
layout data provider included a cache for them, but this cache head to be 
dropped, because the TS describing the grid might change depending on user, 
group, page id or moon phase.

OT: Reminds me, that we should put a generic put a generic moon phase 
condition in the abstract condition matcher.

Effectively the same problem appears in the frontend context. The parsed TS 
depends on conditions that need to be evaluated on runtime. Only the full 
output can be cached, but only if we cache it again for each possible 
condition.

> The major flaw we have, is that Extbase backend modules use
> frontend typoscript for their backend settings. we would need a good
> concept for either a new way configuring these modules or re-using
> PageTS or UserTS.

> We do not have that.

Well, the concept would be easy. Just use the backend API to read 
module.ext_name. key from TSconfig instead of parsing it from TSFE.

I do not know why this was never done, because the API is already pretty 
high-level and this would just need a few lines of code. But I never 
bothered to take a deep look into those dark extbase corner to figure out 
how much frontend extbase really needs for bootstrapping.

> But the real questions are: Do
> we really need dynamic configuration for Extbase modules? I mean do we
> reall want to support it? Is it worth the (quite big) performance
> overhead as we cannot properly cache it?

What is the difference between extbase and "normal" backend modules? You 
could ask the same question for normal modules. And I think that conditions 
are quite handy once a while.
The amazing flexibility of TYPO3 CMS comes partly from the possibilities to 
use conditions to change the configuration based on various parameters.

> Do we really want to simulate a
> frontend in the backend to properly support caching along with still
> working conditions?

I would prefer if we could drop the frontend simulation in extbase, but as 
far as I have heard, this is not so easy.

As said, most conditions are available in both backend and frontend and 
therefore live in AbstractConditionMatcher.

> or do we really want to recreate a new smart
> caching/ condition evalutation mechanism? 

Yes. I really think this is the way to go.

As said in the change, we need a high level API that we just feed with a 
context (frontend, backend, whatever), a page id and possibly a TS path 
(e.g. module.extbase.settings) to fetch the TS array for a given situation.

Caching and doing complex parsing logic inside the working classes is IMHO 
wrong from a conceptional point of view.
Extbase should have nothing to bother with the details of TypoScript, where 
it comes from, how it is parse and if it can cached.

It should just say: "TSservice: gimmy that key on this page" and get back an 
array.

Currently this full parsing, caching, etc logic is spread over several 
classes that should have nothing to do with TS, except of using some array 
values.

The list of conditions with most (or all) possible values is known at 
parsing time and can be used to do a clever caching. But the whole caching 
should be encapsulated inside a service class.
How we cache and if we cache at all should not be a concern of the classes 
making use of the TS values.

> My point is: No we do not
> want all that.

I really thing we do, see above.

> That frontend! conditions worked for Extbase backend
> modules is a (weird) side effect, not a feature.

As said, real frontend conditions might not really work. Those are:
* usergroup
* treeLevel
* PIDupinRootline
* PIDinRootline

Actually all conditions are available in backend too, but might react a bit 
different. Especially usergroup works on backend groups.
On top of that you have isAdmin in the backend conditions.

All other conditions (browser, version, system, device, useragent, language, 
ip, hostname, [time conditions], compatVersion, page, globalVar, 
globalString and userFunc) work the same way as in backend context.

As said above, I do really think that the possibility to react to the phase 
of the moon adds some real value to our product. IMHO this makes it 
"enterprise ready".

OT: If Dilbert would use TYPO3 CMS, he would most likely reconfigure the 
backend module to show a green light bulb overlapped with a chart chowing a 
positive exponential graph for the head department's IP-range and a fancy 
rule-the-work configuration for the admins.
(Yes, you can change the templates the same way like for frontend modules.)

p.s.: We can discuss this in Cologne tomorrow. I live nearby (Bonn) and 
could join for the evenings. I will not take part in the sprint through.
I can join after eight on Thursday or all day on Friday and the Weekend.
Just send me a mail or give me a call. 

Best regards
-- 
Philipp Gampe – PGP-Key 0AD96065 – TYPO3 UG Bonn/Köln
Documentation – Active contributor TYPO3 CMS
TYPO3 .... inspiring people to share!