CodeIgniter Forums

Full Version: Controller Filters - Input needed
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
Subjectively, my idea about middlewares and/or filters is similar to CI3's core hooks. The only difference is that hooks are core level broadcasts that you can tap into. CI3's everything-singleton had a nice effect on auto-loaded libraries, which could act similarly as middlewares.

Meanwhile, one thing I noticed in Laravel is its ability for developers to either use routes only and/or routes plus controllers approach. CI3's routes on the other hand is a good thing because it's not a requirement. In short, I'd vote for middlewares NOT to be available in routes because too much convenience approach would put a lot of stress and confusion to the framework's structure. Middlewares should be explicitly implemented on areas that have proper structures like classes. Even CI3 Form Validation itself needed to be discussed thoroughly whether it should be placed in controllers (based on documentation samples) or on models. It's a good thing CI implemented it as a Library so it can be used anywhere, explicitly.

I keep looking back at CI3 in hopes CI4 can still be used similarly while adapting to the new PHP7 features, without adding too much conventions that would complicate projects. Know the cons about too much convenience and implicit implementations by following Laravel's 5.2 Auth implementation (controllers, models, middlewares) https://laravel.com/docs/5.2/authentication and see if you can grasp the entire flow within 3 to 5 minutes.
FuelPHP uses this:

use_before();

and use_after();

From what I have seen the use_before(); etc; Is mostly used for setting up view templates.
Or themes.
(07-07-2016, 09:06 PM)albertleao Wrote: [ -> ]I would propose a filter/middleware system where you could have a single file to declare your filters and where they would be attached. Whether this happens in the routes.php file or not doesn't matter, but I believe that having that file would be much cleaner and more maintainable than the filter system that Rails currently uses. Is it possible to have CI4 check the routes.php file for middleware/filters even if auto-routing is enabled? Is it possible to have a filters config files?

Great idea!!
(07-10-2016, 06:46 AM)arma7x Wrote: [ -> ]
(07-07-2016, 09:06 PM)albertleao Wrote: [ -> ]I would propose a filter/middleware system where you could have a single file to declare your filters and where they would be attached. Whether this happens in the routes.php file or not doesn't matter, but I believe that having that file would be much cleaner and more maintainable than the filter system that Rails currently uses. Is it possible to have CI4 check the routes.php file for middleware/filters even if auto-routing is enabled? Is it possible to have a filters config files?

Great idea!!

I'm good with this one as well. Just like CI3's hook system.
(07-10-2016, 06:46 AM)arma7x Wrote: [ -> ]
(07-07-2016, 09:06 PM)albertleao Wrote: [ -> ]I would propose a filter/middleware system where you could have a single file to declare your filters and where they would be attached. Whether this happens in the routes.php file or not doesn't matter, but I believe that having that file would be much cleaner and more maintainable than the filter system that Rails currently uses. Is it possible to have CI4 check the routes.php file for middleware/filters even if auto-routing is enabled? Is it possible to have a filters config files?

Great idea!!

I think that would probably work good, also. I was originally trying to stay away from "middleware" since we'd discussed middleware internally and it had some other connotations that we wanted to shy away from. We'll just make sure we name it something different, to stay away from those connotations, and the fact that it's got several other names out there in use already (filters, policies, etc) works for us, I think.
(07-10-2016, 07:23 PM)kilishan Wrote: [ -> ]I think that would probably work good, also. I was originally trying to stay away from "middleware" since we'd discussed middleware internally and it had some other connotations that we wanted to shy away from. We'll just make sure we name it something different, to stay away from those connotations, and the fact that it's got several other names out there in use already (filters, policies, etc) works for us, I think.


Great to hear!
So, here's what I'm thinking for the config file. This would seem to cover all of the bases, and still be simple to use, right? I thought of mapping to controllers instead of URI's/routes, but this seemed to make more sense so the application could change the underlying controllers if needed and still be covered.

Code:
<?php namespace Config;

class Filters
{
    // Makes reading things below nicer,
    // and simpler to change out script that's used.
    public $aliases = [
        'isLoggedIn' => 'App\Filters\Authentication'
    ];

