Good morning again @stefano.menci @jshaffstall
Okay, I won’t serialize the Forms (I didn’t like the whole form idea anyway, as I alluded). However, I will be serializing component attributes populated by content creators, which are the simplest of data types (True, False, int, str, etc) and shouldn’t pose a problem.
The SubForm’s components, look & feel, UI/UX, will never change even one bit (that’s not the content creators role). They are complete as I have designed them.
So, I’ll just do:
- For content creator: Instantiate SubForm1(…); unhide only components material to the content creator; let them complete it; and finally capture the relevant attributes of the now-populated SubForm1() instance (not the whole Form) into a Data Table.
Then, do the reverse (unwind this) for the servey taker:
- For Survey Taker: Read in attributes dict() from the Data Table; Instantiate a SubForm1(…) (initially all or most components are hidden); populate that instance’s content-related attributes from said dict(); and finally, unhide only those components material to the servey taker; and off the servey taker runs.
I’ll know how which “render path” to take (content creator versus survey taker) based on eMail login (the User table has an is_SurveyTaker boolean column).
Again, there are no dynamic Forms (I’ve designed them and they won’t change). Only component attributes values change and whether or not to make them visible.
So I think I see how to approach this (as I just described).
I just need to read up on Data Bindings (which I’m doing now). That seems useful as described by @meredydd and described by @stefano.menci
Thank you for the guidance! 