The Request class rework |
PHP Code: class Request PHP Code: class IncomingRequest extends Request PHP Code: //url host/path/?a=1&b=2&c=3 with POST method a=2&b=3
It's only my opinion, but I find it even more confusing... I don't see that as an improvement. Your get() method returns data from $_POST. Why not from $_GET? What's the use case for get('c', 4) if it completely ignores c and always return 4?
I feel your APIs are a bit cleaner, but
I'm not sure what the benefit would be to change the current APIs. As includebeer says it may be more confusing for the current users. Also, what about compliance with PSR-7? (12-08-2021, 04:37 PM)includebeer Wrote: It's only my opinion, but I find it even more confusing... I don't see that as an improvement. Your get() method returns data from $_POST. Why not from $_GET? What's the use case for get('c', 4) if it completely ignores c and always return 4? Thank you. Maybe I forgot, but it seems to me that this is the first time I get feedback on this forum thread. It seems to me that a possible reason why you do not understand why the get() method works with _POST, and not with _GET, is that you see the http method in the basis of the request, and I see the data. The get() method works with the current HTTP method. Be it GET/POST/PUST/DELETE/PATCH/etc That is, get() ! == _GET. get() === get the request data. get('c', 4) returns 4 because there is no "c" parameter in the current POST request. Therefore, the get() method returns a default value. (12-08-2021, 05:09 PM)kenjis Wrote: I feel your APIs are a bit cleaner, but I have already commented on your PR. Let me explain. Now you cannot get the default value of a variable if it is not in the request. If the variable is not defined you will always get NULL. Although NULL may be one of the expected values. Yes. Users may not immediately understand the nature of the changes. PSR-7 does not regulate in any way how to get the request data.
Ok, now I understand your logic. But I'm still not sure it's an improvement of the current class. Maybe I'm old school, but I'm not a fan of magic stuff happening behind the scene. For me it's easier to understand what is going on if I call a function to retrieve the POST data or the GET data and not a function that will return one or the other depending on the http method.
(12-08-2021, 08:21 PM)iRedds Wrote: It seems to me that a possible reason why you do not understand why the get() method works with _POST, and not with _GET, is that you see the http method in the basis of the request, and I see the data. I also did not understand your intent. And I think the `get()` is difficult to understand, because its behavior changes in the context. I prefer something like `getGet()`, `getPost()`, `getPut()`...
1. Routes depend on the HTTP method.
PHP Code: $request->get('resource', 'Controller::getRequest') 2. Even if the route listens to multiple HTTP methods, the controller still has to separate the logic for different methods. PHP Code: $request->match(['get', 'post'], 'resource', 'Controller::request') 3. The IncomingRequest class already has a getVar() method, which is independent of the HTTP method. Basically, you always want data sent by a specific HTTP method. For example, you won't call getDelete() if there was a GET or POST or PUT request. The only time to qualify a request method is any HTTP method other than GET + a query string.
iRedds
Your proposal is the same as Laravel, right? https://laravel.com/docs/8.x/requests#re...nput-value (12-10-2021, 02:39 AM)kenjis Wrote: iRedds Yes you are right.
Symfony
Quote: request: equivalent of $_POST;https://symfony.com/doc/current/componen...quest-data CakePHP https://book.cakephp.org/4/en/controller...parameters Yii https://www.yiiframework.com/doc/guide/2...parameters Slim https://www.slimframework.com/docs/v4/ob...quest-body |
Welcome Guest, Not a member yet? Register Sign In |