Fluid

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13824

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13823

I'd prefer to change the syntax to:

plugin.tx_cars {
  view {
    templateRootPaths {
      10 = fileadmin/Cars/
      20 = fileadmin/Car/
      30 = EXT:cars/Resources/Private/Templates/
    }

templateRootPath should be ignored completely if templateRootPaths is present.

Patch set 3 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13823

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13824

Hey,

thanks for your contribution!

See my comment over at the related issue http://forge.typo3.org/issues/39870#note-1

Furthermore, this change needs good test coverage; especially the Viewhelpertest needs to be extended to cover this functionality.

I personally am not so much in favor of this change, as it drastically adds complexity and makes debugging a lot more hard. It is a feature we deliberately left out of Fluid to reduce complexity. Still, I am open for discussion and if many people would like to have this change in, I won't block it for Extbase if it is properly tested by unit tests.

Greets, Sebastian

Wouldn't it makes sense to have this working transparently - without new configuration options? Say you configure a path pointing to fileadmin and if the template is not found there, the extension looks in its own Resources folder...

Sebastian, thanks for your review! Sorry but I don't agree that complexity is "drastically" bigger. And the flexibility it gives you is really great and needed. For pi-based plugins it was possible to change template path on file basis so current template handling in fluid is step backward for me in this regard.

I can understand that this might not be the most needed feature right now for FLOW3. For Extbase on the other hand where you are reusing existing extensions a lot and also build new ones on top of them, so being forced to copy all templates to new location makes extension update horrible.

What is also wort noticing people are implementing skins/fallback mechanism for templates in theirs extensions themselves. See YAG for example [1]

I can see several use cases for feature like this
- when adapting a template of some extension to your design (just copy few templates you need to modify)
- when building extension on top of existing one (like extension which adds new plugin to existing one)
- when you have website which several skins for different sections of website - you might have one "base" template and extending it skin (with just few modified files) for every section of website

Mechanism of skins woks very well e.g. in Magento - where you are copying just few files you wan to change to the new location. Of course you can copy all of them, but it is considered as bad practice.

@Ingo, it is also an idea, but it seems a half-way solution for me.

Btw I upladed new patch which uses different configuration - templateRootPath can be also an array now, so there is no new configuration setting introduced.
plugin.tx_cars {
view {
templateRootPath {
10 = fileadmin/Cars/
20 = fileadmin/Car/
30 = EXT:cars/Resources/Private/Templates/
}
}

Of course I will provide unit tests, and introduce the same fallback logic for partials and layouts, but I want to first get feedback about the idea and implementation itself.

[1] http://www.yag-gallery.de/features-documentation/tutorials/build-your-own-theme/change-templates/

Tymoteusz Motylewski wrote:

Sebastian, thanks for your review! Sorry but I don't agree that complexity is "drastically" bigger. And the flexibility it gives you is really great and needed. For pi-based plugins it was possible to change template path on file basis so current template handling in fluid is step backward for me in this regard.

I agree.

Btw I upladed new patch which uses different configuration - templateRootPath can be also an array now, so there is no new configuration setting introduced. plugin.tx_cars { view { templateRootPath { 10 = fileadmin/Cars/ 20 = fileadmin/Car/ 30 = EXT:cars/Resources/Private/Templates/ } }

Ok, looks already quite into the direction I proposed, not needing a new option. Is there a way to know the extension's default path for templates? Then this default path could be added to the list automatically.

The whole typoscript is a mixture of strings and arrays :) We can provide new configuration option which will be strictly an array, or allow existing templateRootPath to be an array. Both solutions are ok for me.

I would prefer to define only one (extension) fallback.

This solution will not be usefull in all usecases, e.g. when having base extension e.g. news, then additional extension which extends news, by adding additional plugin or field, and at the end we have templates which are specific for one installation/customer.
I would like to be able to fallback for templates first to my specific template for this installation, then to extension which extends news, and at the end to news.

Also having only one hardcoded fallback to original extension, will not allow us to have fallback in fluid page templates.
That's why I concider this approach a half solution/workaround.

The described configuration is nowhere used in TYPO3 yet especially not in pi_base.

This is a point of new features isn't it?

I've also thought about other implementation approach which will not require any change in fluid.
I mean, to set templateRootPath to view in ActionController, then call $view->canRender() (which will check if template exist) if it returns false, than try with fallback path.

This would be quite nice solution for templates, but unfortunatelly we can not use it for partials and layouts - as we can not determine what layouts and partials will be used during rendering, so the view has to know fallback paths himself.

Nicole Cordes wrote:

IMHO we shouldn't mix strings and arrays.

Why not, after all PHP is a dynamic language...

especially not in pi_base.

You do know we're talking Extbase here? ^^ SCNR

See also other implementation of Claus https://github.com/NamelessCoder/view

We could add it to fluid extension, because it will not be added to Flow Fluid package, see #39870.

seems that there is sth going on in this area in FLOW see http://forge.typo3.org/issues/39868 and https://review.typo3.org/#/c/16392/

Patch set 4 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/13823

Patch set 5 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/13823

Patch set 6 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/13823