Add an endpoint for get pickersets

[70ray]

We could avoid the expand_pickersets() function by creating the pickersets with character names to start with but then we would have to change some other stuff to use the data in this form.

Sandbox at: https://www.pgdp.org/~rp31/c.branch/api_pickers

[cpeel]

Having this in the PickerSet class makes a lot more sense, thanks for moving it in there.

[70ray]

Sandbox updated.

[cpeel]

Brilliant.

For other reviewers, this can be tested with:

export API_KEY=review
curl -i -H "Accept: application/json" -H "X-API-KEY: $API_KEY" \
     -X GET "https://www.pgdp.org/~rp31/c.branch/api_pickers/api/v1/projects/projectID45b5cfaa0ff81/pickersets"

[srjfoo]

Brilliant.

For other reviewers, this can be tested with:

export API_KEY=review
curl -i -H "Accept: application/json" -H "X-API-KEY: $API_KEY" \
     -X GET "https://www.pgdp.org/~rp31/c.branch/api_pickers/api/v1/projects/projectID45b5cfaa0ff81/pickersets"

Thanks, Casey, that helps immensely.

@70ray, in looking at the output, the thing that stood out to me is that the numbers don't show the actual character. They're also bracketed by square brackets instead of curly, as with the others. I have a memory of you fixing something similar to that in the code -- is that what's going on here? (see screenshot below of picker set labeled 1.)

[cpeel]

@70ray, in looking at the output, the thing that stood out to me is that the numbers don't show the actual character. They're also bracketed by square brackets instead of curly, as with the others. I have a memory of you fixing something similar to that in the code -- is that what's going on here? (see screenshot below of picker set labeled 1.)

Oh, very good catch Sharon! We need to massage those into a string type instead of an int type. I forget exactly how we do that but you are correct we do that elsewhere.

[70ray]

@70ray, in looking at the output, the thing that stood out to me is that the numbers don't show the actual character. They're also bracketed by square brackets instead of curly, as with the others. I have a memory of you fixing something similar to that in the code -- is that what's going on here? (see screenshot below of picker set labeled 1.)

Oh, very good catch Sharon! We need to massage those into a string type instead of an int type. I forget exactly how we do that but you are correct we do that elsewhere.

An easy work-around would be to return pairs [character, name] rather than an assciative array. This would be just as easy for the client to use. So the result would be:

It is possible to use JSON_FORCE_OBJECT with json_encode() but this would make it encode all arrays as objects which we don't want.

[cpeel]

An easy work-around would be to return pairs [character, name] rather than an assciative array. This would be just as easy for the client to use.

We could, but we're doing something to coerce some array key numbers into strings already if you look at the very top of Sharon's screenshot:

What are we doing that coerces the 1?

[70ray]

An easy work-around would be to return pairs [character, name] rather than an assciative array. This would be just as easy for the client to use.

We could, but we're doing something to coerce some array key numbers into strings already if you look at the very top of Sharon's screenshot:

What are we doing that coerces the 1?

It seems that "1" is because the keys are a mixture of numbers and other characters, but if you use consecutive numbers starting from 0 it gets turned into an ordinary array. But we can coerce it into an object with (object).

[70ray]

But it seems an object is not the same sort of thing as an associative array.

[70ray]

Test has been adjusted so it works with an object. Is this a good solution or would returning the [char, name] pairs be better? I like the pairs better.

[70ray]

Sandbox updated.

[cpeel]

Is this a good solution or would returning the [char, name] pairs be better? I like the pairs better.

I think this solution works well. I'm partial to the hash as I think it lets clients easily get the keys via built-in functions. I'm not against the pairs though if you'd rather do that -- both seem acceptable to me. Whichever you prefer is fine.

[70ray]

I looked at how this appears when it gets to the javascript. Unfortunately the "1: numbers and math" key appears as an integer so the subsets get in the wrong order. mdn says:
"Within each component of the prototype chain, all non-negative integer keys (those that can be array indices) will be traversed first in ascending order by value, then other string keys in ascending chronological order of property creation."
I think the best solution would be to treat the components that we want to keep in the right order as simple arrays. I'll made it like this.

[70ray]

Github doesn't seem to be running the checks

[70ray]

Conflicts resolved, snadbox updated.

[cpeel]

This LGTM!