Framework: [5.1] Route::controller() deprecated?

[eidng8]

Just updated today, and suddenly see a bunch of deprecation warning.

Can't really find a clue on it, except #10781.

If it's deprecated, what should I use?

Route::xxx()?
or route()->xxx()?
or something else?

[squigg]

Set up each route manually using the standard post/get/put/patch/delete syntax. It's only the controller method that's deprecated.
http://laravel.com/docs/5.1/routing#basic-routing

You can use $router->xxx or Route::xxx or route()->xxx, depending on which flavour you prefer.

[eidng8]

Sorry to bump in a closed issue.

Shouldn't this be reflected in the document? http://laravel.com/docs/5.1/controllers#implicit-controllers

[GrahamCampbell]

It's not deprecated in 5.1 anymore as of the next 5.1.x release.

[eidng8]

oh~ great! Luckily I haven't start changing the codes. :sweat_smile:

[shehi]

@GrahamCampbell : Sorry for reviving closed topic, but I wonder - what triggered this deprecation? What was the idea behind this move? Is it related to the OP's concern in #10777?

[glandre]

Hello everyone, @GrahamCampbell, @eidng8 and @shehi,

I've been searching on the internet, but I couldn't find any example of problem that may occur while using implicit controllers. All posts I see people saying that it's not a good practice, and, because it's important to see explicitly all routes in your routes file. However, nobody actually provides a real example of possible problems of it.

In my opinion, if I know a route related to a specific controller, I will simply take a look at it's methods in order to find out the routes... Or maybe run a 'php artisan routes:list'.

For example, the method 'Route::auth' ends up in the same situation... I need to know which routes are related to it, but it's nice to have this helper...

Since I want to keep my project updated, and, because of that I want to use the latest version of Laravel, I'm planning to remove all Implicit Controllers. However I would like to get more clearer reasons why removing it, and, what possible problems this was causing.

Finally, why don't warn the user of the related problems and, allow it by providing extra documentation about the ways of using it in the right way? For instance, I imagine that a problem might be a public method implemented by mistake in the Controller, which will be accessible without the proper auth middleware. However, if the route::controller is in a Route::group with an auth middleware, this wouldn't be a problem... My point is, this helps in the development provided that you take the proper precautions... And, removing it will penalize projects under production when updating the version of the framework...

Thanks.

[shehi]

To my experience the problem with route-controllers mostly is related to hardcoded verbs in them (as in "get" in "getItem()" etc). That practice itself creates bottlenecks for large projects, and as you know you _had to_ provide verbs in route-controllers. By deprecating that practice, the team just removed the mandatory "verbage" of routes.

I was lazy about all those updates I had to in my code as well. But eventually, this decision proved to be quite right one, at least for me and my team.

Btw, iirc, deprecation was introduced in 5.2 and practice was totally removed in 5.3. In 5.1 it was some mistaken commit which deprecated it, but it was reverted later on.

[crynobone]

However I would like to get more clearer reasons why removing it, and, what possible problems this was causing.
Finally, why don't warn the user of the related problems and, allow it by providing extra documentation about the ways of using it in the right way?

This has been discussed directly in previous GitHub issues for numbers of time, deprecation has been made during 5.2.0 releases.

However, nobody actually provides a real example of possible problems of it.

If you search on the previous issues/PR under laravel/framework, the issues are basically these two, and those who are involved with the discussion mostly agrees on removing it:

1. Without artisan route:cache all implicit controller need to be resolved (running new FooController) which is not ideal for performance, this would also led to anything that resolved in the construct to be executed twice.
2. You can't use implicit/explicit method binding with implicit controllers, add this become an issue when developers expected it to be the same.

removing it will penalize projects under production when updating the version of the framework...

There's tool such as https://github.com/themsaid/laravel-routes-publisher to upgrade your code.

[glandre]

OK guys. Thanks for your insights. I'll try this command that will probably help a lot.