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)
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 @Agile_Dynamics 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:
Merci Coda for feedback on the matter, Cheers, Christiaan
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.
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.