[TYPO3-mvc] Fluid: Fallback paths for templates

[Claus Due]

Hi Bastian and others,

First of all, sorry I couldn't join the discussion.

I fear there are multiple aspects of the usages that fail to consider:

# Problem 1: Unintentional removal of paths due to lacking consistency in configuration strategy.

Package A is contains one template path set.

Package B extends Package A's set of templates. It uses a **targeted** override/overlay, e.g. plugin.myext.view.templateRootPaths.packageB

Package C extends Package A's set of templates. It uses a **broad** override/overlay, e.g. plugin.myext.view.templateRootPaths { packageA = ...; packageB = ... }

Package C loads after Package B.

## Conclusion: paths from Package B are removed in the suggested use case. Had you used the nested option I suggested, this would not have been an issue since it specifically encourages **targeted** overlays instead of encouraging Package C to use a **broad** override which prevents Package B's path from being taken into consideration.

## Prevention: encourage a configuration strategy which makes it sensible to only ever add overlays instead of one in which overriding the entire path set on the surface looks like the "most compact, recommended config". Using my suggestion of adding a nested grouping of paths completely solves this as it encourages unique keys and results in a merged configuration (which, by the way, can also easily be affected by an integrator).

Flow is all about promoting good conventions. Please don't promote a bad one.

# Problem 2: Legacy/new confusion

First of all I have to vote against using a new naming convention - it's not necessary. I might be missing an edge use case consideration here, but can you imagine any developer wanting to specify overlay paths for his View in any way that is not configuration based, e.g. for StandaloneViews...? I can't.

Assuming this, letting the View's API take array arguments is not necessary - it would need to know them in a TemplateView context but this would all be determined by the Request. This need only be internal, which means the entire API can be preserved.

## Conclusion: while the "change the current config" approach does result in a "simpler" version of the configuration, at the same time it is not "simpler" in that **it changes the current API** - and not only this, it **uses a name that is almost completely identical** making it hard to track down issues. Just an example, a recursive search for "templateRootPath" also yields all "correct" (as in: recent) configurations. A search for "overlay" would not.

## Prevention: do not rename the API. Extend what can be configured but do not change the naming. Rather, extend the configuration set that is delivered to the View. Two options; path of least resistance...

# Problem 3: Flow sync

While it is in academic theory the better choice to let Flow dictate CMS pragma, please don't forget to consider that the "overlay" approach is already proven, it requires no change in the existing configuration names and thus requires no communication that "from version X.Y you must now use FooBar instead". People already know it and use it and associate it with Fluid - so why this need to reinvent the concept?

Please, for once, let CMS - and integrator's desires in particular - dictate a minor detail in Flow. Why? Simply because it makes an insane amount of sense in a v4 CMS context and would only mean a minor adaptation in Flow in order to support exactly the same usage.

If sync is important, it should also be important that what is currently in use remains possible on Flow instead of completely redesigning it so that the configuration in Flow becomes more aesthetically pleasing. Your core audience comes from v4 CMS, don't forget to make them happy.


I don't know how much of this you will attribute to me "just being me" and bitching about once again, Flow just changing everything with no truly good reasoning behind it (except aesthetics and academic concerns) but hopefully you can see through this and look at the actual problems: in a nutshell you have two options here. One is to redesign the whole template path concept, forcing these changes also on the backport, the other is to extend it. It doesn't really take a genius to know which solution would be better for sync and adopting - all it takes is that once in a while you actually use v4 CMS and look at the options that make perfect sense there, then determine you want that in Flow as well. You may not have had such a configuration API in Flow before, but now you do - and this is the chance to make it match and preserve what currently exists and works.

So on behalf of integrators and extension developers everywhere: please use the "overlay" sub-path-collection strategy which I suggested and have implemented in EXT:view - and make the Flow configuration strategy also work that way, even if it does make the configuration files less pretty. You do not need to reinvent this, nor should you.

Kind regards,

Your friendly neighborhood coder,
Claus.