I find myself making an “Superuser Table Record Editor” step a lot recently and was thinking of a widget concept that would suit this purpose. I don’t know if this is possible, but what if there was a widget that adapted to the table record you were wanting to edit.
I’m imagining a single widget that contains an interactive table on the left and a dynamic number of input boxes equal to the fields in the table on the right. Ideally you could pass into it a table name/id in app and optionally a record id to make it more dynamic than setting it up statically. Once the widget had the table id a number of input fields would pop up on the right like when you click on a record in a table to edit it in the browser. Once the user selected a table record in the interactive table the input fields populate with existing data if there is any. and it is freely editable.
I’d love feedback on this idea. I don’t have all the details fleshed out or the ability to make such a complex custom widget, but i believe it could be very useful
Hi @ktoole, great suggestion - we are thinking about how to make it faster to transact table data and this is a good example. As you may/may not know, we just released a bunch of new validation features for input widgets… now we plan on taking that further to speed up the creation of forms. What type of tables/data are you typically working with? Are there any examples you can provide?
The data validation is very useful. Especially the interaction enabled state feature. I would ask that in the condition section of triggers under current step input validity, a all required widgets be added, unless that is the intended purpose of all widgets in that dropdown.
Data types usually include text, numerical, datetime, and boolean
Here is an example of a templates table.
https://daniel-defense.tulip.co/w/DEFAULT/table/txhPxiNSAYEiQGhdD
The editing loop usually consists of select a record to edit, load table fields into variables to allow the user to abort changes, store those variables into the fields, clear the variables, and leave the step.
In instances where rev control is required the only difference being creating a working record that if aborted just deletes the working record and if saved iterates the rev. This instance would make the described widget not be the best solution without modification.