chore: PC change (create multientry)

scratch.md

@@ -0,0 +1,136 @@
+Forms should be built for this application with a series of JSON-type files.
+Each form will have a series of sections, and each section will have a series of
+questions. Each question has a type and a label - question styles may come later.
+It may be possible for us to call out specific question types without needing
+to parse the types separately, but that feels not-really-worth-it.
+
+Example:
+
+```
+{
+    "SectionDefinitions": [
+        "SectionTitle": [
+            "text": {
+                "label": "First name question!",
+                "placeholder": "John",
+            },
+            "text": {
+                "label": "Last name question!",
+                "placeholder": "Smith",
+            }
+        ],
+        "Section Two": [
+            "text": {
+                "label": "Section two testing question",
+                "placeholder": "Some example here",
+            },
+            "select": {
+                "label": "This is a dropdown element!",
+                "placeholder": "option1",
+                "possibleValues": [
+                    "option1": "something",
+                    "option2": "another something",
+                ]
+            }
+        ]
+    ]
+}
+```
+
+...and so on. Here's a likely set of structures to use:
+
+```
+struct FormDefinitionDoc {
+    Vec<Section> section_defs;
+    // and any extra values that should be applied
+    // across the entire form, like settings.
+}
+
+struct Section {
+    Vec<QuestionComponent> questions;
+    // each section may have a series of settings including how to submit,
+    // when to submit, and where to submit to at the very least.
+}
+
+struct QuestionComponent {
+    label: String,
+    placeholder: String,
+    possible_values: HashMap<str, str>,
+    // there are definitely values that i'll find while creating this structure.
+}
+```
+
+Types of questions that are required, starting with the providers.
+
+Providers must be able to:
+
+ - Log into the website using a username and password (handled by AWS)
+ - Create and manage multiple scholarships.
+ - Input scholarship information for each scholarship.
+ - View students that have applied.
+ - View student application information (should just be labels??)
+ - Buttons are a given. Duh.
+
+Students must be able to:
+
+ - Log in using their Region 15 email (handled by AWS)
+ - Create and manage their general application.
+ - Create and manage applications specific to a single scholarship.
+ - View their acceptance status (need more confirmation)
+
+Administrators must be able to:
+
+ - Log in using their Region 15 email (handled by AWS)
+ - Manage student scholarship applications.
+ - Manage scholarship provider account information.
+ - Create/manage scholarship information.
+ - Download student applications if needed.
+ - Statistics would be nice, but are likely a future thing.
+
+Right off the bad, I think I can see a few types of buttons and text inputs,
+along with dropdowns, checkboxes, our custom `MultiEntry` element from last
+time. That means no new options, but it does mean that the `FormDefinition`
+needs to be able to keep track of all this information.
+
+These are some example `QuestionComponent` objects:
+
+Text fields:
+
+```
+{
+    question_type: "TEXT" | "EMAIL" | "NUMBER",
+    label: "The question label",
+    name: "input_name[jsdoc]",
+    placeholder: "An example input"
+}
+```
+
+Dropdowns/checkboxes/radios:
+
+```
+{
+    question_type: "DROPDOWN" | "CHECKBOX" | "RADIO",
+    label: "The question label",
+    name: "input_name[jsdoc]",
+    placeholder: "The pre-selected option value",
+    options: [
+        "optionValue": "Option Text"
+    ]
+}
+```
+
+`MultiEntry`:
+
+```
+{
+    question_type: "MULTI",
+    label: "The question label",
+    name: "input_name[jsdoc]"
+}
+```
+
+The real question here: how can we store this information in a database? And
+this means specifically within DynamoDB, because this is not an easy structure
+to store in there.
+That's going to be the hardest apart and I'll likely involve the AI in that
+planning.