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

Hi Rowan, > On Feb 26, 2020, at 12:55, Rowan Tommins <rowan.collins@gmail.com> wrote: > > That's a reasonable justification. Just to check, are there other > implementations that have both of these names side by side, or do most > implementations have one or the other, but using this naming? My recollection is that they have one or the other, but none with both side-by-side. (A very few have neither.) > The main confusion I can see is having to remember which two of these is an > error without having to read the docs each time: > > isset( $request->files['attachment']['name'][0] ); > isset( $request->files['attachment'][0]['name'] ); > isset( $request->uploads['attachment']['name'][0] ); > isset( $request->uploads['attachment'][0]['name'] ); /me nods While I too have imagined that, my impression has been that consumers of 1.x use $files unless & until they change their systems to use $uploads, at which point they switch over entirely to $uploads. Given that, my concerns (such as they may have been) are soothed. > If getUploads was a method, it could take a similar behaviour switch - > GROUP_BY_ITEM vs GROUP_BY_ATTRIBUTE or similar. For a property, that would > have to be part of the name, like $uploadsByItem and $uploadsByAttribute, > which are a bit ugly. > > Alternatively, you could lean more heavily on the legacy aspect, and have > $uploads and $uploadsLegacyFormat or something like that. Noted. Are there any others here who feel that the names $files and $uploads are "too confusing" (for whatever values of "confusing" you find appropriate) ? > Again, any mention of JSON or XML is drifting away from what I'm asking > for. Ah, my bad then. > What I'm asking for (or rather, suggesting would be a useful and > consistent addition) is a way to do *exactly what PHP does right now*, but > based on a given input string, rather than the initial request. I'm sorry, I'm still having trouble seeing what you're getting at. Do you mean something like this in the ServerRequest constructor? public function __construct(array $globals, ?string $content = null) { if ( ($globals['_POST'] ?? null) === null && strtolower($globals['_SERVER']['CONTENT_TYPE']) === 'application/x-www-form-urlencoded' ) { if ($content === null) { $content = file_get_contents('php://input'); } $globals['_POST'] = []; parse_str($content, $globals['_POST']); } // ... } If so, it seems unnecessary for the goals of this RFC, even overkill. If not, then I await correction. > To play devil's advocate, does the [$content] property belong in the object at all? If it > doesn't interact with any of the other properties (e.g. populating $post and $uploads based on > form data), could "better syntax for getting raw request for global state" be a separate > feature. Then again, maybe the ability to over-ride it in the constructor is enough to make it > useful. I continue to think it does belong there. Often enough, API developers will read php://input to decode JSON or XML they find there, so having it easily-available as $request->content is appealing. To boot, the other content-related headers are present, so might as well have the content itself there too. And as you note, it's easy enough to pass in custom $content via the constructor, e.g. for testing. * * * I feel that if these are the discussion points, then we are close to exhausting the topic (even if we do not agree on everything). Thank you for your diligence and attention to detail! -- 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