Introduction

WARNING

The software is in the Alpha stage and is under active development.

This section provides a general overview of the Open Dig Reports (ODR) software.

Stack used: MySQL, Nginx, Laravel, Vue, Pinia, Vue-Router, Vuetify, Vuelidate.

The ODR is a Single Page Application (SPA). The Laravel backend provides the initial download of the application to the browser and functions as an API server.

The frontend is written in TypeScript and utilizes the Vue framework with Vuetify for UI.

The application is url driven; that is, the frontend routing middleware (provided by Vue-Router) is responsible for intercepting url changes, performing (frontend) authorization and validation, and requesting and storing data retrieved from the backend. The frontend uses Pinia for state management and Vuelidate for form validation.

As mentioned in the Core Design Choices section, a first step in dealing with the complex archaeological record and reining in the applications' complexity was to center its design around the module. This naturally lead to the use of a relational database with each module represented by a specific table (stones, ceramics, etc.) and its supporting tables (lookups, tags, onps).

A few techniques were applied to allow for some flexibility with regard to the variability of the records:

• Free text fields such as "description" and "notes" columns are widely applied as catch-all entries.
• Whenever possible, properties were divided into groups, each containing a limited number of options.
• To accommodate required/optional and single/multiple properties from the above groups, different group types were defined, each corresponding to specific DB storage schemas (enums, external tables of different schemas).
• The Trio structure with its dependency system was devised in order to reduce overchoice.
• The different treatment of single vs. aggregate records is handled by using a single table (rather than two) while utilizing the different group types mentioned above to accomodate for these different record types.

The design of different module-specific registration schemas and frontend forms are implemented on a per-application basis.

Please visit the project's github page for more details.