Skip to content
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

Controller Filters #150

Closed
6 of 8 tasks
lonnieezell opened this issue Jul 7, 2016 · 4 comments
Closed
6 of 8 tasks

Controller Filters #150

lonnieezell opened this issue Jul 7, 2016 · 4 comments
Assignees
Labels
new feature PRs for new features
Milestone

Comments

@lonnieezell
Copy link
Member

lonnieezell commented Jul 7, 2016

Inspired by Rail's ActionController filters and PSR7's Middleware concepts, we should look into incorporating some form of actions that can be run before and after controller methods.

We cannot simply do route middleware since CI does not restrict routes to be defined. This makes the most sense in the CI world view - so don't ask. :)

Hooks may be able to work for this, though they have always been used in the past as a global way to interact with the hook points, but is worth considering.

*EDIT: BASED ON DISCUSSION IN THE FORUM (see thread below) I THINK WE'VE LANDED ON SOMETHING LIKE: *

  • A new "filters" config file exists that allows us to specify what filters apply to what controllers/methods. Something like Sails.js policies could work here. Will need to determine the exact format later.
  • MUST be able to redirect out of a filter and have the current controller loading ignored, like if it's being used for authentication.
  • MUST be able to return error responses at this point, like bad API calls, missing CSRF fields, etc.
  • Should have a before and after filter. Before can stop the current request, after has access to the request.
  • Should have an easy way of setting global filters that affect everything, with the possibility of excluding a handful, if needed.
  • It might be handy if "after" filters could be set during run-time. Not 100% on this one, but it could be nice for bad word filters, etc to be applied as needed without modifying the main file. Then again, that might just complicate things.

Some refactors:

  • CSRF should be refactored to be a filter so it's easily applied to exactly the controllers/methods you want, while leaving out the couple you might not want.
  • Full-page caching should be refactored into a filter?
@lonnieezell lonnieezell added the new feature PRs for new features label Jul 7, 2016
@lonnieezell lonnieezell added this to the Pre-Alpha 2 milestone Jul 7, 2016
@albertleao
Copy link

Is there a thread we can discuss this on on the CI forum? I know I threw my 2 cents a couple of weeks ago when it came to route middleware on the forums, but having worked a lot with Rails with a larger dev team, the filtering system in controller quickly becomes a headache as compared to middleware functionality.

I understand the point of view of 'We cannot simply do route middleware since CI does not restrict routes to be defined.', but the benefit of having all of your middleware/filters in one file is that it is easily definable and much easier to document and read as your application grows.

Now I'm not going to pretend I'm an expert in building a framework, but would it be possible to have CI check the routes.php file even if automagical routing is on to check for middleware/filters? Or maybe have a separate filters file where you can input an array of controller/actions that will be associated with a filter of some sort?

I'm just looking at my current use cases (3 CI 3.0 apps in production and 2 Laravel 5.2 in production) and the ease of use of being able to identify and modify my filters/middleware in one spot is what makes the psr7 middleware system such a breeze compared to my older rails apps where I had to make sure all my filters were correct in each controller, which can ended up giving me sever code anxiety when i had 3-4 devs working on project. In my current codeigniter apps, I find myself having multiple base controllers which I extend on depending on the functionality. This could become an nuisance when filters start cascading down controllers.

@lonnieezell
Copy link
Member Author

Good points. There is a thread now where I've asked for input on it.

@lonnieezell
Copy link
Member Author

Based on discussion in the forum, the description has been updated with current thoughts.

@lonnieezell lonnieezell self-assigned this Jul 11, 2016
@lonnieezell lonnieezell mentioned this issue Jul 15, 2016
@lonnieezell
Copy link
Member Author

Implemented and merged in 18aafdc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature PRs for new features
Projects
None yet
Development

No branches or pull requests

2 participants