zydronium/manage.get.gov
1
0
Fork 0
mirror of https://github.com/cisagov/manage.get.gov.git synced 2025-08-02 16:02:15 +02:00
Code Issues Projects Releases Packages Wiki Activity

Revert "Merge remote-tracking branch 'origin/main' into nl/1798-update-email-signature"

Browse source 
This reverts commit ef5358e7e2, reversing
changes made to 5746dbe0a1.
This commit is contained in:
CocoByte 2024-03-12 12:37:49 -06:00
parent ef5358e7e2
commit 1e44b20690
No known key found for this signature in database
GPG key ID: BBFAA2526384C97F
88 changed files with 1834 additions and 2597 deletions
Download patch file Download diff file Expand all files Collapse all files

8
docs/architecture/decisions/0016-django-form-wizard.md
View file

@ -8,17 +8,17 @@ Accepted
## Context
The domain request form by which registrants apply for a .gov domain is presented over many pages.
The application form by which registrants apply for a .gov domain is presented over many pages.
Because we use server-side rendering, each page of the domain request is a unique HTML page with form fields surrounded by a form tag.
Because we use server-side rendering, each page of the application is a unique HTML page with form fields surrounded by a form tag.
Needing a way to coordinate state between the pages as a user fills in their domain request, we initially used the Form wizard from [django-formtools](https://django-formtools.readthedocs.io/en/latest/wizard.html). This eventually proved unworkable due to the lack of native ability to have more than one Django form object displayed on a single HTML page.
Needing a way to coordinate state between the pages as a user fills in their application, we initially used the Form wizard from [django-formtools](https://django-formtools.readthedocs.io/en/latest/wizard.html). This eventually proved unworkable due to the lack of native ability to have more than one Django form object displayed on a single HTML page.
However, a significant portion of the user workflow had already been coded, so it seemed prudent to port some of the formtools logic into our codebase.
## Decision
To maintain each page of the domain request as its own Django view class, inheriting common code from a parent class.
To maintain each page of the domain application as its own Django view class, inheriting common code from a parent class.
To maintain Django form and formset class in accordance with the Django models whose data they collect, independently of the pages on which they appear.