Very impressive. It reminds me of Surveyjs.io, which is also very feature rich. One of the reasons for me for looking into SurveyJS was the ease of creating data entry forms, which is quite a challenge in Anvil.
You seem to have a nice set of entry components. Have you considered extracting the entry components so that they might be used in other projects as well? Would be a godsend.
BTW I have succeeded of integrating SurveyJS in Anvil. I succeeded creating surveys, showing them in Anvil, gathering the survey data. However I have not yet succeeded in using the survey form to edit existing data. I’d be happy to share my experiments.
I’m interested in your experiments. I don’t really understand what you mean, though, by data entry forms being a challenge in Anvil. Could you say more about that?
What I meant by data entry forms being a hassle in Anvil, is that it does not provide fields with validation (the text entry ‘type’ does not work). Furthermore what would be useful would be to have compound fields with a label, title, help text, error message (localised) + form validation. I am aware of the library form validation but found that lacking as well.
I have tried to create such components myself but found them lacking as well because the custom component implementation is very limited in Anvil (limited property support w/o validation), no preview of components (so all look alike when used), limited event model (although anvil-extras provides a useful pubsub implementation).
Finally I find it hard to tweak the appearance of Anvil forms. Fine for quick, internal apps, but not very polished (compared to, say, the Quasar framework). I know I could probably use a custom theme or something, but I haven’t tried that yet.
Many of the anvil-extras custom components also support preview in the designer as of v1.4 (though I haven’t examined how it works).
Is there a model elsewhere for the kind of compound component you have in mind? To me, it seems difficult to imagine making one that generalizes sufficiently to all the different cases one might want to use it for?
I haven’t seen any GUI definition that excels in this area. They just stop at making data entry possible. As if that’s ever enough… Have they all forgotten the GIGO principle?
Databases have paid much closer attention. A DB’s Domain Model is a good start. In a Domain Model, you explicitly define, for each datum, its set of valid values, or Domain. (If it’s multiple choice, you define the choices, the values to be stored, the display/print string for each, the order in which they should appear. If it’s numeric, you typically set the upper and lower bounds, and the precision.)
Several different datums may fall into the same Domain (such as PersonAge), so it helps to be able to name your domains. It’s even better if you can give them a user-readable explanation of what’s expected. That way, the Help text for a datum can focus on that datum’s role or purpose, not its set of values.
For GUI use, this kind of constraint can be checked immediately at point of entry. That’s the optimum time to tell them where they went wrong, while a person is still focused on the entry field or widget.
Scope of a Domain is not always just a single value. For a group of related datums, e.g., where the user enters both an upper and lower bound on a variable, then you need cross-datum constraints. These can be checked when the GUI focus leaves that particular group.
Alas, I have not seen any GUIs lately that take these ideas seriously. But any system that includes a clean, simple Data Dictionary, with all of the above GUI-independent details, would be a good start.
I think the Quasar framework provides a refined set of components. Among them form entry components with a simple validation network. See: Input | Quasar Framework