ModelForms
+ModelForms
A few of our data entry pages use ModelForms, these are where the Form object is automagically created from a Model class. If you can't find where something is initialised, it is probably because it was done automatically and invisibly by instantiating a ModelForm. - + +
Form views: the code that handles form input
+The python code which handles the presentation of a form and handles the user responses is called a Django "View" and in troggle these functions are all in python files in the folder troggle/core/views/. There are two ways of doing it: Class-based views (CBV) and Function-based views (FBV). Troggle only uses function-based views for the reasons described very well in this article on why Class Based Views are not a good fit for the community we have maintaining troggle. + +
The documented method for handling the "GET" and "POST" http interactions in Django FBVs are to use a large if statement: +
if request.method == "POST": # POST
+ ....
+else: # GET
+ ....
+def dwgupload(request, folder):
+
+ def _setup(folder_arg):
+ # initialize common state and return context dictionary ctx
+ ......
+ return ctx
+ def _get(ctx):
+ # build page and prepare form using data in the supplied context ctx
+ ......
+ return ctx
+ def _post(ctx):
+ # handle POST -- validate form and save files, update ctx in-place
+ ......
+ return ctx
+
+ # main flow: setup, then POST or GET handlers, then render
+ ctx = _setup(folder)
+
+ if request.method == "POST":
+ ctx = _post(ctx)
+ else:
+ ctx = _get(ctx)
+
+ response = render(request, .....) # rendered form to display on screen
++ Not all our forms use this structure yet. +
+ We looked at using the extremely simplified Class-based View structure where all our view functions would inherit from Django View class, but it has no advantages over this pure function structure and many disadvantages in readability and maintainability. +
For loop
