element - let’s say on the form submit trigger we like to validate fields → if end date is lower than start date show notification “End date must be equal or higher than start date” else add values to current row.
So, my question is - is there something like this coming cause for a real online app that is needed - and we would look then for now for another platform…
You’re right, native Glide Forms are somewhat lacking in data validation functions.
There is some basic data validation that can done at the component level. For example, with dates you can restrict the range to before or after the current date, you can set a range on number entry, and you can set a character limit on text entry.
For anything beyond that, you really need to use a Custom Form.
Custom Forms are a bit more work, but they give you much more flexibility, especially when it comes to data validation. The big difference is that data inputs are available in the data editor immediately, so you can use them to perform calculations and relate to existing data, and provide immediate feedback to the user - before the form is submitted.
That wouldn’t actually work with an Add Form.
When the user submits the form, a new row is added immediately.
Any onSubmit action that you configure runs after the form is submitted, and is completely independent of the Add Row action (which happens automatically).
So as I mentioned, a custom form is your best option.
Here is an example of a Custom Form in action, with built in data validation:
as soon as the user selects a Leave Type, we tell them what their available balance is
Start Date & End Dates are validated against each other
Once a valid date range is selected, the user is informed how many leave days will be deducted (accounting for weekends and public holidays)
The Submit button is disabled until all validation rules pass
This is the sort of stuff you can do with custom forms, that can’t be done with a native form.
Can you define what you mean by action component, an example use case perhaps?
We actually build in glide pages - I’m not sure if there is such thing as a custom form…
Our work around we are working on is: (like a programmer would tackle this…)
List → select → details screen → custom action → copy data to submission table → open detail screen for submission table → enter and validate data → custom action copy data to row in original table.
by action component I mean the custom action option to create own actions and then we could save them and use them elsewhere - same thing would be great for page elements to gather them in a component save that component and use it at another page in the webapp
Yes, Custom Forms can be used in both Apps & Pages.
Note that Custom Forms are not an “offical” Glide thing - it’s a just a technique that many of us use when we need that extra flexibility that the native option doesn’t provide.
Yeah, that looks a lot more convoluted than it needs to be. Hate to sound like a broken record, but that can be simplified with a … you guessed it
Ah, right. Re-usable actions.
Yeah, that’s been an outstanding feature request ever since Custom Actions became a thing. Glide have indicated that we’ll eventually get it, but no idea when…
Nice - thank you - had a look, basically it does exactly what we described up in our post just in one table instead of two. As we’re having a lot of fields, we think two tables would be cleaner, or is there a specific reason to do the temp fields in one table??
One small thing - should be all temp fields be user-specific? - we can’t really get the grasp out of them. If we got it right, there is no use of them in tables that needed to be edited by multiple users and therefore should be only for data protection or user-specific comments or should be all temp fields user specific?
User Specific columns are an essential feature of Custom Forms. Without them, you couldn’t have more than a single user of your App using the form at the same time - as they would be clobbering each other’s data.
This is a key difference between native forms and custom forms. With native forms, data input is held in the device memory and only committed to the underlying table once the form is submitted. But with a custom form - which is basically just a details screen with input components - all data is immediately written to the underlying table.
This means of course, that when a custom form is submitted, you need an add row action that takes the values from the User Specific columns and uses them to create a new row in the destination table.
The working table, whilst not essential, just helps to keep things a bit cleaner. It avoids polluting your main data table with a bunch of columns that don’t really need to be there. A nice side effect of using a Working table is that you can create re-usable Custom Forms. Once you’ve built your form on top of the Working Table, you can call the same form from anywhere in your App with a Show Details Screen action.