    // Always applied before every request
    public $global = [
        'isLoggedIn'               => ['except' => 'login'],
        'CodeIgniter\Filters\CSRF' => '*'
    ];

    public $routes = [
        'admin/*' => [
            'before' => ['isLoggedIn'],
            'after' => ['somethingElse']
        ]
    ];
}
Interesting. I'm glad everyone seemed to agree that separating the filter logic from the controllers is a good thing.

I have a few questions for the code posted above:

1) Would the $routes array mean that if I had 100 routes that I wanted to use a certain before filter but I did not want in the global score mean that I'd have to to set that filter for each individual one?
For example:

PHP Code:
    public $routes = [
        'admin/*' => [
            'before' => ['isLoggedIn'],
            'after' => ['somethingElse']
        ],
        'profiles/*' => [
            'before' => ['isLoggedIn'],
            'after' => ['somethingElse']
        ],
        'users/*' => [
            'before' => ['isLoggedIn'],
            'after' => ['somethingElse']
        ],
        'posts/*/store' => [
            'before' => ['isLoggedIn'],
            'after' => ['somethingElse']
        ],
        'posts/*/destroy' => [
            'before' => ['isLoggedIn'],
            'after' => ['somethingElse']
        ],
    ]; 

2) Would the $routes array follow the inputted url or the routed url?

3) Would it be simpler if we reversed the array and were able to create multiple routes under a group of filters? I would think it's much easier to copy a group of routes into a filter than add a filter to a bunch of routes.
(07-10-2016, 09:55 PM)kilishan Wrote: [ -> ]So, here's what I'm thinking for the config file. This would seem to cover all of the bases, and still be simple to use, right? I thought of mapping to controllers instead of URI's/routes, but this seemed to make more sense so the application could change the underlying controllers if needed and still be covered.

Code:
<?php namespace Config;

class Filters
{
// Makes reading things below nicer,
// and simpler to change out script that's used.
public $aliases = [
'isLoggedIn' => 'App\Filters\Authentication'
];

// Always applied before every request
public $global = [
'isLoggedIn'               => ['except' => 'login'],
'CodeIgniter\Filters\CSRF' => '*'
];

public $routes = [
'admin/*' => [
'before' => ['isLoggedIn'],
'after' => ['somethingElse']
]
];
}

Yes, this is the one.

On the other hand, I'm just being nit picky. But it's not to dish out anyone. It's to make CI one of the best frameworks out there. Shouldn't we be practicing folders as plural and classes singular? I'd prefer CI4 to be consistent: Apps\Filters\Auth, Configs\Filter. It's a good thing the entire PHP community didn't follow Java samples like org\somefolder\something, com\somefolder\something. A lot of Java developers didn't know that org and com are both organization and company respectively to be used as fully qualified namespace like BCIT\CI\SomeFolders\Something.
My thoughts, while still forming, are:

1) Yes, that's how I pictured it, though there might be some syntax options that could make that more palatable.

2) $routes array is probably bettern named $uri - since it would be the input url. This makes it simple to modify the underlying guts of the site, while still keeping things intact, as long as the URI structure doesn't change.

3) I had that thought, also, and haven't explored it much yet, but it seemed easier to keep a mental picture of what was affecting a portion of the site by grouping them by uri. Instead of checking 3 or 4 arrays to make sure that the admin area had everything applied to it, etc. I guess using your example, it would be something like this, then:

Code:
public $filters = [

    'isLoggedIn'    => ['admin/*', 'profiles/*', 'users/*', 'posts/*/store', 'posts/*/destroy'],
    'somethignElse' => ['admin/*', 'profiles/*', 'users/*', 'posts/*/store', 'posts/*/destroy'],
];

In some ways this is definitely cleaner, but I can't help but think that once a site gets big enough, it's going to be confusing to keep in mind what's being protected either way. The first way (with some additional syntax for grouping routes, or something) makes it easier to look at a portion of your site and make sure it has all of the filters applied it needs, to me anyway.

I'll have to make a list of general types of filters that we'd expect to be used and see which way would be easiest for each of them to be applied.
Pages: 1 2 3 4