TYPO3 Core

Annoying bug but thanks for the report, for me with 6.0.4 the workaround with empty files worked!

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.

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.

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

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.

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

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.

So do we want to introduce YAML support for CMS? Or should the configuration go somewhere else?

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

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.

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.

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

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.