@anzze Specifying the namespace did scan, but still an empty routes.scanned file, filter not working. And when adding the path, I get directory not found, it is looking inside the app/ directory. Even with php artisan route:scan --namespace="Modules\Session\Http\Controllers\AuthController" --path="../Modules/Session/Http/Controllers/AuthController" nothing.

Either way, it's pretty tedious to have to manually run this for every controller. Hopefully something gets added that'll be smart enough to check in loaded controllers/routes.

Same here, no joy yet with route:scan, empty routes.scanned.php no matter what. In my case, looks like a conflict of existing routes.php and incremental annotations. Unfortunately, old approach not working anymore either (no luck with bringing back Illuminate\Routing\Controller; controller constructor filters not throwing errors that way but not firing either). As Taylor is in the process of committing other serious changes like this one https://github.com/laravel/framework/commit/30681dcf7d1b5ad0f06f8964e68ce6f350d89ddf (read Taylor's comments - interesting), I'll roll my L5 back to pre-weekend and keep away from Composer for the time being.

Another thought: As per this thread and other sources, is it fair to say that annotations are controversial enough that a substantial proportion of users will fail to see an upside and want to stick to the proven L4 approach? - If so, we might want to ask Taylor to keep L4 style in the core rather than shifting it to such "legacy" package, as the very "legacy" term suggests this will land us in a dead end sooner or later.

Well I'm not disappointed with the comments, I need to point out that I also disagree with the annotations style. We don't need meta programming, we do need good architecture in our apps, SOLID principles and things that I've been learning from Taylor, Jeffrey, even Fabien and I strongly appreciate. Now I feel like Laravel is pointing in two directions, things that advanced developers will absolutely love like dependency injection in methods and things that IMHO will impress newcomers but won't add value to the way we develop.

For me it's easier to use routes.php because it's PHP I can use variables, I can group my routes in different files, for example:

Route::group(['before' => 'user:admin'], function () {

    require 'routes/admin_routes.php';

});

Or I can even use some tricks like this: http://laravel-news.com/2014/04/laravel-tip-break-up-your-routes/

And my controllers deal with requests/response and my routes deal with... well, the routing.

I will continue using and supporting the framework, of course, but it hurts me, because I will have to work in projects with other developers that eventually will use this, even worse, projects that will use a combination of PHP routes + annotations.

Annotations and meta programming is something I really didn't like in Symfony, because you also have XML, and YML, and etc. Laravel looked simpler and more PHP oriented...

