|
|
The goal of the document is to explain the architecture of the code to help new contributors.
|
|
|
It will assume that you are already familiar with the OCR workflow and the different bricks of the web stack (especially Django).
|
|
|
|
|
|
## Running eScriptorium locally:
|
|
|
There are two ways to run eScriptorium, the 'easy' way [with Docker](docker-install),
|
|
|
and the hard way by [installing and configuring everything yourself](full-install).
|
|
|
Unless you are familiar with coding inside a docker environment, the second solution is preferred for development because docker tends to get in your way during debugging.
|
|
|
|
|
|
## Coding workflow and guidelines
|
|
|
* We use gitflow (no extension), so:
|
|
|
new feature/fix branch -> Pull Request -> Peer Review -> merge into develop -> tag master -> merge develop into master -> deploy
|
|
|
* [cia python guidelines](https://wikileaks.org/ciav7p1/cms/page_26607631.html)
|
|
|
Note: considering using black for more code homogeneity
|
|
|
|
|
|
## General organisation
|
|
|
eScriptorium follows Docker & Django good practices as much as possible.
|
|
|
The root directory is the docker-compose root. The `app/` directory is the Django root.
|
|
|
All templates can be found in the project folder `app/escriptorium/templates/`.
|
|
|
Some statics can be found in the project folder; others, when closely related to an app can be found in their respective directory.
|
|
|
|
|
|
## Backend apps
|
|
|
They lie in app/apps/, they can be imported directly from anywhere because they are added to the python PATH in settings.py.
|
|
|
|
|
|
1) core
|
|
|
It is the main application, it contains most models and business logic. The main models are:
|
|
|
* `Document`, which represents a working directory (for the user it could be a single doc, an related ensemble, an entire corpus).
|
|
|
Note: there will probably be a 'directory' level on top of this one for organisation purposes.
|
|
|
* DocumentPart, which basically represents an Image and its
|
|
|
|
|
|
2) api
|
|
|
Doesn't contain any models, it only defines `django-rest-framework` endpoints for __internal and external__ communication.
|
|
|
|
|
|
3) imports
|
|
|
Historicaly Missleading name, it deals with both importing and exporting data.
|
|
|
|
|
|
4) helper apps: versioning, users, bootstrap
|
|
|
* versioning defines an abstract model to keep the history of a model instance
|
|
|
* users stores everything related to users but unrelated to the business logic;
|
|
|
* bootstrap is just a display layer to automate generating bootstrap css frontend forms.
|
|
|
|
|
|
|
|
|
## Frontend apps
|
|
|
The frontend code is mostly vanilla JS and some JQuery, we are considering using views.js, but since we are mostly backend devs we didn't jump in yet.
|
|
|
|
|
|
1) edition panels
|
|
|
[...]
|
|
|
2) wheelzoom
|
|
|
[...]
|
|
|
3) baseline editor
|
|
|
[...]
|
|
|
|
|
|
## statics and medias
|
|
|
[...]
|
|
|
|
|
|
## Unit testing and coverage
|
|
|
[...]
|
|
|
|
|
|
## The channel server and working with websockets
|
|
|
[...] (some tuto somewhere?)
|
|
|
|
|
|
## Working with an asynchronous task queue
|
|
|
[...] (some tuto somewhere?) |
|
|
\ No newline at end of file |