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

Global access to the request object #2307

Closed
iPurpl3x opened this issue Sep 24, 2020 · 1 comment
Closed

Global access to the request object #2307

iPurpl3x opened this issue Sep 24, 2020 · 1 comment

Comments

@iPurpl3x
Copy link
Contributor

Feature Request

I think it would be handy for extensions developers to provide something like app('request') to be able to access the current request object from anywhere in the code.
I agree that it may not be a good practice to resolve that object this way, but in some very specific cases this can be very useful. Also Laravel has done this so I think it is safe to do it for Flarum as well.

As I briefly mentioned in #2306, this could easily be achieved with a Provider that registers a singleton and a Middleware that assigns an instance to that singleton.

@franzliedke
Copy link
Contributor

Hi, and thanks for your suggestion! 😃

Sorry, this is one of the cases where I really want to veto.

I've taken great care to ensure that Flarum can easily be used with modern approaches like application servers (ReactPHP, PHP-PM, ...). This requires a mental shift from the good old days when everything was always "shared-nothing": global state was global, but only for the current request. No leaks, no worries.

I want to keep the container and application classes free of per-request objects. They should only deal with truly application-wide state, whether the PHP process only handles one request or multiple. There is one object tree that can be long-living, and then there are object trees for each request. In the traditional world, there will be no difference between them, but once you run with a PHP application server, there is.

Laravel does this, true, and I don't particularly like that. 😉 The downsides can be circumvented, alright, but you have to be aware of them. Just look at some of the dark magic that the Swoole adapter for Laravel has to do. Having this clean separation can sometimes make specific things a bit more complicated (though not impossible, in my experience), but has the benefit of being compatible with the different ways to run PHP applications - by design.


I believe we still have a few weaknesses in this regard, too, e.g. translator and possibly auth stuff, but I'd rather see those fixed than introducing more of them.

I hope this is understandable. 😉

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

No branches or pull requests

2 participants