100% with you, @silence. I guess what surprises me most is that something as controversial as annotations (and as conflicting with Laravel's marketing claim "expressive & elegant") is going to be the only route [sic] to take, "legacy" package notwithstanding that nobody in their right mind will want to choose for a new project as this will break latest with L6 in 18 months or so. Laravel offers multiple avenues for numerous aspects of the framework - here, would make sense, too, IMHO, and probably a matter of 5 mins for Taylor to implement.

Wait... Legacy how? Really?

I really don't like the fact that this functionality with annotations are forced upon us. It would be ok if Illuminate\Routing\Controller was still here and it's the users choice to use annotations or not.

Like it is now I'm forced to repeat myself and use filters directly in the routes. Repeating myself, because I'm using a 'Modules' structure, and every module has its routes.

@silence - on the notion of "legacy" - here once again Taylor's original tone: "The only controller base class and controller dispatcher will be moved to a separate “legacy” composer package for 4.x upgrades. This will use the new illuminate.routing.disptacher custom container hook to register a custom dispatcher to provides backwards compatibility with those using the 4.x container base class."

Yes, but there he is talking about the BaseController class, (by the way +1 for the fact that our controllers won't have to extend anything, really liked that one), he is not talking about the routes, is he?

https://github.com/laravel/framework/commit/d7e0f13da9ccb8e8a7e1c0b77d62275632e2d17f

I'm not sure I follow this discussion any more.... Only base Controller class has been removed. Routes still work as they always did. So for example, the following still works:

get('test', ['as' => 'my-route', 'uses' => 'TestController@index', 'before' => 'auth']);

Annotations are not forced on you if you don't want to use them. You can still do everything from your routes.php file. So I'm a little confused - which feature are you missing?

@rspahni exactly, but you still can add routes in your routes.php as well as filters, etc. And you could indeed still use the base controller if you want, or create your own. No need to worry about that.

@anzze You are right! Routes as we know it aren't going anywhere.

Actually, I have my filters defined in the constructors of the controllers in $this->beforeFilter(...) style. For my app and its routing/filtering characteristics, by far the most efficient = DRY approach. Yet, not working anymore since this weekend, and won't for good unless I use that "legacy" package. Of course, I can put the filters back into routes.php but that will be a step backward. Same for annotations I'm afraid. But I'll survive.

I think that you may not getting the awesome of this change.

Imagine that you have a controller that relies on a group, you can just build the Controllers with the annotations, after the changes you can run "php artisan route:scan" and everything goes online automatically

@silence In my particular case, I'm using an API controller that automatically wraps responses in an array and appends some secondary data, plus optional debugging data. The reason I can do this is due to the specific way that Laravel calls controller actions.

I can get around this with a POPO controller, but I'd have to write an extra couple lines of boilerplate code for every controller function, and I'd rather not.

Imagine that you have a controller that relies on a group, you can just build the Controllers with the annotations, after the changes you can run "php artisan route:scan" and everything goes online automatically

Or you can do it in your routes file and have the same effect without having to run an additional step every time your route changes. ;)

@anzze et al - to be specific: beforeFilter() method was part of the late Illuminate\Routing\Controller and gone with it. I'm sure I'm not the only one who preferred routes in routes.php and filters in constructors. @maxccarvalho - up until here, I did not need to use a command to make my routes and filters work (unless I used L5 route caching). So I can't seem to see the efficiency increase.

@thepsion5 yes you can but, we have to agree that the changes in routes file are not so frequent.

We also have to agree that we work more on Controllers that on routes file.

Controllers points to URL, to path, to route paths. So you can determine this paths under the controllers, using the annotations.

Yes, I agree, its a one-more-command to run but, its not the end of the world.

And of course, we can keep the "old way" and use the routes file.

Yet I'm still waiting to hear/read a smashing argumentation as to WHY we should be running that one additional command and refactor our stuff. I.e. where's the value-added of annotations? Downsides we have a found a few, not the end of the world, now where's the upside?

In my opinion, the good thing is that the Controller keep more elegant, but that is my opinion only.

The automatic generation keeps the mistakes away.

But again, this is only my opinion. I imagine that, like in many other parts of the framework, Taylor will allow more than one way to do things, so the developers can choose what is the best approach.

I'm with @thepsion5

@rspahni @thepsion5 Your problems are a great representation of the importance of SOLID principles even in controllers. Relying on the controller logic provided by the framework or on the "specific way" the controllers are called in a certain framework is generally a bad idea. You are tightly coupling your controller implementation to the framework and of course your code breaks with every major framework release.

Naturally, using annotations is not a solution in this case - it violates the same rules as using $this->beforeFilter or any similar method provided by the framework. I like to make my controllers decoupled from the underlying framework implementation and if I need any shared logic, I write my own BaseController class. I only use tight-coupling on smaller projects, where I feel comfortable rewriting large parts of my code when the new framework version arrives or where I just don't care about upgrading.

Therefore I really like the new way controllers are handled in L5 - they are now nothing else but simple PHP objects and through the use of dependency injection you are now able to make them entirely decoupled from the framework.

@anzze - good points altogether but funny that you make the point, too, that annotations won't solve that dilemma. Let's rest this case though - Taylor's very active right now... https://github.com/laravel/framework/commit/00942094d12d53f6b7dc0f18c0bb5b242d334254 and we shall see where this all leads to. "Middleware" the title of the next heated thread, maybe. :)

@rspahni I like that the BaseController is gone, not the annotations (though I can see some use cases, just not in the project I'm building). Those are two different things.

And I agree - let's wait to see where the ship is headed. It will all be revealed very soon. :)

@anzze The whole reason we keep our controllers thin is specifically because they're intrinsically coupled to the framework. In fact, I'd argue that there are no classes more tightly-coupled to the framework than your controllers. And that's by design.

@thepsion5 Don't get me wrong - I agree with you. Decoupling controllers is not something many people do (and also, 100% decoupling is almost impossible) and it's not necessary as long as you feel comfortable with some refactoring when the framework changes. But when that happens, don't blame Taylor for it :)

I just wanted to point out that Laravel 5 takes controller decoupling one level further (it was possible to do it in 4.x too, but not to that extent). In any case, I try too keep my controllers as decoupled as possible, not because I keep any logic in them, but because I think it's a bad idea not do do it if you have better options. And it just saved me some time, since none of my code broke with the recent changes.

Hi,

I think it is an important step so everyone will see the need to "avoid overloading controllers with too much logic of work" , correct me if I'm wrong.

If I may offer my slightly unconventional view on decoupling: If this were my primary aim, I would not choose a framework to begin with but loosely coupled packages/components to tie together myself. In contrast, being a newbie probably ~1.7 times older than @JeffreyWay :), I want to rely on a framework so I don't need through all multi-year learning curves that the Jeffreys, Taylors, or Phil Sturgeons of this world have gone through. Let alone they may be 10x more brilliant than I, but either way I'd be retired [and broke] before having gone live with anything. Neither am I constantly thriving to swapping this with that or what else, for as long as I can get stuff done that matters to users/customers. With this I don't mean to take anything away from all the valid argumentation in favor of decoupling, just wanted to share my motivation for not doing it very much, and point to the fact that thinking the subject to the very end, we would all be putting out 100% POPOs, this forum would be empty and Taylor would have zero followers if it were our joint prio no.1.

I try to see this from positive POV. now, since controller is a POPO, then my controller is no longer couple to a specific framework. annotation is just like a comment where provide infrastructure information for the controller.

since annotation is embedded in the controller itself, IF someday I want to move to ABC Framework, I know exactly what I need to wired up the new framework in order to make my controller works. even if the new framework not supporting annotation, but the 'comment' will reminds me what to do according their way. Its more clear compared if the filters was configured in routes file.

just my 2 cents