Re: RFC: Server-Side Request and Response Objects (v2)

Hi Mike, > I like this, a lot. ... In general I think this would definitely be a nice enhancement to PHP, > IMO. Thanks for saying! > I do have questions about ServerResponse. It is not clear how that interacts with existing > echo, header(), setcookie(), etc? You say it creates a buffer; is > $responseSender->send($response) effectively the same as having issued regular echo, header(), > setcookie(), etc. all at once? That's correct. ServerResponse stores the (mutable) state of the response; ServerResponseSender reads from the ServerResponse and calls header(), setcookie(), etc. with its values. > each instance of $response has it's own buffer and can be sent at any time That is also correct. > Regarding ServerRequest ... How about instead creating an empty mutable object with the > constructor and then a method with an optional array parameter that adds the values and > "locks" it to be mutable, i.e. > > $request = new ServerRequest(); > $request->initialize(); > // OR > $request->initialize([ > '_SERVER' => [ > 'foo' => 'bar', > ], > ]); > > With this approach someone could create a class that contains the ServerRequest and build the > object up to be anything they like which could be useful for testing, i.e. > > $request = new ServerRequest(); > $request->get = [ 'foo' => 'bar' ]; > $request->cookie = [ 'id' => 123 ]; > $request->nv = $_ENV; > $request->server = $_SERVER; > $request->lock(); That is essentially what it does now; the difference is that you mimic the $GLOBALS array at construction time, and the instance locks automatically: $request = new ServerRequest([ '_GET' => ['foo' => 'bar'], '_COOKIE' => ['id' => 123], '_SERVER' => $_SERVER, ]); // $request is now locked The class that contains ServerRequest would then build up that array for the constructor. Do you feel that's close enough to what you're asking for? > I would also suggest considering to add get(), post(), request(), cookie(), server() and end() > methods to ServerRequest First, I'd have to decline adding request() (or $request) at all; my opinion is that one ought to be reading from $get, $post, $cookies, etc. specifically, not from a pool of those values. Second, if I understand you correctly, I much prefer the property access over the method getter; it just "looks and feels better": $request->get['foo'] vs $request->get()['foo']; Let me know if that makes sense to you or not. > incorporate the functionality of filter_input(). Otherwise we have to bypass the objects to > get filtering. I don't think you'd have to bypass the objects to get filtering; unless I am missing something, this ... $foo = filter_input(INPUT_GET, 'foo', FILTER_SANITIZE_SPECIAL_CHARS); ... would easily become this: $foo = filter_var($request->get['foo'], FILTER_SANITIZE_SPECIAL_CHARS); There might be behavioral nuances between the two, but the point is that you can still do filtering. > Would you not also add an option to generate a warning when using them for those who want to > deprecate their use in their own code (deprecating across the board would be too extreme give how > much CMS and framework code uses them intimately.) That seems a bit much at this point. ;-) I hope that answers all your questions. -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php