A user moving through a multipage webform might have second thoughts or encounter information on later pages that causes them to want to go back and edit earlier pages. As discussed below, it probably isn’t possible for a multipage FormFunction to automatically facilitate such editing unless it has a static layout. In the static layout case, the below code gives the FormFuncton user some access to editing previous page information by cumulatively adding fields for these inputs. Can anyone think of less restrictive conditions, simpler and/or alternative ways to accomplish multipage FormFunction editing?

Default FormFunction editing

Multiple clicks of the browser back button will allow the user to go back to any previous form page, but as each previous page opens any input that was previously entered will be gone. Furthermore, after going back to the page to be edited, appropriately re-entering the information, and clicking the FormFunction Next button, the user will have to re-enter all information on the page after the edited page, and so on for all subsequent pages.

The example in the FormFunction > Examples > Scope > Multipage forms documentation section shows a multipage pure function formspec that programmatically sets the number of fields on second page equal to the integer input on the first page. The possible presence of such multipage dynamic layout would apparently make it difficult, if not impossible, for Mathematica to automatically support paging back and forth through a multipage form in a way that preserves all earlier inputs. However, if the multipage layout is completely static then multipage FormFunction editing should be possible.

Simple static layout editing

For a static layout the number of fields (and their input types) on each page is preassigned rather than dependent on user input. But on each page it's still possible to make the user prompt, that is the field label, depend on all previous page inputs:

CloudDeploy[
   FormFunction[{
      FormObject[{
            {"A", "A. Given no prior input:"} -> "String"},
         AppearanceRules -> <|"ItemLayout" -> "Vertical"|>],
      FormObject[{
            {"A", "A."} -> <|"Interpreter" -> "String", "Input"->#A|>,
            {"B", "B. Given prior input " <> #A <> ":"} -> "String"},
         AppearanceRules -> <|"ItemLayout" -> "Vertical"|>] &,
      FormObject[{
            {"A", "A."} -> <|"Interpreter" -> "String", "Input" -> #A|>,
            {"B", "B."} -> <|"Interpreter" -> "String", "Input" -> #B|>,
            {"C", "C. Given prior input " <> #A <> ", " <> #B <> ":"} -> "String"},
         AppearanceRules -> <|"ItemLayout" -> "Vertical"|>] &},
      Identity],
   FileNameJoin[{$CloudRootDirectory,"MultipageFormFunctionStaticLayoutEdit"}]]

The first FormFunction page displays the field named A and the string “a” is entered. The second FormFunction page displays the field named B with a prompt that responds to the input from field A, the string “b” is entered, and the input for field A is edited to be “aa”. The third FormFunction page displays the field named C with a prompt that responds to the input from fields A and B, the string “c” is entered, and the inputs for fields A and B are edited to be “aaa” and “bb”. The final FormPage shows that the A, B, and C fields have been correctly assigned their input or last edited values.

Comment

The FormFunction parser does not correctly handle a multipage formspec. For example, it presumably should be possible to put labels above fields instead of to their left with the FormFunction option:

AppearanceRules -> <|"ItemLayout" -> "Vertical" |>

This does not work correctly on the desktop and deployed to the cloud it returns an error. Fortunately there’s a workaround, which is employed in the above code. Explicitly specify each FormObject and repetitively include the AppearanceRules option in each FormObject.