Route filters about core

[WinterSilence]

better to pass a string with the function body :

$filter = 'return $request->method() != Request::POST ? FALSE : $params';

and use create_function:

$this->filters[] = create_function('$route, $params, $request', $filter);

firstly it will avoid problems with the serialization of caching, and secondly less resources.

[happyDemon]

It would be the point to store the filters somewhere, e.g. in a module's init.php:
Route::filter('name_of_filter', function($route, $request){ //do some stuff });

And call the filter when needed e.g.

Route::set('default', '(<controller>(/<action>(/<id>)))')
        ->filter('name_of_filter')
    ->defaults(array(
        'controller' => 'welcome',
        'action'     => 'index',
    ));

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.

[WinterSilence]

@happyDemon mistakes:

The filters themselves wouldn't need to be serialized, only the name that's stored with the route.

Routes serialized at caching https://github.com/kohana/core/blob/3.4/develop/classes/Kohana/Route.php#L165

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.

It's true only if route used single filter, see https://github.com/kohana/core/blob/3.4/develop/classes/Kohana/Route.php#L460

There's no need to provide the $params variable since you can get that from the request object.

this request not contain params yet, also see previous comment

[kemo]

@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?

[WinterSilence]

1. Need to split the class code to classes: Router (collection of routes) and Route.
2. Need fix: values ​​passed to Route::defaults() and 'Route::uri()' are not checked for compliance with Route::$_regex
3. Does it make sense to store routes as objects? Would not it be faster to store data in an array and return the object in Router::get()

https://gist.github.com/WinterSilence/437395f886177017d4bc my earlier version

@kemo

routes can be cached, which doesn't mean filters have to be cached with them as well.

Then caching will not make sense. Add example, maybe I did not understand you.

the filter doesn't have to be a 'lambda'

I suggest using a string containing the function body (and use create_function()) instead of closure, then will not have problems with caching: at serializing closures replaced by the original strings (they stored in special property)

One thing I don't like about Laravel's "filters" is that they don't only filter, they do more than that.

Filters are rarely used, so no need to expand their opportunities.

[WinterSilence]

Create class wrapper for create_function: https://gist.github.com/WinterSilence/604e1cd86e242e592795

[shadowhand]

Using create_function is not an acceptable solution for anything.

[WinterSilence]

@shadowhand Why do you think so?

[kemo]

@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.

[neo22s]

Seems also that garbage collector doesnt work there.
On May 27, 2014 11:28 PM, "Kemal Delalic" [email protected] wrote:

@WinterSilence https://github.com/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.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/500#issuecomment-44337947
.

[happyDemon]

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).

[lenton]

@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?

[moon0326]

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