latin-language-toolkit/arethusa — pull request #253 by LFDM (2014-07-11 21:53:10+00:00)
Title: Adding/removing tokens - editing token strings - id mappings - token eventing

Closes #173

A massive PR, not only in terms of size but also in importance. Work on the Ellipsis problem laid the foundation for a lot of future features.

The main body of work consists in the `artificialToken` plugin, which allows users to insert new tokens into the text - they act just like regular tokens then. At some point a further distinction of artificial tokens will be made. Right now only one type (elliptic) is supported. Based on this type, more annotation options will follow (for detailed analysis of an ellipsis, or for fillings gaps in fragmentary texts like inscriptions).

This led to an overhaul of the eventing systems. When tokens are added or removed, an event is fired directly through the `state` service, which injects `$rootScope` to allow eventing inside plugin services. This brings us a lot closer to the business of manipulation of underlying texts, e.g. splitting/merging tokens etc. As the string value of artificial tokens can also be edited, we now have functions at our disposal to change typos in templates. Separate PRs will start to work on such features.

Artificial tokens receive internal ids which position them inside a regular text. The limitations of the current treebank schema opened up the world of id mappings. The ids stored in treebank documents are NOT the same as our internal ids. While its arguable whether that's a good solution or not, the work on this is groundbreaking for Arethusa in general: Upgrades to the `idHandler` service decouple Retrievers and Persisters now from ids within a document - the `idHandler` provides an API to map back and forth between internal and document ids. This is not very well abstraced right now, but a huge step into the right direction. Subsequent work on this interface will finally allow us to work across multiple documents at once.

`treebankRetriever` and `treebankPersister` were refactored a bit in the process. They code is still quite ugly, but further abstractions will happen naturally here once we move to a new retriever and a new persister for the new treebank schema.