... | ... | @@ -17,7 +17,7 @@ The node back end enforces aggressive caching, to minimize loading time. |
|
|
### Proxying service calls
|
|
|
All actual data processing; HTTP POST, PATCH etc are forwarded to the services container. GETs are cached, but invalidated by POSTs and PATCHes to same resources.
|
|
|
## Application structure
|
|
|
To allow flexibility with respect to ontology and workflow supported, the application conceptually consists of a front end that knows how to render any number of input fields grouped by tabs and connected to specific RDF targets such that each tab roughly concerns some aspects of one resource. A resource in this case can be a _Work_ og a _Publication_. These corresponds to resource types from the ontology. Each tab also has a button to navigate to the next tab, supporting a particular work flow e.g. search for a work, then create a publication of it and then link it to the work. In addition, tabs may be selected explicitly once enabled by the workflow state. The application is deigned to be capable of handling a somewhat shallow hierarchy of resources, more specifically _Work_ as top nodes and one or more _Publication_ as children. Depending on context, the editor at any time targets a _Publication_ and its parent _Work_ or only a _Work_ instance. In the former case, the uri of the _Publication_ infers also the uri of the _Work_, so only the uri of the _Publication_ is present in the address bar.
|
|
|
To allow flexibility with respect to ontology and workflow supported, the application conceptually consists of a front end that knows how to render any number of input fields grouped by tabs and connected to specific RDF targets such that each tab roughly concerns some aspects of one resource. A resource in this case can be a _Work_ og a _Publication_. These corresponds to resource types from the ontology. Each tab also has a button to navigate to the next tab, supporting a particular work flow e.g. search for a work, then create a publication of it and then link it to the work. In addition, tabs may be selected explicitly once enabled by the workflow state. The application is designed to be capable of handling a somewhat shallow hierarchy of resources, more specifically _Work_ as top nodes and one or more _Publication_ as children. Depending on context, the editor at any time targets a _Publication_ and its parent _Work_ or only a _Work_ instance. In the former case, the uri of the _Publication_ infers also the uri of the _Work_, so only the uri of the _Publication_ is present in the address bar.
|
|
|
|
|
|
A guiding principle during development has been to separate the general from the specific, so that the front end in principle should be able to handle any type of resource in a structure, not only _Work_ and _Publication_, but e.g. Buildings and Floors. "Publication" and "Work" are therefore mentioned as rarely as possible in the code, but it has not been totally avoided. One could argue that the mindset has been kept, however. To support the principle above, all specific behavior is configured in the file `workflow_config.js`, which is served by the back end. The configuration file describes which predicate from the ontology goes to which tab in the workflow, and other helper functions like how to search for relevant values when linking to authorities, which fields should be shown when creating new authorities etc.
|
|
|
|
... | ... | |