What is needed here is a way to recursively (statically or dynamically) open views to satisfy more complex inputs.
Some instances of this can be found in #7.
Let's say you had three python classes: A, B, and C such that, at some point you need from the user to get an instance of C:
To do this, you need to get an A and a B in the first place, whose __init__ requires further objects.
The input elements for a and b could include the possibility of uploading these from a file, or a DB managed by the app's backend. But sometimes (for example, to get these saved items in the first place) we may need to ask the user to construct their a or b...
So we click on a "make one" button of the a input element, and this brings up a view for A(d: D, e: E, ...).
The user can then go down the tree until all inputs are acquired.
Of course, if this process takes time, we want to offer, by default, some caching and/or persistence possibilities to not use all that work.
What is needed here is a way to recursively (statically or dynamically) open views to satisfy more complex inputs.
Some instances of this can be found in #7.
Let's say you had three python classes:
A,B, andCsuch that, at some point you need from the user to get an instance ofC:To do this, you need to get an
Aand aBin the first place, whose__init__requires further objects.The input elements for
aandbcould include the possibility of uploading these from a file, or a DB managed by the app's backend. But sometimes (for example, to get these saved items in the first place) we may need to ask the user to construct theiraorb...So we click on a "make one" button of the
ainput element, and this brings up a view forA(d: D, e: E, ...).The user can then go down the tree until all inputs are acquired.
Of course, if this process takes time, we want to offer, by default, some caching and/or persistence possibilities to not use all that work.