... | ... | @@ -7,7 +7,7 @@ Catalinker started as a simple dynamic one page app that could render all input |
|
|
Catlinker is designed to be as flexible as possible in terms of supported ontology and workflow.
|
|
|
|
|
|
# Architecture
|
|
|
The application consists of a Node.js back end serving a javascript/Ractive.js front end.
|
|
|
The application consists of a Node.js back end serving a javascript/[Ractive.js](http://www.ractivejs.org/) front end.
|
|
|
## Node backend
|
|
|
The node.js back end serves static files; html, javascript, images etc, in addition to serving the main configuration, caching and proxying to services container.
|
|
|
### Browserify bundling
|
... | ... | @@ -15,7 +15,7 @@ All node mudules and the main javascript source files are bundled with browserif |
|
|
### Caching
|
|
|
The node back end enforces aggressive caching, to minimize loading time.
|
|
|
### Proxying service calls
|
|
|
All actual data processing; POST, PATCH etc are forwarded to the services container. GETs are cached, but invalidated by POSTs and PATCHes to same resources.
|
|
|
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.
|
|
|
|
... | ... | |