[TYPO3-mvc] Fluid: Fallback paths for templates

[Bastian Waidelich]

Claus Due wrote:

Hi Claus, thanks for your detailed feedback!


> 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.

With overlays like...

plugin.tx_news.view.overlays.foo.templateRootPath = 
EXT:foo/Resources/Private/Templates/

plugin.tx_news.view.overlays.bar.templateRootPath = 
EXT:bar/Resources/Private/Templates/

...it's not easy to tell what path is being looked up first (in this 
case it's EXT:bar/Resources/Private/Templates/ I guess) and the 
configuration might be spread around multiple extensions & TS templates.


Taking your example with the three dependent packages:
You're right, the last package/extension could override previous 
configurations (btw: that would also happen if two extensions use the 
same overlay index such as "foo"). That's how it works in CMS and Flow 
ever since.

In fact one could use dictionary notation rather than numeric indexes 
and it would be just the same:

plugin.tx_news.view.templateRootPaths.foo = 
EXT:foo/Resources/Private/Templates/

plugin.tx_news.view.templateRootPaths.bar = 
EXT:foo/Resources/Private/Templates/

Personally I'd prefer to create a "site extension" that is loaded last 
and *explicitly* overrules all configuration because it would be much 
easier to comprehend that way.


> # 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.

I think that is a misunderstanding!? There are no new naming conventions 
with our latest draft.
Apart from the "Views.yaml" introduction to Flow I consider the change 
less intrusive than the overlay configurations.

I just suggested to add a new setter for "templateRootPaths" (and 
layout/partial..). As I wrote, I think "templateRootPath" can stay as is 
so it would be completely backwards compatible. Example:

# tx_news
plugin.tx_news.view.templateRootPath = 
{$plugin.tx_news.view.templateRootPath}

# tx_news_extended_super_plus
	# adds a new "fallback"
plugin.tx_news.view.templateRootPaths {
	tx_news = {$plugin.tx_news.view.templateRootPath}
	tx_news_extended_super_plus = 
EXT:tx_news_extended_super_plus/Additional/Templates
}

# tx_mysiteorg

	# this would add a new overlay
plugin.tx_news.view.templateRootPaths.tx_mysiteorg = 
EXT:tx_mysiteorg/Overridden/Templates

	# ..and this would override everything above as before
plugin.tx_news.view.templateRootPath = EXT:tx_mysiteorg/Overridden/Templates


> ## Prevention: do not rename the API. Extend what can be configured but
> do not change the naming.

Agreed, I only want to *extend* it. Whether or not to *deprecate* the 
existing syntax I don't know (as I wrote) but I don't see a reason 
currently.


> # Problem 3: Flow sync

> While it is in academic theory the better choice to let Flow dictate CMS
> pragma [...]

 > Please, for once, let CMS - and integrator's desires in particular -
 > dictate a minor detail in Flow [...]

 > Flow just changing everything with no truly good
 > reasoning behind it (except aesthetics and academic concerns) [...]

 > Your core audience comes from v4 CMS
 > don't forget to make them happy.

I'm really surprised that you still feel like this after we invited you 
and other "CMS guys & girls" to an open discussion where all attendees 
agreed..
We are one TYPO3 and there is no such thing as dictatorship in my 
impression.


-- 
Bastian Waidelich
--
Core Developer Team

TYPO3 .... inspiring people to share!
Get involved: typo3.org