Task #39121
Encapsulate PHP superglobals for Http\Requests
| Status: | Rejected | Start date: | 2012-07-20 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | Marco Falkenberg | % Done: | 0% |
|
| Category: | Http | |||
| Target version: | TYPO3 Flow Base Distribution - 2.0 beta 1 | |||
| Sprint: | Has patch: | No | ||
| PHP Version: | Complexity: | |||
| Votes: | 0 |
Description
The superglobals used for initializing the Http\Request classes ($_GET, $_POST, $_COOKIE, $FILES, $_SERVER) should be encapsulated in a wrapper. The advantages are:
- Because of the abstraction you can transparently implement a transformation of these variables, e.g. for different OS's or versions of PHP.
- You can add more utility functions to the encapsulating class in the future.
- The encapsulating class could be a singleton and could be injected by constructor into the Http\Request class. By now the proxy for the Http\Request is not used because the HttpRequestHandler creates the Request by a static constructor function.
Related issues
| related to TYPO3.Flow - Bug #39005: Proxies for Http\Request not used | Resolved | 2012-07-16 |
History
Updated by Karsten Dambekalns 11 months ago
- Status changed from New to Needs Feedback
We had a superglobal replacement object which even blocked access to superglobals for security reasons. But as soon as we started to integrate 3rd party code, that turned out to be a blocker, so we dropped it again. For the same reasons I think we should leave the superglobals alone - they are one of the PHP fundamentals, after all.
Updated by Robert Lemke 10 months ago
- Status changed from Needs Feedback to Rejected
Thank your for the suggestion. However, due to the points Karsten explained and some more internals, we won't encapsulate superglobals.
The recommend way is to leave superglobals alone, completely ignore them, don't touch them.