latin-language-toolkit/llt-annotation_environment — pull request #62 by LFDM (2014-05-16 07:28:30+00:00)
Title: Resource service and navigation stub

This PR adds two features

- The resource service

This service is actually a factory for external http resources. It is a wrapper around ngResource, that provides additional routeParams handling as well as better compatibility to xml files - something ngResource usually doesn't like, as its default configuration only works with JSON.
Data handling plugins (such as Retrievers and Savers) can define these resource objects through their configuration. The configurator service is actually the provider of these resources, plugins do not have to inject this service on their own. Almost every plugin needs the configurator anyway. They are obtained through calling `configurator.provideConfiguration(NAME_OF_PLUGIN)`.
Configuration of such a resource currently only includes setting a `route`, which supports route matching, and `params` to define which routeParams the resource is watching. Check the `staging.json` file for an example (the treebankRetriever and the bspMorphRetriever are using it).

In the future this will also be the place to handle other http verbs, right now only GET is implemented. Authentication (cookie references etc.) will also be handled through this resource object.

- The navigator

Cf. the commit comments for 7ec7f1a. This is only a very raw implementation as of now, that only works with full treebank files that contain more than one sentence. The behaviour is somewhat hardcoded into the treebankRetriever, which is a solution that cannot stay.
This is not a trivial problem. It is not clear what a navigation chunk exactly is. For treebanks moving from sentence to sentence might be sensible, for other use cases it clearly won't be.
Additional complexity enters when more than one document has to be loaded into the state object, even if this would almost work as it is right now. More on this at a later stage.

The point is: Navigational chunks need to be flexible, they have to be defined somewhere. If we are loading treebanks per sentence - as the Perseids eXist environment would provide at the moment (working with a document_id, that has several sentence_ids), the concept of `next` is already quite different than in a full treebank file. (full treebank files are used in the staging.json file, perseids-like files are present in staging2.json)

This has to remain unsolved for now.

- Next steps

Throughout the work on this PR it appeared that the structure of configuration files leaves a lot to be desired. A new attempt at formatting them will be made in the next PR, after that we return to work on these problems.

PR will be merged for now, additions to the features in it will come in separate branches.