Input Data Fields Validation Should Be at The Top of The List

[Monj]

In the world of software development, we often emphasize the principle: “Garbage In, Garbage Out.” The quality of data input directly affects the quality of the output. Today, I stand before you as a passionate member of the Glide community to address a critical need for our platform—a need that, if fulfilled, can significantly enhance the experience for developers and users alike.

First and foremost, let me express my admiration for Glide as a powerful platform. Its capabilities are vast, and it has enriched the lives of many developers. However, there is one significant challenge we face—input field validation. In the realm of software engineering, ensuring the integrity of user input data is paramount.

Effective validation should occur on the front end, prior to data transmission to the database. While Glide offers workarounds that can involve a multitude of steps, these methods, though helpful, often feel like an inefficient use of a developer’s time. We believe that our efforts should be focused on innovation and creativity, rather than spending hours laboriously validating inputs.

Imagine the impact on our community if Glide were to prioritize this feature enhancement. By addressing this fundamental need, Glide could catalyze a substantial improvement in the efficiency and productivity of developers. In essence, it would be like strengthening the foundation of a house, ensuring its stability and longevity.

I earnestly appeal to my fellow Glide developers to rally behind this crucial cause. Let’s unite to demonstrate the significance of this feature request to the Glide team. Please show your support by upvoting and providing comments that highlight the importance of enhanced input field validation in our beloved platform.

Together, we can elevate Glide to new heights, making it an even more invaluable resource for developers worldwide. Your engagement in this endeavor is greatly appreciated.

@david @NoCodeAndy @Jeff_Hager @Darren_Murphy @ThinhDinh @Mark

Thank you for your attention and support.

[david]

You’ve pinged me on the weekend and I don’t even understand what you’re asking for. Was this written by ChatGPT?

Data validation already happens on the client–can you please be more specific?

[Monj]

Hi @david,

Thank you for responding. First, I wrote my request first and asked ChatGPT to help me phrase it better.

Allow me to elaborate on this critical feature request that could significantly enhance our experience with Glide apps.

Currently, when we incorporate input form components into a form, it would be immensely beneficial if each component inherently possessed the capability to perform form validation. This would obviate the need for complex validation processes through tables, streamlining the form validation workflow.

Take, for instance, the Phone Entry component. Ideally, it should only accept numerical input and a limited set of characters such as ‘()±’. However, the current behavior permits any input, including letters, to pass through to the table. This leads to what can be aptly described as “Garbage In.” Presently, the workaround entails creating a computed field to perform this validation, which can be rather time-consuming, especially when dealing with multiple input fields.

The above Phone Entry component example is just one instance. Let’s consider a simpler case - the Text Entry component. Suppose we wish to restrict input to a specific length, say, 10 characters. It would be highly advantageous if we could define this input length directly during the design phase, rather than necessitating the creation of a computed field for subsequent validation.

In essence, the proposed feature would significantly streamline the development process, saving valuable developer time and effort. Your support for this feature request would be invaluable in advocating for its implementation.

I trust that this explanation clarifies the importance of this feature.

Thank you for your consideration and support.

PS. I have to say that I love Glide Apps and this request will only make my love for it grow even deeper.

[ThinhDinh]

What exact validation do you want?

[Monj]

I just posted my response. Please read above. Thanks.

[ThinhDinh]

@Monj

The above Phone Entry component example is just one instance. Let’s consider a simpler case - the Text Entry component. Suppose we wish to restrict input to a specific length, say, 10 characters. It would be highly advantageous if we could define this input length directly during the design phase, rather than necessitating the creation of a computed field for subsequent validation.

This is already built in.

[Monj]

Oops! I’m sorry, I meant the Number Entry component not Text Entry.

[Darren_Murphy]

You can set min/max values with the Number Entry component, and it doesn’t accept non-numeric inputs. Which additional validations should it have?

[Monj]

Here is an example and you can see that is allow non-numeric inputs. Am I missing something?

It did not validate the input. The validation shouldn’t even allow the form to be submitted. It should have given and error msg that nothing is allowed but numbers. The only way to do this is through the workaround of computed fields. Am I correct on this?

[Monj]

How about the Phone Entry component?

[ThinhDinh]

I don’t know how you got “w” in there, but “e” is considered a default possible key to enter in number entries for HTML5 number input elements. As I understand, it stands for the exponent, and is used for shortening long numbers.

E.g: 200 = 2 * 10^2 = 2e2.

However, I have not used this before. I just tried and see that I can’t submit an add form with the number entry having an “e” character.

I would also suggest you not tagging the team or us in the posts. A post in the feature requests section should be enough.

For the Phone entry component, phone numbers in some cases do have characters inside them, I think mainly for marketing purposes.

Phoneword

[Monj]

Okay Thank you.

[david]

In summary:

1. You want an option to make the Number entry stricter
2. You want some way to make the Phone Number entry stricter–phone numbers can contain letters and other symbols. Can you explain what you need in this case?

[Monj]

David,

In simple terms, all I am asking is that when we add a form component (during the design process) that we can have check a box or have some parameter settings that specify the validation of that component.

So when the user is filling out the form, the validation is happening live and NOT ALLOW the user to submit the form until they have filled out the form correct. Again, it would be VERY HELPFUL if we DO NOT have to spend the time trying to figure out how to do this with computed columns. It just takes too much time away from us, especially when you have lots of components to validate.

I hope this make better sense. Thank you.

[Monj]

@ThinhDinh

@Monj

The above Phone Entry component example is just one instance. Let’s consider a simpler case - the Text Entry component. Suppose we wish to restrict input to a specific length, say, 10 characters. It would be highly advantageous if we could define this input length directly during the design phase, rather than necessitating the creation of a computed field for subsequent validation.

This is already built in.

I just want to add that the min and max length validation still passes whatever amount of characters to the table regardless of what limit you enter in them. So technically, it doesn’t stop users from entering more characters and that defeats the purpose.

[ThinhDinh]

Do you still talk about the Text Entry component? I think it definitely works within a native form. Are you talking about a custom form?

If that’s the case, custom forms are just a workaround for us. Glide does not officially support it, and entry components’ validation have never been intended to be used outside of the native forms.

[Monj]

Yes, Text Entry on Custom Forms. Thanks.

[ThinhDinh]

Yeah, that’s not supported.

As noted above, custom forms are just a workaround, originally for the fact that duplicate validation is not supported in native forms for Classic Apps.