Hello everyone,
We successfully use the GRIST API to duplicate a template grist document, and upload data to tables.
Some of the data that we upload to the template could need to display extra columns that does not exist in the template’s views.
Is there a (hidden?) way to use the API to manipulate views to do it ?
Thank you for your help,
Xavier
Hello everybody,
We found another approach as a workaround : adding unused column in each tables of the template that are renamed if extra columns are in the dataset we import, or deleted if not used.
Cheers
Hello Grist Community,
I’m reaching out to revisit this topic, as our project could greatly benefit from the ability to create documents and manipulate views using the API.
Here are a couple of use cases that illustrate our needs:
We maintain a data model (dictionary) that we document using a Grist file. This file lists the name/ID of each column we use per table, along with their type, description, and allowed values. We’d like to programmatically generate a template from this dictionary to ensure that it stays in sync with our data model.
We’d like to create an interface that allows users to select only the parts of the data model that are relevant to the dataset they need to submit. The ability to dynamically create a customized view would be extremely helpful in this regard.
While we could potentially achieve this by reverse engineering the SQLite files, we would prefer a more official/lifelong solution. We believe that other use cases for this functionality may exist within the community.
@paul-grist, would implementing this feature require a significant amount of work? If so, our association may be interested in contributing financially to the development effort @dmitry-grist.
We look forward to hearing your thoughts on this matter.
Best regards,
There is an undocumented /apply endpoint that can make any change to a document that you could with the web client. People have had some success just watching what messages the web client sends on its websocket connection to the server, and replicating that on the /apply endpoint. Not a very satisfying solution, but the endpoint is stable and available today.
What would be more satisfying is a well thought out API that makes performing common operations easy while being expressive enough to also make advanced operation possible. Designing this API would be a significant chunk of work, although I expect implementing it would be relatively easy. That’s interesting, since it means over half the work could be done by a developer who is broadly familiar with Grist but may not be comfortable with its source code. Would you have a developer like that available to work on this?
Hello @paul-grist,
Thank you for your reply and the precisions.
The /apply endpoint might be considered, but after watching the call of the frontend, I feel that it will be quite painful to go through this path for what we have in mind.
I may have found a potential opportunity to host an intern this summer. It could be a suitable topic to discuss.
Meanwhile, we will continue our reflections on the simplest ways to address our use cases with existing resources.
Thank you