Bug #34844
closedview->setTemplatePathAndFilename bug
Added by Stefano Cecere over 12 years ago. Updated about 9 years ago.
0%
Description
i want to use another action template (let's say "List.html) for my Search action
inside searchAction() i call:
$this->view->setTemplatePathAndFilename(t3lib_extMgm::extPath('myxt') . 'Resources/Private/Templates/Mycontroller/List.html');
but it doesn't work well (keeps telling "The technical reason is: No template was found. View could not be resolved for action "search".")
the bug is: if the template file for an action Mycontroller/Action.html exists, then you can change it's template via $this->view->setTemplatePathAndFilename
otherwise it gives error!
i solved creating an empty action template for Search.html .. so i can redirect it to List.html :)
Updated by Felix Oertel over 12 years ago
- Target version changed from 1477 to Extbase 1.4
Updated by Alexander Schnitzler about 12 years ago
- Target version changed from Extbase 1.4 to Extbase 6.1
Updated by Anja Leichsenring almost 12 years ago
- Project changed from 534 to 2559
- Category changed from 962 to Fluid: View
- Target version deleted (
Extbase 6.1)
Updated by Dominic Garms over 11 years ago
Annoying bug but thanks for the report, for me with 6.0.4 the workaround with empty files worked!
Updated by Alexander Opitz about 10 years ago
- Status changed from New to Needs Feedback
Hi,
was this issue fixed or does it still exists?
Updated by Bernhard Schenkenfelder about 10 years ago
Just checked (TYPO3 6.2.4, extbase 6.2.0):
public function listAction() { ... } public function searchAction() { ... $this->view->setTemplatePathAndFilename(... 'List.html'); ... }
The above code only works if the folder contains List.html and (an empty) Search.html. Without Search.html, the error message as per description will be displayed.
I my opinion, the issue still exists.
Hope this helps.
Updated by Alexander Opitz about 10 years ago
- Project changed from 2559 to TYPO3 Core
- Category changed from Fluid: View to Fluid
- Status changed from Needs Feedback to New
- TYPO3 Version set to 6.2
- Is Regression set to No
Updated by Markus Klein almost 10 years ago
Some ideas to solve this: # Set an empty dummy template by default if the actual file is not there (may be strange for a dev if the output is always empty just because of a typo in the file name) # Add a configuration that sets a different template for an action (works only if the template is known beforehand, not for dynamic template selection) # Add a configuration that disables the automatic evaluation of the template file to use (leaves the work to the action itself)
I guess a combination of those is the way to go.
"Strong default" is the present behaviour, but the dev can choose to modify the behaviour by defining an alternative template, if he/she sets it to an empty value an empty file is loaded as template.
Updated by Helmut Hummel almost 10 years ago
If I understand this correctly, I think this would help:
https://jira.typo3.org/browse/FLOW-107
https://review.typo3.org/#/c/33884/
Setting the template file in the action method is understandably too late, as the view is already initialized
Updated by Philipp Gampe almost 10 years ago
I agree to Markus here. We need a dummy view to be initialized without requiring the actual associated files to exist. In the long run, the view initialization should be changed, as discussed in the flow ticket.
The bug is about initializing all views as html view first and then switching to json view later on. This requires that the html files must exist even if they are not used.
Updated by Matthew Colton almost 10 years ago
It would be nice to have a initialize{ActionName}View method. In that way the the code would be cleaner. And as far as I understand the current solution sounds more like a "hack" to me. :)
Updated by Helmut Hummel almost 10 years ago
Philipp Gampe wrote:
We need a dummy view to be initialized without requiring the actual associated files to exist.
Why that?
In the long run, the view initialization should be changed, as discussed in the flow ticket.
Why not just do that now?
The bug is about initializing all views as html view first and then switching to json view later on.
No, it is not at all about the format. If a format is given then Extbase already resolves to the template with the correct file extension.
This requires that the html files must exist even if they are not used.
This is about wanting to change the filename from the conventional name (ActionName.format) to another one.
The challenge: find a good way to do this. Flow has a View.yml where you can easily achieve what is discussed here with a small yaml configuration file.
Updated by Markus Klein almost 10 years ago
So do we want to introduce YAML support for CMS? Or should the configuration go somewhere else?
Updated by Claus Due about 9 years ago
Several alternatives exist:
- Override "resolveViewObjectName" method on controller and make it return a custom View class with a relaxed "canRender"
- Override "resolveView" and relax the checks for "canRender".
- Put the custom View class in the expected namespace-based custom View class location for your controller.
- Use setViewConfiguration (happens immediately before canRender call) to force a desired filename - it is, after all, also a "view configuration".
I agree to Markus here. We need a dummy view to be initialized without requiring the actual associated files to exist.
I disagree with you both here :) it is formally correct that if the View resolved by the Controller cannot render the Request as the Request appears without modification, it should - in the default implementation at least - report this as exactly an error. If one wishes to replace this behavior, any of the alternatives above will suffice.
So do we want to introduce YAML support for CMS?
No thanks. This can already be solved in so many ways without yet-another-configuration-file. No configuration is required.
I suggest closing this as "Has plenty existing API-based alternatives".
Updated by Markus Klein about 9 years ago
- Status changed from New to Needs Feedback
Claus: Honestly, for the requested feature "change the used template" only the last option can be taken seriously. I would by all means refrain from replacing too much functionality from the Core in my own extension. Overwriting @setViewConfiguration()
is indeed one option, which still allows to simply call the parent's implementation and modifying the template afterwards.
Updated by Claus Due about 9 years ago
Claus: Honestly, for the requested feature "change the used template" only the last option can be taken seriously.
I'm happy that at least you take me 25% seriously then (man, that's a bad way to proclaim an opinion about my suggestions. Really unprofessional, imho, and you don't even give me the courtesy of an argument to substantiate your ridicule).
I would by all means refrain from replacing too much functionality from the Core in my own extension
And I would refrain from allowing every edge use case we come across, some years old by now, to dictate the creation of new logic, like YAML view configuration, or forcing controllers to initialise the View before being able to say if it can render the Request, in the core.
Updated by Markus Klein about 9 years ago
I'm happy that at least you take me 25% seriously then (man, that's a bad way to proclaim an opinion about my suggestions. Really unprofessional, imho, and you don't even give me the courtesy of an argument to substantiate your ridicule).
You obviously understood that a bit wrong. I really don't know where you see "ridicule" in my comment and I did not - by no means - attack you. There is no reason for me to do so.
All I expressed is that I don't consider the first three options you present as something I would tell a developer to solve the issue at hand as they need to modify/copy too much of the Core's implementation. All options for sure would do the job, but as I said, I would refrain from replacing too much Core code in my extension. The fourth option is a good solution, which is minimal effort to implement and also requires no copying of code.
And I would refrain from allowing every edge use case we come across, some years old by now, to dictate the creation of new logic, like YAML view configuration, or forcing controllers to initialise the View before being able to say if it can render the Request, in the core.
I agree with that, and I was never pro-YAML. (I'd also refrain from introducing any new configuration language in the whole CMS Core.)
If you agree, we can close this ticket.
Updated by Claus Due about 9 years ago
You obviously understood that a bit wrong. I really don't know where you see "ridicule" in my comment and I did not - by no means - attack you. There is no reason for me to do so.
It's implied when something is not taken seriously when it is meant seriously. But I understand what you mean after this explanation; looks like you meant "recommendable".
All I expressed is that I don't consider the first three options you present as something I would tell a developer to solve the issue at hand as they need to modify/copy too much of the Core's implementation. All options for sure would do the job, but as I said, I would refrain from replacing too much Core code in my extension. The fourth option is a good solution, which is minimal effort to implement and also requires no copying of code.
And here's where I would have to chip in and say: sometimes, more often than you'd think, I'm already creating custom View classes to gain access to custom rendering behaviors. IMHO replacing a view isn't so much a matter of replacing a core implementation, as it is a matter of using an API-based, convention-for-classnames feature - Extbase was built for working with such custom Views. That's why I include this feature as a way to solve this. It might not be the ideal way if you "just need a controller", sure. But it is nonetheless perfectly valid and, imho, equally good solutions for the problem at hand.
And last point, technically speaking, neither of the View-based solutions 1, 2 or 3 require code copying. They require subclassing and selective method overrides and are only different from solution 4 in that they also require a subclassed View. But I do understand what you mean. In terms of LOC the fourth solution is probably smaller - but it's not by much!
I agree with that, and I was never pro-YAML. (I'd also refrain from introducing any new configuration language in the whole CMS Core.)
If you agree, we can close this ticket.
Completely agree, I think we've properly explained all the current API-based ways of achieving this goal without the need for a code change :)
Updated by Markus Klein about 9 years ago
Of course you need to override all the functions of each proposed solution, but as I read the code in the ActionController you need copy quite some code from the existing functions, as you need to adjust the code somewhere in the middle, whereas the last solution only leaves you to call the parent and then overwrite the template filename. (Didn't test that though, just by reading.)
I don't do that much with extbase, but I never had any reason to write my own view class. So your use cases seem to be exceedingly different. ;-)
Closing this now.
PS: Of course I'm really looking forward to inclusion of the standalone Fluid made by you, even though I didn't find time to take a closer look, what exactly you had to adjust to make it work, but I assume it's a lot. It's a pity that you're not available on Slack btw.
Updated by Markus Klein about 9 years ago
- Status changed from Needs Feedback to Closed
Updated by Sybille Peters over 4 years ago
- Related to Bug #58746: setTemplatePathAndFilename not work when original Template was not found added