... | ... | @@ -19,9 +19,9 @@ 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.
|
|
|
They lie in app/apps/, they can be imported directly from anywhere because apps/ is added to the python PATH in settings.py.
|
|
|
|
|
|
1) core
|
|
|
__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, a related ensemble, an entire corpus..).
|
|
|
* `DocumentPart` represents an image which is usualy the scan of a page or a double page.
|
... | ... | @@ -32,38 +32,57 @@ It is the main application, it contains most models and business logic. The main |
|
|
It is also versionned to keep an history of modifications.
|
|
|
* `OcrModel` stores segmentation & recognition models.
|
|
|
|
|
|
2) api
|
|
|
__2) api__
|
|
|
Doesn't contain any models, it only defines `django-rest-framework` endpoints for __internal and external__ communication.
|
|
|
|
|
|
3) imports
|
|
|
__3) imports__
|
|
|
Historicaly Missleading name, it deals with both importing and exporting data.
|
|
|
|
|
|
4) helper apps: versioning, users, bootstrap
|
|
|
__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.
|
|
|
|
|
|
> Warning: It is very important to import one way only, from the more general to the more specific (to the business model).
|
|
|
> _Warning_: It is very important to import one way only, from the more general app to the more specific app (to the business model).
|
|
|
> Not only does it protects against circular imports but it's also good design to have your data flow one way only.
|
|
|
|
|
|
## 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.
|
|
|
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.
|
|
|
More info on the largest blocks:
|
|
|
|
|
|
1) edition panels
|
|
|
__1) edition panels__
|
|
|
[...]
|
|
|
2) wheelzoom
|
|
|
__2) wheelzoom__
|
|
|
[...]
|
|
|
3) baseline editor
|
|
|
__3) baseline editor__
|
|
|
[...]
|
|
|
__4) external librairies__
|
|
|
[...]
|
|
|
|
|
|
## Working with an asynchronous task queue: celery
|
|
|
[...] (some tuto somewhere?)
|
|
|
|
|
|
## The channel server (daphne) and working with websockets
|
|
|
[...] (some tuto somewhere?)
|
|
|
|
|
|
## statics and medias
|
|
|
[...]
|
|
|
|
|
|
## Unit testing and coverage
|
|
|
[...]
|
|
|
|
|
|
## The channel server and working with websockets
|
|
|
[...] (some tuto somewhere?)
|
|
|
Simply run
|
|
|
|
|
|
$ python manage.py test
|
|
|
|
|
|
To run the tests for a single app
|
|
|
|
|
|
$ python manage.py test api
|
|
|
|
|
|
Or a single test (example)
|
|
|
|
|
|
$ python manage.py test api.tests.DocumentViewSetTestCase.test_list
|
|
|
|
|
|
Coverage
|
|
|
|
|
|
## Working with an asynchronous task queue
|
|
|
[...] (some tuto somewhere?) |
|
|
\ No newline at end of file |
|
|
$ coverage run --omit=/env/ manage.py test # env dir may vary
|
|
|
$ coverage report -m |