Hi Rowan,
> On Feb 26, 2020, at 12:55, Rowan Tommins <rowan.coll...@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
pmjo...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
