-
-
Notifications
You must be signed in to change notification settings - Fork 835
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
Introduce RequestUtil #2449
Introduce RequestUtil #2449
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aren't all methods supposed to be static ?
Yeah, also I haven't changed any of the usages in the code yet. Actually I should have put this in the issue as a comment (since I just want to confirm which attributes we want to provide an API for) not as a PR, not sure what I was thinking |
Abstracts access to following request attributes: - actor - session - locale - route name
01b35ae
to
2584be8
Compare
|
||
class RequestUtil | ||
{ | ||
public static function getActor(Request $request): User |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a branch lying around somewhere that basically does the same thing, but more along the lines of Actor::fromRequest()
. I liked that a lot. Maybe you like the idea, too? 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just saw more discussion in #2703 and related tickets. Have fun. 😀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actor is sensible too, but I prefer RequestUtil
because:
- While getting it is clean, setting it results in clunky naming, as with the user method.
- If we need to encapsulate more stuff, we don't need to add more util classes / force people to import as much stuff. Perhaps separate classes is slightly better with respect to single responsibility, but I think encapsulating request data is still fairly granular. Better than adding it onto
User
anyhow 🙈
Fixes #869
Abstracts access to following request attributes:
Are there any attributes on here that we're missing (or that we should exclude)? $actor is the biggest one that needs to be abstracted away IMO, do we even need the others?