Allow DOT Operator to work on Objects returned by ParseJSON() and Object()

[Xyzor_Max]

we can build a Coda Object from JSON using the ParseJSON() function.

and we can build a Coda Object using a combination of Object() and List() functions.

but the resulting object should be able to be de-referenced with the dot operator.

so, for example
ParseJson('{"Title": "Lord of the Rings", "Author": "J R R Tolkienn" }').Title
should return “Lord of the Rings”

and, similarly;
Object("Title", "Lord of the Rings", "Author", "J R R Tolkienn").Title
should return “Lord of the Rings”

i consider this to be a bug. the use of the dot operator in Coda formulas is one of the key features that sets the language apart from all competing products

(as far as i can surmise, only Packs which return an Object with a Schema can support the dot operator for de-referencing)

max

[Christiaan_Huizer]

This would be more than welcome and even necessary to make the usage of web hooks easier for most makers including myself. Last weekend I went through a lot of documentation on JSON to finally conclude that Coda in the doc itself does not yet allow for working with the dot operator as @Xyzor_Max explains so well.

The logic we have to apply today includes quite some manipulation of an unexpected type that even includes a Slice() to get rid of a curly bracket at the start of the list.

The work around you find here:

How to Coda with JSON — main

Merci Coda for feedback on the matter, Cheers, Christiaan

[Paul_Danyliuk]

@Christiaan_Huizer

The logic we have to apply today includes quite some manipulation of an unexpected type that even includes a Slice() to get rid of a curly bracket at the start of the list.

No need to, just learn JSONPath. Some time ago it wasn’t supported but it’s been around for half of the year already or so.

How to extract @People and other @-references from a Text cell

A client asked me today how he could take a text field like this and extract people from it: [image] The “straightforward” ideas like using Split didn’t work. Links and @-references in formatted text are unlike the rest of the text: technically they occupy just one empty character and instead have an extended encoded descriptor telling what should be displayed in place of that empty character. Running a formatted text field through just strips those descriptors and that’s what you get: [imag…

[loucadufault]

This seems infeasible from a technical standpoint. Dot operators only work on objects with declared shapes, such as rows in a table or pack results conforming to a schema. To provide the same functionality on arbitrary objects dynamically would probably be much more difficult, as it would require evaluating the expressions to understand the shape of the JSON. Additionally, not being declared means that the shape can change at any time and cause referencing errors.

[Xyzor_Max]

agreed. i concede your point.

the ‘shape’ of the json may change dynamically, preventing the editor from knowing the name-space at edit time. and the coda system resolves name-space references to provide stability at both edit-time and run-time.

to allow late-binding dot referencing would require the editor to leave the operand unresolved at edit-time, and to generate an error at run-time if it failed to resolve.

both of those behaviours violate important rules of the CFL paradigm.

instead we must use the jsonPath parameter of the ParseJSON() function to deref the required object, as explained by @Paul_Danyliuk above.

it was a desire i had when using a lot of json objects, but i guess i failed to think its implementation through.

well spotted @loucadufault

max