... | ... | @@ -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 POSTsand PATCHes to same resources.
|
|
|
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.
|
|
|
## 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.
|
|
|
|
... | ... | @@ -26,12 +26,12 @@ Following the from above, all solutions are designed to be as generic as possibl |
|
|
The use interface is constructed with thee help of one from of a handful of _templates_. The most important being `workflow.html`, while the entry point to the application is via the `menu.html`template.
|
|
|
|
|
|
### Ractive.js
|
|
|
Catalinker uses Ractive.js web framework, developed by the Guardian newspaper. Its main purpose is two-way binding between input fields and javascript object structures, suitable for rendering a complex user interface backed by an application state.
|
|
|
Catalinker uses [Ractive.js](http://www.ractivejs.org/) web framework, developed by the Guardian newspaper. Its main purpose is two-way binding between input fields and javascript object structures, suitable for rendering a complex user interface backed by an application state.
|
|
|
### main.js
|
|
|
Most of the functionality in Catalinker is in main.js. main.has grown from its simpler state in the old catalinker mentioned earlier to a quite large chunk of javascript code. Some parts and functions are more complex than others, and cater for more than one concern. No doubt should the file be divided into smaller modules and perhaps utilise ractives component support, but because of the incremental nature of the development process followed, and perhaps laziness, it has not come to this yet. However, most functions are kept small and with descriptive names, and the structure is roughly the same as from the beginning, only with more features added.
|
|
|
Most of the functionality in Catalinker is in main.js. main.has grown from its simpler state in the old catalinker mentioned earlier to a quite large chunk of javascript code. Some parts and functions are more complex than others, and cater for more than one concern. No doubt should the file be divided into smaller modules and perhaps utilize Ractive's component support, but because of the incremental nature of the development process followed, and perhaps laziness, it has not come to this yet. However, most functions are kept small and with descriptive names, and the structure is roughly the same as from the beginning, only with more features added.
|
|
|
|
|
|
#### Outline
|
|
|
The outline of `main.js`is as follows:
|
|
|
The outline of `main.js` is as follows:
|
|
|
* Require directives, e.g. requiring jquery and jquery-ui artifacts.
|
|
|
* Various functions
|
|
|
* Dialog handlers using jquery-dialog
|
... | ... | @@ -61,6 +61,7 @@ The configuration file mainly consists of these groups: |
|
|
|
|
|
#### `inputForms`
|
|
|
This is an array with objects that describe forms used to create and maintain authorities, e.g. _Person_ or _Place_. Each has an array of inputs specifying which RDF-property should be made available for entry.
|
|
|
|
|
|
#### `tabs`
|
|
|
This is an array og objects each describing a tab in the workflow, with attributes like tab label but most important which type of resource the fields in the tab adresses. The application can at any time handle one resource of each type, so all tabs with the same `rdfType`, e.g. `Work` targets the same resource.
|
|
|
|
... | ... | |