Page and query generation

marco · January 11, 2022, 12:48pm

Hi,

I am sure this has been asked before so I hope I am not bugging… but it would be useful to modify the page generation and query generation process to make them a bit more flexible. Maybe this can already be done but I would like to:

generate an update page with all columns in the page, instead of the mini-form with 4 fields;
would be good if it was possible to auto-generate (or simply have there by default) CRUD queries for alla tables with all fields available.

what do you think?

M

Nikhil · January 11, 2022, 12:52pm

Hello! We will definitely improve this feature with your suggestions soon once the JSON Form widget is available

github.com/appsmithorg/appsmith

[Epic] JSON Form: Generate forms from JSON Object/Queries/APIs

opened 10:58PM - 09 Jan 21 UTC

areyabhishek

App Viewers Pod UI Building Pod Form Widget community Medium effort Epic Project

## Objective As a user, I should be able to generate a form with input fields b…y using fields of a DB table schema that automatically generates the queries, bindings and child widgets. As a user, I should be able to configure changes/validations easily here. ## Features - [ ] It should automatically identify the datatypes and associated widgets for the form - [ ] It should be able to add basic validations that can be enhanced by the user - [ ] It should be able to automatically connect the submit buttons to the relevant queries (PUT/POST/CREATE/UPDATE). ## Success Metrics | Goal | Metric | | ------------- | ------------- | | Simplify user experience | One-click to generate a form from a single DB schema and be able to map it to a PUT/POST request which updates/saves data | | Decrease the time needed to build a form | Time that user spends creating a form | ## Assumptions - Forms are the core building block of a web application - It is currently difficult/time-taking to set up a working form comprising of multiple child widgets and bind them all the data query and finally be able to add them to a post request - One of the most common operations in any DB is the insert/add/create entry operation. It would go a long way to save the user time by generating the scaffolding, if not the complete widget for users ## Requirements | Requirement | User Story | Importance | Notes | | ------------- | ------------- | ------------- | ------------- | | Connecting to Query/API | As a user, I should be provided with all the option to connect to different queries and APIs. Furthermore, I should be able to select the fields I need inside the form and I should be able to change the datatype to others from what was automatically connected | High | If this is not going to be based on the response object and depend on the DB schema, this will be removed from the scope | | Create a form from a JSON object | As a user, I should be provided with all the option to create a form from a JSON object apart from the Queries/APIs. All the other functionalities mentioned above will be extended here as well | High | - | | Identify datatypes and associated widgets | As a user, after connecting a DB query to the form, the platform needs to identify the widget types based on the data types. For ex: `Array` maps to `Select` widget. All the widgets need to remain configurable | High | related to the first requirement | | Basic input validation | As a user, I should be able to see basic input validations for the form I have created from an internal DB query and also be able to modify any of these easily | High | related to the first requirement | | Connect submit action to queries that update related DB schema | As a user, I should be able to easily configure the submit request which finally updates or saves my data. I should be shown all fields preloaded in my query and appropriate bindings against them | High | This might not be involved in this scope | | Auto naming with schema / object keys | All fields & label in the form should be named based on the schema key they are mapped to | High | - | | Reopen form config | Once import all fields from an object/datasource I should be able to reopen the config page view to alter any initial configurations. This will reset and changes made to the form elements individually. | High | The default connect data will be used for this, another CTA might be required to update the form data through the same workflow | ### Discussion 21-Sept-2021 - We will get rid of the modal which shows up in when setting up the form fields, Instead we show the fields under the field configuration directly - Fields on the form will be deep linked to the property pane field configuration, i.e. the respective property pane field setting should open when the field on the form is clicked - The form fields / view will reflect changes as the form data is updates - We need to keep in mind a future scope while developing the feature. Nesting of form fields / handling nested form data objects `needs design` `**_pending_**` ### Discussion 27-Sept-2021 We decided that the following will be the type of widget taking into consideration, Additionally the component used in this widget will have there own set of properties (like the table widget) which should be covered by automated tests to avoid any regressions in the future. We also discussed the form properties which will need design review Types of fields: - Text - Number - Phone - Email - Switch (boolean) - Checkbox (boolean) - RadioGroup (exclusive or) - Select (one out of many) - Multi-Select (many out of many) - Files - Date - Time Complex fields: - Grouped fields Additional (optional) fields: - Rate (Range) - Map (search) - JSON object - Audio ---------------- We figured Properties of fields: Common: - Type - Default - Label - Disabled - Required - Tooltip - Visible - helperText Not common: - Validation Fn - Error - Possible values (options) - Placeholder - onChange ---------------- `**_needs design_**` Main properties of the form for it to work: Form: data Form: submit (action) Form: source data Form: Edit the field types and properties Features in the form: Form -> input type -> possible properties Form -> has state of the fields Form -> onSubmit Form -> onCancel Form -> can hide cancel button Form -> can disable submit button Form -> can reset itself* Form -> checks for validations -> knows which fields have errors Form -> tab navigation works Form -> can scroll to selected fields Form -> button location (sticky | bottom) Form -> field styling (borders, colors, label alignment, error colors, helper text, etc) Form -> spacing between fields Form -> all fields have full width --------- Library to consider: react-hook-forms ------------ ### Discussion 19-Oct-2021 `Files` component is being considered out of scope right now as the implementation of the widget component is not well constructed to be used in this widget and would need a lot of refactoring. This can be considered in the next iteration. ## Out of Scope - Dynamic width / auto layout of form elements - Alignment templates/Layouts - As a dev, I should be able to choose the layout for aligning my input fields in the form. Templates can be 2 Column, Single column, Label & input side by side. Or, Drag to re-order elements side by side or one below the other ## Developer Handoff Document in Figma Link: https://www.figma.com/file/pZuLD9mWXtk45TOjAeh32b/Form-Widget-Thu-26-Aug?node-id=2%3A2 ## Questions | Question | Answer | Date Answered | | ------------- | ------------- | ------------- | | How to identify the submit request needs to be Create/Update? | It will by default be POST the user can change to there choice | | | Can we add necessary formatting function ex: JSON.stringify() automatically to remove any invalid api attributes | | |

marco · January 11, 2022, 3:34pm

Hi,

seems like an interesting feature, is there a delivery date yet for it?

you might have wanted to use surveyjs for it, save some time

M

Nikhil · January 12, 2022, 7:30am

@marco it’s scheduled for the end of the month