This PR modifies the layer querying API to accept a JSON array rather than a comma-separated list of layer names, in order to allow for higher degrees of filtering to be done through the API. Filters applied via the API are templated around a layer's existing SQL query in the form of SELECT * FROM <existing query> WHERE <column> <operator> <value>. Multiple WHERE clauses can be strung together with AND and OR. The reasoning for these decisions is as follows:
Developers should be able to generate dynamic sets of tiles that vary with user input, but
API users shouldn't have too much access to database information in order to prevent confidential information from leaking.
Wrapping pre-existing queries allows developers to restrict the amount of information that is query-able.
It is safer to parse a JSON string than to invent a less-verbose data format and attempt to parse that using regexes, or something.
Demo
Notes
Caveats:
Using JSON makes the API a lot less human-readable/human-editable (but at lot easier for machines).
Changing the expected input for the ?layers query string makes me think the other query strings that work using lists should expect as JSON arrays as well, although I don't want to fix what isn't broken.
Most browsers have a length limit on URLs (in the 1000s of chars) which could hypothetically cause issues for elaborate requests.
Testing Instructions
Start the development server using ./scripts/update and ./scripts/server.
Open up demo/client-filtering.html.
Modify the JSON in order to modify the visible layer.
It may be helpful to open up the database with ./scripts/console database and execute some queries to determine what data exists in there to see. \d+ pwd_parcels; and SELECT DISTINCT owner2, count(*) FROM pwd_parcels GROUP BY owner2 ORDER BY count(*) DESC; are what I looked at.
Overview
This PR modifies the layer querying API to accept a JSON array rather than a comma-separated list of layer names, in order to allow for higher degrees of filtering to be done through the API. Filters applied via the API are templated around a layer's existing SQL query in the form of
SELECT * FROM <existing query> WHERE <column> <operator> <value>. MultipleWHEREclauses can be strung together withANDandOR. The reasoning for these decisions is as follows:Demo
Notes
Caveats:
?layersquery string makes me think the other query strings that work using lists should expect as JSON arrays as well, although I don't want to fix what isn't broken.Testing Instructions
./scripts/updateand./scripts/server.demo/client-filtering.html../scripts/console databaseand execute some queries to determine what data exists in there to see.\d+ pwd_parcels;andSELECT DISTINCT owner2, count(*) FROM pwd_parcels GROUP BY owner2 ORDER BY count(*) DESC;are what I looked at.Resolves #89