[TYPO3-mvc] Fluid: Fallback paths for templates

[Claus Due]

Hi Helmut,

In an attempt to keep this brief:

> > Your solution:
> >
> > ```
> > plugin.tx_ext.view.templateRootPaths.foo = ...
> 
> > # which will be removed when setting...
> > plugin.tx_ext.view.templateRootPaths { ... }
> 
> Not true!
> ...
> No unexpected overriding here!

It wasn't clear, but I was trying to illustrate the behavior in Flow's Fluid by using CMS TS.

As I understand it, any Package which sets view paths in Flow will do so by overriding all
current paths, not by merging with existing configuration. Which is what I reacted to. We're
used to this configuration being done using a MERGE strategy and it would be quite sad
to see that option being discarded. You yourself say it's unique to TYPO3 so why should
it not also be useful for Flow/Neos to use such a strategy?

> From a OO standpoint, this is code smell as it introduces a direct 
> coupling to a very specific (configuration) component, which makes the 
> code harder to re-use in different contexts (standalone view, other 
> applications, Flow/ Neos).

It smells just as bad as the current formatToPageType mapping. We actually need these
things in CMS to make it friendlier to use - even if they smell bad to Flow/Neos.

> which is to extend the public API of Fluid Template View to not only 
> accept one root path for templates, but an array of templates, which can 
> be set through a new setter (setTemplateRootPaths), while making the old 
> setter call the new setter (read Bastians first post for more details). 

If I am reading this correctly, the result would exactly be as I predicted: setting first the
templateRootPath[s] then the templateRootPath results in the templateRootPath[s] being
ignored. Is this incorrect?

Once ported back to CMS, if this processing was done in a similar way: first applying path[s]
then the "old" path, would the result not here, too, be as I predicted?

Also: if the same name is re-used in TS, making this the pragma:

plugin.tx_ext.view.templateRootPath.tx_someother = ...

Then what happens when someone does:

plugin.tx_ext.view.templateRootPath = ...

> No backporting hell, no organisational problems, clean, easy, straight 
> forward, beautiful, no BC break.
> Can we also agree on this? Or am I missing something?

I am still not convinced. But there are more of you than of me.

> Secondly (and I very well might have missed something) I do not see how 
> the additional complexity in configuring something, adds more 
> flexibility for developers or integrators, in contrast to the 
> straightforward configuration mentioned above (and by Bastian).

One suggestion renames the location. Another changes the type.

Mine does neither.

> looks like a nice and powerful thing to have.

Thanks.

> On the other hand at the same time I do not like it for several reasons.

Okay then. It may not be right, but it is necessary. And here is where we will
always disagree, as far as I can tell. If something is necessary, whether or
not it is entirely academically correct is secondary to the benefit it brings.

If you have to choose between clean and useful what will you choose?

> I fail to understand, how the other way does not support that (as 
> mentioned above). (red: "that" being atomic configuration of path overlays)

This depends on how well I understood the Flow approach. It didn't look to me
to be supportive of atomic configuration?

> > , it might
> > mean that legacy support is broken because of a removed configuration loc.
> 
> Good point. This needs to be taken into consideration.

Thanks - I agree. Preemption is needed.

> Final words:
> I have a strong opinion on how this feature should be implemented on the 
> PHP level and have good arguments to support that (but I'm still looking 
> forward to be challenged on that).

And I have a strong opinion about how the configuration API should deal
with this. My focus is not on those people wanting to use Flow for writing web
applications. My focus is on CMS users who also should want to switch
some day.

> However, although I would prefer the simplest possibility to configure 
> the path overlay feature, I would agree to implement a more complicated 
> one even if it diverges from the way it is configured in Flow, but only 
> if we (Extbase Team, TYPO3 Core Team and Active Contributors) agree that 
> is a future proof, more flexible and thus better option for TYPO3 CMS

I would say it is. It could go into 6.2 with no further ado. The explanation how
to gain benefit from this new feature would be extremely simple. If this means
that the Flow solution is to be "less flexible" then so be it. Perhaps by the time
Neos finally shows up, there will then be more demand to "make Flow do what
CMS has done for so long" in that regard, too.

> Thanks for your patience and time reading through this long post :)
> Really! Thank you!

Same to you! Hopefully I've now argued that solution which looks cleaner is not
necessarily also the better solution. It also has to be taken into account how easy
it is to adopt and how much communication is required (and therefore how much
frustration would arise from people not reading it and other people having to
point it out repeatedly).

PS: I see Bastian already started the patch. And went completely in the opposite
direction; treating settings which should be considered fallbacks as overrides.
This is logical when you read the PHP side only. It's not logical when you consider
the practical application it has to fit into (one would need to remove the old path
and add it in the new set, etc. etc. with all the priority/order issues this brings). But
this might be one place where CMS could be allowed to diverge from Flow; CMS
being more TS than PHP/YML. One can hope :)

Cheers,
Claus