right now, we're using the machine name for the key, i.e.

"field_occupation_origin_date" : "2011-10-15 00:00:00",

which is good because it's a sanitized value, however, it's not customizable.

Let's use the field label (if it exists) instead?

CommentFileSizeAuthor
#3 label-as-key-1578908-3.patch814 bytesdobe

Comments

phayes’s picture

phayes commented

This feels like a bad idea....

I wonder if we can add a custom attribute called "labels" that is a key => label map. Downstream consumers would then be responsible for re-stitching labels to fields.

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

using label might not be the best idea, but being able to configure the key looks tempting, especially when you want to have short identifiers for performance reasons...

dobe’s picture

dobe commented
Issue summary: View changes
StatusFileSize
new label-as-key-1578908-3.patch814 bytes

@phayes & @dasjo please explain in more detail why this is not a good idea? Labels are not being used at all right now...

Here is a patch. It just checks if a label exists if it does then it changes the key to it. Labels are pointless except if you're adding the field to the description right now. With json objects with thousands of features. Putting all that data into the description will cause problems regardless.

-Jesse

pol’s picture

pol
Location Brussels
commented

mmh mmh

  • Pol committed 5af0a91 on 7.x-1.x authored by dobe 
    Issue #1578908: Use field labels as keys in output.
pol’s picture

pol
Location Brussels
commented
Status: Active » Fixed
Related issues: +#2356957: missing "_rendered" suffix on properties seems causing problem with Google Store Locator , +#1578862: Only rendered fields should appear in geojson, +#2357027: Compatibility issue with new Views GeoJSON alpha 3

Committed, this might help with the other related issues.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.