Annotation Tacks Data Source and Caching

[MrFlick]

Here are two small updates for the data sources. This first wraps the annotation tracks (or BED tracks, more generally) as an API data source end point. A simple test on the default demo page can be run with adding the data source

 data_sources.add("ann", ["BEDLZ", apiBase + "annotation/intervals/results/"])

and then requesting data

demo_instance.lzd.
  getData(demo_instance.state, ["ann:start", "ann:end","ann:state_name"]).
  then(console.log.bind(console)).done();

The second update allows for URL level caching on data sources that they can opt into. For example, on the default page. Running

demo_instance.refresh()

shouldn't trigger any new data requests. and running

demo_instance.applyState({ldrefvar:"10:114808902_G/T"})

should only trigger one call to the LD source.

[MrFlick]

@Frencil This should be all set if you want to play with the annotation track stuff. I didn't feel like I was doing a good job at naming things today so if you have any suggestions for improvement, let me know.

[Frencil]

Sorry about that last comment, trackpad submitted it early.

Essentially I thought about the approach presented here and it's nice and compact as is and does what it does well. The only thought I had to further simplify it would be to make caching just the last response for each source by default (essentially what's happening here) the only logic. It's cheap to just store it since the number of data sources can never practically be that many at once, and the configurable part can be whether a given source should pull it from the cache if the cache is there.

In other words, getRequest could do just what getPossiblyCachedRequest does, just with the added check of only going to the cache (that's refreshed every time no matter what) if some configurable boolean (this.useCachedURLResponse / this.useCache / this.requestFromCache) set on the data source is true. This would simplify the number of methods to get data back down to just getURL, getRequest and getData--a nice logical progression.

[MrFlick]

Thanks for the suggestions. I've tried to streamline things a bit. Caching is enabled by default now. I created a fetchRequest() function that is called by getRequest() that does the actual AJAX call. That way just that function can be customized (if you have a server with strict authorization requirements or something) and you can still take advantage of caching without redoing it yourself. I've also made the getCacheKey a replaceable function if you wanted to cache on something other than the full URL.

[Frencil]

Looks great! For reference: today Marc is describing a use case for supporting POST requests in the future, something that would be good to support in general. Breaking out the generation of the request to this fetchRequest() method provides a nice place to do that logic down the road when we're looking at adding POST request support.

Merging...