-
Notifications
You must be signed in to change notification settings - Fork 328
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Route filters #500
Comments
better to pass a string with the function body :
and use create_function:
firstly it will avoid problems with the serialization of caching, and secondly less resources. |
It would be the point to store the filters somewhere, e.g. in a module's init.php: And call the filter when needed e.g.
There's no need to provide the $params variable since you can get that from the request object. The filters themselves wouldn't need to be serialized, only the name that's stored with the route. There's no need to call create_function. I don't see a single app using dozens of filters. Unless I'm missing what you mean. Also there's no need to return anything. It would be wiser to Throw a HTTP exception if something went wrong or redirect when needed. |
@happyDemon mistakes:
Routes serialized at caching https://github.com/kohana/core/blob/3.4/develop/classes/Kohana/Route.php#L165
It's true only if route used single filter, see https://github.com/kohana/core/blob/3.4/develop/classes/Kohana/Route.php#L460
this request not contain params yet, also see previous comment |
@WinterSilence routes can be cached, which doesn't mean filters have to be cached with them as well. There's virtually no overhead defining an anonymous function (and remember, the filter doesn't have to be a 'lambda', can be defined as a call to a class method). One thing I don't like about Laravel's "filters" is that they don't only filter, they do more than that. Maybe there should be a different name for this? |
https://gist.github.com/WinterSilence/437395f886177017d4bc my earlier version
Then caching will not make sense. Add example, maybe I did not understand you.
I suggest using a string containing the function body (and use
Filters are rarely used, so no need to expand their opportunities. |
Create class wrapper for |
Using |
@shadowhand Why do you think so? |
@WinterSilence because it's a hack, because you write PHP code in a string and because it's simply not the way Kohana does things. + There is no need to cache methods. |
Seems also that garbage collector doesnt work there.
|
I'm willing to have a go at this and have a pull request ready in a few weeks. The main reason I'd like this is because I always seem to be hacking controllers' before method to serve specific needs for several of its actions (when these specific functionality actually should be defined on route level). |
@happyDemon Is the problem you're trying to solve: not being able to use different before/after methods for specific actions and/or specifying which actions should/shouldn't run the before/after methods? |
I used to use my own version of route module that supports filters. I used it only for just a month or so then stopped using it since I've moved on to a new framework. if you're interested in, checkout https://github.com/moon0326/Kohana-Route-Extended |
This is a feature I found handy while using Laravel.
Instead of having to inject the before method of controllers it could be nice to define route filters somewhere and assign them to the routes that need them (including a global route filter).
There's an added bonus for module developer that could bundle them, leaving them optional to use by other developer (instead of hardcoding them in a base controller).
http://laravel.com/docs/routing#route-filters for details
***edit
This would be for milestone 3.4 obvisously (forgot to add that to this ticket)
The text was updated successfully, but these errors were encountered: