6. Upload Form Documentation

This page will tell you about the upload form from a developer's perspective.

• The upload form is made with Django
• The goal of the uploads is for users to add metadata and files to pre-existing works, or to add a work to the database along with any metadata and files they have. As such, there is a need for authority control.
• The upload form's autocomplete elements, for example to select the title of a musical work already in the database, was made with Django Autocomplete Light (DAL).

File structure:

• The upload form is split in two; the first page is for the musical work metadata input, and the second for the file information.
• creation_view.py : This is the view for the first form. The post function handles the given musical work and composers. The raw POST data is converted to a format that is accepted and validated by the Django form.
• creation_form.html : This is the template for the first form. It contains the contributor form.
• file_creation_view.py : This is the view for the second form. It requires the ID of a musical work, which is either created or selected from the previous form. It uses this to associate the uploaded file and its metadata to the appropriate work.
• file_creation_form.html : This is the template for the second form.
• creation_forms.py : This file defines the widgets that are used by both templates. One of widgets is not a built-in widget, and is custom: InfoTooltipWidget is defined in info_tooltip_widget.py. I tried to make a custom widget for autocompleting input elements but was unsuccessful and therefore rely on DAL, but a native HTML element would be more stable.

Contributor form:

The contributor form in the first page can be duplicated to input multiple contributors. This can be done with native Django with formsets; however, the duplicating the DAL elements with this method has proven difficult. To solve this, a workaround was implemented to duplicate forms, up to a maximum of three total (2 duplicates). Form duplication is done by simply taking the HTML of the original form, replacing the id's of each element and widget names, and appending the new HTML to the end of the previous form. Three sets of widgets are created in creation_forms.py. Their id is the name of the widget + a number from 0 to 2 representing which form it belongs to. When the HTML is duplicated and edited, the widget name is edited such that a new, separate widget is added to the form, rather than a duplicate of another widget. This is done to avoid confusion in the view where the elements' inputs are handled.

The DAL autocomplete widgets allow users to select one or multiple objects from the database. All objects of the certain class is available to be selected, and as the user types, the objects are narrowed down based on a defined attribute. So, when one first clicks on the select "Instruments" element, all instruments are listed; but, if the user starts to type in "Gui" into the text box, it will be narrowed down to Guitar based on matching the name attribute of the instrument (and any other instrument with "Gui" in the name).

Authority Control:

Ideally, the entire upload form would incorporate a level of authority control. Currently, upon populating the database, VIAF's locations page is scraped to add basic locations that users may select while picking a location of a contribution. However, there is no filtering for this process, meaning there are some highly unnecessary locations such as Antarctica. Despite this, pulling data from VIAF (with some filters), and elements in the upload form that allow selection/autocomplete to objects in the database, is a good starting point for authority control.