So I’m loving GlidePages. I created a form to allow people to sign up with google
But when you use the form container, it forces each field to stretch the entire length of the screen, UNLIKE the basic container block which lets you choose how wide across the screen you want the fields to go.
Below is a video where I show what I’m talking about but the text itself basically explains the problem.
I’m discovering Pages and liking it as well 
Any reason why you decided to not use the classic container with entry components (instead of the form container)?
Yes.
The form component, clears out all the fields when you submit. The regular component, leaves content in the field (at least the one above which I built using Glide Tables). So when you make a button that says “submit.” I can’t think of a “trigger acction” for the button that causes it to clear out the form fields without requiring the user to go hit page refresh or something. The DATA is already in the field but for user psychology they want to see the form emptied out and a “Thank you.” I can make the submit button pop up a thank you note and all that. … BUT … I can’t make it empty the fields out.
I thought about sending the user to a new page or something but that just seemed like the tail wagging the dog becuase when you went BACK to the home page after sending them to a thank you page, the form content is still there…inside the fields (as if it was never submitted) whereas with the Forms container… it gets cleared out.
Also the forms container greys out the submit button until all the right fields are filled in. That is quite nice.
Third… the forms container allows you to specify a CUSTOM database/spreadsheet to use. By contrast the regular container does not. If you accidentally associated your page with DB/Spreadsheet X but you want the form data to go into spreadsheet Y… your stuck. The regular block pulls data to and from whatever the main DB/Spreadsheet associated with the whole page is. Whereas the FORM container allows you to specify a spearate spreadsheet
SO here would be an actual problem. If you had TWO forms on one page, feeding two different databases, it seems like you would HAVE to use the forms container, because putting form fields into a regular container just automatically adopts the DB/spreadsheet that the page is using.
I believe Glide will be pushing similar container settings for Form containers in the future. It only makes sense and I’m 99.99% sure it’s on their radar. If it’s 100% necessary right now, you’ll have to use a regular container with a custom form until those container settings come to Form Containers.
I would want to add that until Glide Pages have better entry validations, I would stick to custom forms.
I second Thinh Dinh, I mostly create custom forms. @Darren_Murphy in one of his posts thoroughly explains how we creates custom forms.
Here’s the link.
nah, you’re not stuck at all.
All you need to do is direct your form entry components at user specific columns, and then use an Add Row action with your submit button, and you can add rows in any table that you want to.
In fact, its a quite common practice to use a single row “working table” with custom forms, where the only purpose of the table is to collect data to be inserted into other tables.
That’s easy to do with custom forms. You can either clear the user specific columns on the way in to the form, or clear them as part of the submit action. Depends on the use case.
This is also easy to do with a custom form approach.
All of the above is demonstrated in my Custom Forms concept app (the one that @ThinhDinh linked to).
