Able to use two different edit forms actions in one screen

Ask for Help
1

I have a number of rows that each need their own unique forms to edit different values, but each action will update the same object and row.

So for example, image this sturcture:

Table Headers: Contact ID, Name, Gender, Phone, Coach, Coach Birthday

Action 1 - Edit Gender, Phone, Coach then Save
Action 2 - Edit Coach and Coach Birthday then save

I want one action to open an edit screen where I can update Name, Gender, and Phone. Then another button that can open a form where I can update Coach and Coach Birthdays. Currently if I try to create two actions and choose edit form then I always get the same default form. I can’t find a way to add two diferent forms where I choose different values.

I need this since i have MANY column attributes and I need to break them into differnt survey actions that a coach performs at different times. So they don’t update all data at the same time.

Can someone help?

2

So, essentially two “edit forms” inside an edit screen?

  • Add two containers for two sets of components.

  • Add a button that edits “Name, Gender and Phone”, set it to open in an Overlay.

  • Add a button that edits the other things, set it to open in a Slide In.

Notice the difference in a part of the URL between those two screens, and set the visibility condition of the containers accordingly.

3

That’s not a very normalised data structure, and could quite easily lead to problems in the future. The thing that really jumps out at me is “Coach Birthday”. Presumably a Coach can be associated with several Contacts, so this means that you’ll be storing each Coaches birthday many times in the same table. It’s easy to see how you could easily wind up with the same Coach having multiple birthday dates. At the very least, you should consider moving that to a separate Coaches table, so the birthday date for each coach is only stored once. I’d recommend having a think about how your data is structured. Watch the below video, you might find it a bit of an eye-opener. If you do a better job of structuring your data, you might find that you no longer need multiple edit screens.

3 Likes
4

Your issue – and answer – is in your opening sentence. You pinpoint the issue without realizing it. The way I see it, it’s one table, one form.

In Darren’s video, they discuss 3rd normal form.

  • 3rd normal form: Every (non-key) attribute in a table should depend on the key, the whole key, and nothing but the key.
  • Corollary: An attribute cannot depend on the key via a transitive dependency. In your example, the attribute CoachBirthday depends on the primary key ContactID via the transitive dependency CoachName (actually I think it would depend on the key ContactID-CoachName).

I couldn’t have said it better than Darren, because I learned database normalization from him. With the “Coach birthday” attribute, the table doesn’t follow 3rd normal form anymore.

Your next reasonable question could be “So do tables in Glide need to be normalized? And to what extent?”

I don’t have a good answer, I think people like Thinh, Darren, Bob, Jeff, the team at Glide of course and other developers by trade would have a good anwer. Glide is database-driven and logical, so making tables as normalized as possible won’t hurt, quite the opposite. I strive to ensure all my tables are at least in 3rd normal form (I probably mess up but I try), and really I try 5th normal form (I’m just less comfortable with grasping fourth and fifth normal forms).

3 Likes