[FEATURE REQUEST] Add support for emulating request method with forms
Ruby on Rails on its own previously emulated request method by considering _method post parameter as an intended request method. Some things could happen here too even if the parameter is more obscure (security through obscurity 😅 ). There are some corner cases where you can't / won't want to alter the request via AJAX.
I think this could be a configurable feature for the router since it has side effects.
So you want BramusRouter to check for the _method parameter and change behavior based on it?
If that is the case, I don't think that behavior should be part of BramusRouter in any way. You may want this behavior, but I (as a user of BramusRouter) wouldn't want it.
If what you are suggesting has some actual merit, please explain more, with examples if possible.
Also, you can easily add that _method check to the router with two lines of code to the beginning of getRequestMethod().
Since bramus/router Already supports the X-HTTP-Method-Override header, supporting _method seems like a nice addition.
Feel free to open a PR and I'll gladly merge.
Please note that your PR must include tests and an updated README. Also avoid massive PR's that change too much at once. Breaking changes are also not preferred.
@necmettin I know this feature is not wanted by some users since it can clash with existing codes where this POST variable is already used to something else. This is why I think it could be enabled via some configuration method, like $router->enableMethodOverrideFromPost(); to avoid clashes during updating Bramus Router via composer on an existing code.
@bramus Sadly I am not too good in PHP, I continously learning how to do things. Your code is awesome because it's easy to use for someone like me. I'm rather a Ruby/Rails developer but I've some projects that must be written in PHP.
I have been against this since day one not because it is a bad idea but because I don't see the merit in bringing a non-standard feature from another system.
(Not specific to this issue) I know I am not the decision maker on this but I have always been principally against bringing features from other systems just because a user is used to that feature. I always advise them to learn the new system before trying to bend it to their habits and practices.
This library is for PHP programmers and being in the industry for 20+ years, (as far as I can recall) I haven't met a single PHP programmer who wanted/needed a _method override. Just my 2 cents. Since bramus/router already supports what is an unwritten standard in method overriding, you could use that header maybe?
Forgive me if I'm overstepping my boundaries, but I still don't see the merits (although, sadly, I'm not yet a contributor).
@necmettin I absolute agree with your mentality. I don't ask this feature because it is in Rails and I want to use Bramus Router in same way as Rails routing. But I went trough few cases where this specific feature was cool because there was no way to submit the form via AJAX (that gives you the potential to add X-HTTP-Method-Override header) but the project itself was coded to use REST routes strictly and it could cause issues to work it around with alternative URL-s (and it could mess up the global URL namespace). So, if it you makes you comfortable about this issue, ignore my words about it's a part of the Rails framework and replace it with this comment.
It's way more common to POST a "_method" field, I'd say. And more failsafe. I'm not sure where you been the last 20 years?
https://laravel.com/docs/5.7/routing#form-method-spoofing https://github.com/dannyvankooten/AltoRouter/pull/84#issue-17379677 https://github.com/skipperbent/simple-php-router/blob/master/README.md#form-method-spoofing https://github.com/swagger-api/swagger-ui/issues/5306 https://symfony.com/doc/2.6/cookbook/routing/method_parameters.html#faking-the-method-with-method http://www.slimframework.com/docs/v4/middleware/method-overriding.html https://book.cakephp.org/3/en/development/routing.html#reserved-route-elements
@bubach Please keep it friendly.