TYPO3.Flow

Even though it is done a lot (we have caught ourselves here) it is really bad practice to have "delete" links in an application.
Per definition crawlers (including search engines) are allowed to follow links and the only reason that this doesn't end up in loss of data, is because those delete links are usually behind a login.. but imagine a delete link on a wiki.

Following the notion of "safe requests" will us allow to do great optimizations in the future such as:

• Running persistence in "readonly" mode for GET
• Partly disable validation for GET
• No CSRF hassle
• Smarter caching of GET requests

Don't get me wrong. Flow is known to be "opinionated", but this doesn't mean you're forced to do it the "flow" way. But I don't agree with your approaches for following reasons:

allow GET methods to tunnel other request methods

This would circumvent the whole "safe method" approach.

extend the link.action viewhelper with a method parameter, which allows to override the request method through the request method tunneling feature

That wouldn't work out for the above reason.
But what we should provide is documentation on how to adjust your application:

The preferred way is probably to replace links with little forms where possible:
from:

1<f:link.action action="delete">delete</f:link.action>

1<f:form action="delete"><f:form.button>delete</f:form.button></f:link.action>

If you really need links (I'd be interested in use cases) you could set some (data) attribute on the link and unobtrusively turn them into POSTs on click via JavaScript:

In Ruby on Rails the link_to helper has an argument :method that we could adopt to make this a bit easier.
So this:

1<f:link.action action="delete" method="delete">Remove</f:link.action>

would result in:

1<a href="foo/bar" data-method="delete" rel="nofollow">Remove</a>

The JavaScript RoR uses to turn this into a form on the fly is quite interesting, too:
https://github.com/rails/jquery-ujs/blob/master/src/rails.js#L151

And last but not least (or maybe also least):

You can keep everything as is and change your action from

1/**
2 * @param Foo $foo
3 **/
4public function deleteAction(Foo $foo) {
5  $this->fooRepository->delete($foo);
6}

to:

1/**
2 * @param Foo $foo
3 * @Flow\SkipCsrfProtection
4 **/
5public function deleteAction(Foo $foo) {
6  $this->fooRepository->delete($foo);
7  $this->persistenceManager->persistAll();
8}

Be warned though, that this circumvents CSRF protection (which might not be an issue here).

BTW: There is a brand new CsrfToken ViewHelper in Fluid to keep CSRF protection working for non-fluid forms & javascript POST requests

That's pretty much exactly what I thought of. A JavaScript helper would be cool too, just not sure how that could be properly bundled with flow, so that it works out of the box (automatic JS injection when a link.action method parameter is given?).

doh, I just realized that I replaced my long comment from yesterday by this addition.. does anyone has the original text still (maybe in your email inbox)? would be nice to add this again for others with the same question..

Bastian Waidelich wrote:

doh, I just realized that I replaced my long comment from yesterday by this addition.. does anyone has the original
text still (maybe in your email inbox)? would be nice to add this again for others with the same question..

Thanks to Marc I could add it to the above comment again. History rewriting FTW! ;)