[TYPO3-mvc] Fluid: Fallback paths for templates

[Claus Due]

Hi Bastian,

Thanks for the reply.

You write:

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

Yes, such is the nature of an atomic configuration as combined with the nature
of programming languages. Thankfully, "we's ain't stupid, y'all".

> and the configuration might be spread around multiple extensions & TS
> templates.

Yes. That is the whole point. It's the entire reason for this feature.

You're thinking of all this as "one site, one package contains full configuration"
when you should be seeing it as "one site, many packages contain config, one
package contains supplemental config, fill-in-gaps style".

You view the atomic nature of this configuration as a problem. I view it as a key
selling point. You think of how to debug sites easier, I think of how to make their
creation and modification easier. No surprise that we don't agree on this ;)

And worse: you've only argued this from a personal-taste standpoint...

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

My question is: why choose the solution which obviously encourages this
overwriting strategy and promotes this type of problem when there is another
choice that won't - but admittedly, is less pretty?

The only arguments I gather from your text are "it's prettier" and "it's more
predictable" but you don't seem to touch much upon the problems in not having
decided for/against deprecation and not considering the current configuration
convention _the base_ of the new one but _an alternative_ to the new one.

One might view such arguments as more weighty than deprecation concerns,
worries about this being a switch, not an addition and the loss of the very
flexibility this feature was intended to bring. I certainly don't.

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

This is, also, an example of personal preference and aesthetics. While I agree
with you in theory and aesthetics, practice is not this pretty and orderly! I like
your taste but Fluid isn't a matter of what we find aesthetically pleasing... is it?

> I think that is a misunderstanding!? There are no new naming conventions 
> with our latest draft.

I don't think it's a misunderstanding? You add new naming conventions for
when multiple paths must be registered. You even consider the old naming
an alternative, which only makes sense if this is in fact a changed convention.
The two patterns cannot coexist. The name of the setting is different. So is the
type. Help me understand this as anything but a changed convention?

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

But had you chosen my solution you would not need to consider deprecation.
You wouldn't need to worry about "is he using the new or old way?".

I'll sum this up as best I can.

Your solution:

```
plugin.tx_ext.view.templateRootPaths.foo = ...
# which will be removed when setting...

plugin.tx_ext.view.templateRootPaths { ... }
# which will now be ignored when someone sets...

plugin.tx_ext.view.templateRootPath = 
# which is the official and well-known way.
```

Your solution forces you to use one way or the other and disables one way
when the other is used. Which is fine if what you need to do is to at some
point remove the old convention. But you don't need to. So you should not.

My solution:

```
plugin.tx_ext.view.templateRootPath = ...
# would still be considered as the LAST path if adding...

plugin.tx_ext.view.overlays.foo.templateRootPath = ...
# would be tried first, only to be used if the file(s) exist there, if they
# dont', look for them in the original path which still has the same name.
# And when someone does this:

plugin.tx_ext.view.overlays {
    foo.templateRootPath = ..
    bar.layoutRootPath = ...
}
# the result is a merged configuration containing all paths defined by
# other extensions with only this limited set of path configurations overwritten.
# but you can also do things like this:
plugin.tx_ext.view.overlays {
    foo < plugin.tx_foo.view
    bar < plugin.tx_bar.view
}
# which of course attempts to build on the paths of "foo" and "bar" but don't take
# away the control over the paths - and is even pluggable regardless of how
# recent the configuration in "foo" and "bar" is (read: which pragma they use)
```

My suggestion allows integrators as well as extension developers to add
the extra templates they think should be present at any place they think it
should apply; and it respects (uses as last lookup location) the existing
conventional location. These are two ideal flexibility points for both integrator
and extension developer.

Your solution forces the integrator to choose between one or the other. It
encourages complete overrides of template paths and at some point, it might
mean that legacy support is broken because of a removed configuration loc.

My solution has a "problem" with predictability unless you know how to inspect
configurations, that's true. But this is no problem when you compare it to the
force, name change, one-or-the-other, deprecation risk done in your suggestion.

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

Look, Bastian. EXT:view is the result of communication with many integrators
and extension developers. I've nurtured it and taken support questions, asked
for suggestions and more. There are hundreds of users who use and enjoy this.
That's why I suggested you use that approach: I have done all the work for you!
It preserves the current API. People already know how to use it. But it is built in
and for a CMS world with atomic configuration as a feature, not as a problem.

Maybe what I'm actually confused about is the intention behind this change.
Because it's obviously not the same intention as the one behind EXT:view.

But let's not design by committee.

The real question is:

Which solution has less impact on the API, which solution has less deprecation
risk and which solution respects and use the current behavior as fallback?

..and is the one that can say yes to all counts not the better solution?


Kind regards,
Claus